Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Ari Saastamoinen Newsgroups: sfnet.atk.linux Subject: Re: Kuormantasausta kahdelle isp:lle Date: 19 Feb 2017 20:13:39 +0200 Organization: A noiseless patient Spider Lines: 137 Sender: oh3mqu@titan.hyper.fi Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: mx02.eternal-september.org; posting-host="3af7ce1f57e1df926062c8f1337e33f9"; logging-data="5547"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+dGtSExFfFtpUVFr2DYzBx" User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Cancel-Lock: sha1:fuiAyaGkoBt7HmvosA88gMYJtpM= Xref: csiph.com sfnet.atk.linux:939 Reijo Korhonen writes: > >> tosiaankaan rakenneta http-yhteyden varaan. Joten kyllä noissa > >> yhteystavoissa on aika iso periaatteelinen ero, vaikka molempia Juu, periaatteellinen ero on se, että toisessa dataliikenne on salattua ja suojattua matkalla tapahtuvalta data muuttamiselta. Ja tuo onkin ihan merkittävä ero, ja tuota HTTPS:ää tulisi käyttää kaikissa palveluissa. Googlekin nykyään suosii hakutuloksissa HTTPS:ää käyttäviä saitteja. (Ja nykyään tulee kauheasti falsepositiivisia SafeBrowsing -varoituksia, ja luulen, että siihen vaikuttaa salaamattomuus ja lomake samalla sivulla) > > Staattisten sivujen latailu yksitellen ei varmaan ole gatewayn > > vaihtumisesta moksiskaan. > > Niin minäkin ajattelen. Maailma oli yksinkertainen kun vain näitä oli. Suurin osa staattisilta vaikuttavista sivuistakin sisältää nykyään kauheasti logiikkaa taustalla, ja sekin saattaa tehdä jotain hämmentävää jos IP-osoite vaihtuu pyyntöjen välissä. Tuskin kuitenkaan mitään kauhean ongelmallista. > > Käyttäjän tunnistava palvelu tuskin siitä tykkää. Toki nuo ovat > > kaikki jo https ja pitääkin olla. > > Juuri näin. Tällöin ainakaan sivun pääsoitteen eli sen osoitteen jonka > laittaa selaajaan (jos mitään uudelleenohjauksia ei ole yms. mutta jos > ymmärrätte mitä tahdon sanoa, ei mennä aidanseipäisiin, eihän ;-)) ja > jossa palvelussa käyttäjä tunnistautuu ja tunnistetaan, pitää hallitusti > yllä istuntoa joka teknisesti ei voi siirtyä isp:ltä toiselle kesken > istunnon, vaan se tunnistettaisiin toiseksi istunnoksi, jossa ei ole > tunnistautumista voimassa. Edellenkään HTTPS ei tarjoa YHTÄÄN sen enempää sessionhallintaa kuin salaamaton HTTP:kään, joten tuollainen kuormantasausjärjestely toimii tai on toimimatta ihan tuosta SSL-kerroksesta huolimatta, ja toimiminen riippuu siitä, että onko käyttäjän IP-osoite yhtenä parametrina tuossa sessionhallinnassa. > Kuormantasaus ei siis voi toimia niin, että kesken istunnon kuormaa > tasataan tähän istuntoon kuuluvissa yheyksissä toiselle isp:lle. Ei voi, mutta HTTPS:ssä noi SSL-sessiot ovat lyhyitä, ja suurin osa asioista toiminee vaikka ISP:tä vaihdettaisinkiin TCP-sessioiden välissä. Eli siis TCP:n SYN- ja RST-paketit on turvallisehkoja vaihtopaikkoja. Mutta kuitenkin löytyy niitä palveluita, joissa sessiontokenit on sidottu IP-osoitteeseen, niin niiden kanssa toimiessa käytännössä pitäisi tunnistaa se ylemmän tason sessio, ja sen puitteissa sitten pitää IP-kiinteänä, mutta koska noita sessiototeutuksia on satoja erilaisia, niin käytännössä sun kuormantasaajasi ei sitä pysty tunnistamaan - eritoten jos sivustolla on SSL-käytössä, niin sitten se ei noita sessiotunnisteita pysty edes arvaamaan, kun ne on salattu. Sellainen järjestely olis kohtuullisen hyvin toimiva, että esim. parillisen IP-osoitteen palvelimet reitittäisi toista kautta, ja parittomat sitten toiselle reitille. Tästä tosin ei ole mitään iloa, mikäli netin käyttö on tyypillinen (lataat sivun luet sitä hetken, ja klikkaat linkki seuraavalle sivulle), mutta jos latauksia (eri palvelimilta) on samanaikaisesti käynnissä useita, niin sitten tuo on ihan toimiva ratkaisu. Mutta tuossakin sitten saattaa aiheuttaa ongelmia sellaiset palvelut, joiden kirjautumispalvelu on eri kuin varsinaisen sisällön tarjoava palvelu. > striimi avataan ja tässäkin yhteyskäsite menee korkeammalle tasolle kuin > pelkkä sokettiyhteys. Tai voi mennä, riippuu toteutuksesta. Jos on kirjautumisen vaativa webbisovellus, niin tuo yhteyskäsite menee AINA korkeammalla tasolla kuin TCP-soketti, ja jopa SSL:ääkin korkeammalla, koska toi SSL ei tuohon session hallintaan tarjoa mitään lisäapuja pelkkään sokettiin verrattuna. > Jos koko striimi tulee yhden auki olevan sokettiyhteyden kautta ja > Nyt täytyy tietenkin arvata kuinka striimit käyttäytyvät, mutta > kuvittelisin esim. youtuubin striimien toimivan OK vaikka sieltä tulisi > mainosstriimit eri servereiltä siksi, että kokonainen striini tulee yhden > sokettiyhteyden kautta. Mutta kun en ole kokeillut, niin en voi tietää. Tosin esim. youtube-videota näyttävä selauin näyttäisi vähän väliä pyytävän tuollaisia webbirequesteja, joihin tulee vastauksena tuollaisia useampisatakiloisia datablobbeja, joten toikin todennäköisesti toimii niin, että se pyytää pätkän videota, ja sitten vähän päästä pyytää lisää (Muuten olisikin huomattavasti hankalampaa toteuttaa mm. se että videossa voi hypätä eri kohtaan). Todennäköisesti toi youtubekin toimisi ihan hyvin vaikka noi peräkkäiset pyynnöt tulisikin eri IP-osoitteesta. > Juuri näin, isp ei voi vaihtua istunnon aikana, Mutta esim. > pankkipalveluissa se ei vaihdu, sillä kaikki vastaukset tulevat samalta > serveriltä. Näin oletan. Oletettavasti pankkipalveluissa on ihan katkosten minimoimiseksi käytössä useita edustapalvelimia, joille pankin oma kuormantasaus sitten asiakkaitten pyyntöjä heittelee. > istunnon ajan. Mutta jos oletan väärin, kertokaa sellainen https-yhteyden > avulla toteutettu tunnistusta käyttävä palvelu jossa näette > potentiaalisen ongelman. Esim. OP tekee jokaisesta toimenpiteestä, jonka verkkopalkissa teet ihan uuden soketin ja kättelee uuden SSL-session (Ks. edellinen viestini, joka meni ohjauksesi mukaa .sotiin). Ja jos sun kuormantasaimesi jakaa liikennettä TCP-sessioiden perusteella, niin on jopa todennäköistä, että ne sun eri klikkauksesi menee eri IP:llä pankin palvelimelle. Ja jos se pankin sessionnhallinta vertaa sessiotokenin lisäksi myös IP:tä, niin ei toimi. Mutta on ihan mahdollista, että se ei käytä IP-tietoa mihinkään (muuhun kuin logitukseen) > > prosessien liikennettä. Failover on myös selvä tapaus. Edes failover ei ole helppo, sillä tuollaisen kuormatasaimen tasolla toimiessa ei ole ihan triviaalia aina selvittää, että nyt tuo reitti on rikki. > En löydä linuxin kuormanjaosta mitään tätä tukevaa asiakaspäähän. > Sokettiliikennettä ip-tables tasolla ei yhdistetä millään helpolla > tavalla käyttäjiin ja istuntoihin ja palveluihin ja prosesseihin. Ja Iptables:n säännäillä pystyy kyllä mätsäämään haluttuun prosessiin tai käyttäjään (mikäli sitä ipteblaesia ajetaan samalla koneella kuin sitä prosessia). Tuolla saisi ainakin eri käyttäjien liikenteen kulkemaan eri reittiä. Prosessin nimen mätsäämisestä ei liene kauheesti iloa, kun molemmat käyttänee sitä samaa firefoxia. Mutta näyttäis iptablesi sallivan mätsäyksen myös cgroup:n mukaan, ja tuon avulla voisi ehkä saada tehtyä säätöä myös prosessin mukaan. -- Arzka oh3mqu+nntpsig@hyper.fi - En halua follareita mailina 1. Valitse sopiva paikka, ei ihmisten tai rakennusten lahella, jossa paukku voi aiheuttaa hairiota. - Iso-Kiinalaisen kayttoohje