Discussion:
Kuormantasausta kahdelle isp:lle
(too old to reply)
Reijo Korhonen
2017-02-01 22:03:02 UTC
Permalink
Näyttäisi siltä, että jäinkin kahden isp:n loukkuun. Samantasoista
palvelua lupaavat. Noh, asiat voi nähdä valoisastikin eli nyt on
tilaisuus ;-) Opetella ja säätää kuotmantasausta linuxilla.

Kone1-- ! !--- modeemi1 --- ISP1
Kone2-- Linux--
Kone3-- ! !--- modceemi2 -- ISP2

Toivottavasti kuva ei muutu matkalla. Noh, minulla on siis Linuc
rfeitiämässä muutamalle koneelle internettiä. Ja tämä linuc näkee kaksi
er1 modeemia joiden takana kaksi eri ISP:tä tarjoaa nettiä. Olisihan se
kiva että kun ylimääräistä maksua menee, niin molemmista ISP:stä saisi
vuorotellen tavaraa sisään. Jotenkin niin, että joku palikka katsoo että
jos toinen ISP ei ole ehtinyt vastaamaan edelliseen pyyntöön ja toinen ISP
on joutilas, niin seuraava pyyntö sillejoka on vapaana. Tämä tietysti
onnistuu istunnottomissa palveluissa (http) mutta eikös istunnollisissa
(https) palveluissa istunto pidä mennä koko istunnon ajan saman isp:n
kautta, sillä muuten vastapuoli luulee että otetaan toinen istunto ja
silloin kaksi istuntoa taitaa olla pian epäsovussa.

Miten tälläiset kuorman tasaukset/optimoinnit säädetään linuxissa?
--
***@iki.fi.nospam.invalid
http://www.iki.fi/Reijo
Mikko Tuumanen
2017-02-12 19:20:50 UTC
Permalink
Post by Reijo Korhonen
Näyttäisi siltä, että jäinkin kahden isp:n loukkuun.
Miten tälläiset kuorman tasaukset/optimoinnit säädetään linuxissa?
Luodaan toinen reititystaulu. Näin saadaan toinenkin oletusreitti,
(siis "gateway" tai "default route") eli voidaan käyttää molempia
yhteyksiä samanaikaisesti.

Tämän jälkeen on luotava jonkinlaiset säännöt sille, mitkä
yhteydet reititetään milläkin reititystaululla. Sääntö voi
olla yksinkertainen, eli osoitteen tai verkkoliitännän
perusteella, mutta tässä tapauksessa mielenkiintoisempi on
MARK-vaihtoehto, eli reititystaulun valinta iptablesin tekemän
merkinnän perusteella.

Näin isp:n valinta saadaan tehtäväksi iptablesilla ja siellähän on
erilaisia kikkoja käytettävissä, kuten esim. sääntö, joka
täsmää joka N:nteen pakettiin jne.


En ole itse tällaista kokeillut, mutta pohdin kerran vähän vastaavaa
tilannetta:

Junassa, kahvilassa, lentokentällä, tms. paikassa on ilmainen wlan, mutta
mukana on myös kännykkä, jossa on joku 3G/4G-netti. Halutaan mahdollisimman
nopea ja hyvin toimiva yhteys firman vpn:ään. Miten saadaan molemmat
nettiyhteydet hyötykäyttöön samanaikaisesti ja siten että ei haittaa, jos
toinen katkeaa?

Miten tällainen viritys pitäisi rakentaa? Saattaa olla, että on
olemassa vpn-palvelin, joka ei välitä tulevan udp-paketin ip-osoitteesta
vaan katsoo paketin sisältä onko se ok. Näin voisi ehkä etäkoneella
kuormaa tasaamalla saada lisää nopeutta toiseen suuntaan, mutta
se ei auttaisi muuten, koska paketit palvelimelta takaisin
kulkisivat vain toisen yhteyden kautta.

Olisi ehkä mahdollista avata kaksi erillistä vpn-yhteyttä, yksi kummankin
yhteyden kautta ja sitten yhdistää nämä bonding-ajurilla. Tässä
tapauksessa kumpikaan vpn-yhteyksistä ei saisi päätyä
suoraan firman sisäverkkoon, vaan ne pitäisi tietysti
yhdistää bonding-ajurilla myös toisessa päässä. Mutta tekeekö
mikään vpn-palvelinsofta omaa tun/tap-laitetta palvelinpäähän per yhteys,
jotta bonding-ajuria voisi käyttää? Joutuisinko siis ajamaan kahta vpn-
palvelinta käyttäjää kohti?

Muita vaihtoehtoja? Viritetään molempien yhteyksien kautta GRE
(tai vastaava) tunneli, yhdisteään nämä bonding-ajurilla ja
sitten vpn-yhteys sen kautta? En tiedä toimisiko.
Reijo Korhonen
2017-02-12 21:47:09 UTC
Permalink
Post by Mikko Tuumanen
Post by Reijo Korhonen
Näyttäisi siltä, että jäinkin kahden isp:n loukkuun.
Miten tälläiset kuorman tasaukset/optimoinnit säädetään linuxissa?
Luodaan toinen reititystaulu. Näin saadaan toinenkin oletusreitti,
(siis "gateway" tai "default route") eli voidaan käyttää molempia
yhteyksiä samanaikaisesti.
Tämän jälkeen on luotava jonkinlaiset säännöt sille, mitkä yhteydet
reititetään milläkin reititystaululla. Sääntö voi olla yksinkertainen,
eli osoitteen tai verkkoliitännän perusteella, mutta tässä tapauksessa
mielenkiintoisempi on MARK-vaihtoehto, eli reititystaulun valinta
iptablesin tekemän merkinnän perusteella.
Tämä mark-vaihtoehto tulee usein esille, kun etsii netistä ohjeita.
Post by Mikko Tuumanen
Näin isp:n valinta saadaan tehtäväksi iptablesilla ja siellähän on
erilaisia kikkoja käytettävissä, kuten esim. sääntö, joka täsmää joka
N:nteen pakettiin jne.
Sellainen sääntö tietenkin kuormantasauksessa olisi hyvä, että http-
lukupyyntö aina sille yhteydelle, joka on vastannut viime ajat nopeammin.
Mutta ei taida iptablesin tasolle saada tilastointia.

Miten muuten https-yhteys toimii siinä mielessä, että tykkääkö se
kyttyrää kun paketit alkavatkin tulla välillä toiselta IP:ltä? Luulisin
että kyllä, ihan niin kuin mikä tahansa tcp-liiikenne, sehän on portista
porttiin ja koneeni ip-numerohan vaihtuu kun yheydessä siirrytään
toiselle palveluntarjoajalle. http-liikenteessä sen sijaan "istunto" on
pyyntö-vastauspari joten siinä eiu taida olla väliä, vaikku sivun osat
latautuisivat vaikka kuinka monen palveluntarjoajan kautta.

Jos pääsen tässä kokeiluvauheeseen, niin enpä taida kokeilla tunnelia
ensimmäiseksi. Mutta pitää saada aikaa ensin siirtää laitteita
sisäverkossa toimivan modeemin taakse ja sitten resetoida varayhteyden
modeemi joka lakkasi reitittämästä sisäverkosta ulos, vaikka muuten
toimiikin.
--
***@iki.fi.nospam.invalid
http://www.iki.fi/Reijo
Mikko Tuumanen
2017-02-16 06:27:26 UTC
Permalink
Post by Reijo Korhonen
Miten muuten https-yhteys toimii siinä mielessä, että tykkääkö se
kyttyrää kun paketit alkavatkin tulla välillä toiselta IP:ltä? Luulisin
Https-yhteys on tcp-yhteys ja tcp-yhteys on aina kahden osoite+portti-parin
välillä. Näin ollen yhden tcp-yhteyden paketteja ei voi mennä lähettämään
"väärään" osoitteeseen. On siis joko viritettävä jonkinlainen tunneli tai
sitten vaan hoidettava koko tcp-yhteys saman isp:n kautta.
Post by Reijo Korhonen
http-liikenteessä sen sijaan "istunto" on
pyyntö-vastauspari
Termi istunto on joka tapauksessa aika epämääräinen, mutta en sanoisi, että
istunto tarkoittaisi missään yhtä pyyntö-vastausparia, vaan pikemminkin
http-tapauksessa useampaa toisiinsa liittyvää pyyyntö-vastausparia.
Kysymys on kuitenkin aiheellinen. Jotkut verkkopalvelut saattavat
hyväksyä sen, että saman istunnon (joka tunnistetaan esim. keksillä),
eri pyynnöt tulevat eri osoittesita. Joillekin toisille se ei sitten
kelpaakaan. Jos saat tuollaisen kahden ips:n kuormantasauksen käyttöön,
olisikin mielenkiintoista kuulla missä tilanteissa se toimii ja missä ei.

Toimimattomille voi luultavasti jotenkin lisätä säännön, että aina saman
yhteyden kautta.
Ari Saastamoinen
2017-02-16 20:19:18 UTC
Permalink
Post by Mikko Tuumanen
Post by Reijo Korhonen
Miten muuten https-yhteys toimii siinä mielessä, että tykkääkö se
kyttyrää kun paketit alkavatkin tulla välillä toiselta IP:ltä? Luulisin
Https-yhteys on tcp-yhteys ja tcp-yhteys on aina kahden osoite+portti-parin
välillä. Näin ollen yhden tcp-yhteyden paketteja ei voi mennä lähettämään
"väärään" osoitteeseen. On siis joko viritettävä jonkinlainen tunneli tai
sitten vaan hoidettava koko tcp-yhteys saman isp:n kautta.
Post by Reijo Korhonen
http-liikenteessä sen sijaan "istunto" on
pyyntö-vastauspari
Ei HTTP yhteys eroa HTTPS yhteydestä tuossa suhteessa millään tavalla.
Molemmat käyttävät tilallista TCP:tä, ja yhden (TCP)-yhteyden aikana
IP-ei saa vaihtua. HTTPS:ssä on erona vain se, että tuon TCP-yhteyden
avaamisen jälkeen se juttelee vähän extraa (avaintevaihdon vuoksi)
ennenkuin varsinaista dataa voi liikuttaa.
--
Arzka oh3mqu+***@hyper.fi - En halua follareita mailina
1. Valitse sopiva paikka, ei ihmisten tai rakennusten lahella, jossa
paukku voi aiheuttaa hairiota. - Iso-Kiinalaisen kayttoohje
Reijo Korhonen
2017-02-16 22:42:20 UTC
Permalink
Post by Ari Saastamoinen
Post by Mikko Tuumanen
Post by Reijo Korhonen
Miten muuten https-yhteys toimii siinä mielessä, että tykkääkö se
kyttyrää kun paketit alkavatkin tulla välillä toiselta IP:ltä? Luulisin
Https-yhteys on tcp-yhteys ja tcp-yhteys on aina kahden
osoite+portti-parin välillä. Näin ollen yhden tcp-yhteyden paketteja ei
voi mennä lähettämään "väärään" osoitteeseen. On siis joko viritettävä
jonkinlainen tunneli tai sitten vaan hoidettava koko tcp-yhteys saman
isp:n kautta.
Post by Reijo Korhonen
http-liikenteessä sen sijaan "istunto" on pyyntö-vastauspari
Ei HTTP yhteys eroa HTTPS yhteydestä tuossa suhteessa millään tavalla.
Molemmat käyttävät tilallista TCP:tä, ja yhden (TCP)-yhteyden aikana
IP-ei saa vaihtua. HTTPS:ssä on erona vain se, että tuon TCP-yhteyden
avaamisen jälkeen se juttelee vähän extraa (avaintevaihdon vuoksi)
ennenkuin varsinaista dataa voi liikuttaa.
Kyllä kyllä, mutta https istunto on oikea istunto, joka alkaa, kestää
yleensä pitkään saman istunnon sisällä sisältäen paljonkin liikennettä
jsa sitten puretaan eli loppuu. Esimerkiksi yhteys verkkopankkiin. Tai
loppuu implisiittisesti kun lisää pyystöjä ei tule eli sisältää timeoutin.

http-pyyntö, usein get sen sijaan saa vastauksen. sitten tehdään uusi
get, istuntoa ei ole ja selain voisi tehdä seuraavan getin toisesta
ip:stä ja http-serveri antaisi siihen vastauksen, sillä ei http-serveri
välitä mistä pyynnöt tulevat, se vaan vastailee. Luulenpa että samaan
aikaa samalle serverille voisi olla auki kaksi tcp-yhteyttä, jotka
vuorotellen pommittaisivat serveriä saman sivun eri osien
latauspyynnöillä tai muuten vaan tilannetta erottelemmtta pyytävät
tavaraa getilllä, niin serveri vaan vastailee ja selain rakentaa
vastauksista sujuvasti sivut, saihan se vastaukset.

https-istunnossa sen sijaan istunto alkaa raskaahkolla
avaintarkistuksella. Sen jälkeen istunto on alkaa tuohon porttiin
molemmin päin. Jos nyt käyttöisin toista isp:tä tuohon istuntoon, niin se
ei voi millään onnistua, sillä se menee pakostakin serverille eri
porttiin eikä tuohon alkuperäiseen istuntoon, eli alkaa toinen istunto
eri porttiin ja aika fakiirisofta saisi olla, että keksisi että kahdessa
portissa on nyt loogisesti yksi istunto, jossa asiakkaana on sama
instanssi.
--
***@iki.fi.nospam.invalid
http://www.iki.fi/Reijo
Ari Saastamoinen
2017-02-17 00:51:39 UTC
Permalink
Post by Reijo Korhonen
Post by Ari Saastamoinen
Ei HTTP yhteys eroa HTTPS yhteydestä tuossa suhteessa millään tavalla.
Molemmat käyttävät tilallista TCP:tä, ja yhden (TCP)-yhteyden aikana
IP-ei saa vaihtua. HTTPS:ssä on erona vain se, että tuon TCP-yhteyden
avaamisen jälkeen se juttelee vähän extraa (avaintevaihdon vuoksi)
ennenkuin varsinaista dataa voi liikuttaa.
Kyllä kyllä, mutta https istunto on oikea istunto, joka alkaa, kestää
yleensä pitkään saman istunnon sisällä sisältäen paljonkin liikennettä
jsa sitten puretaan eli loppuu. Esimerkiksi yhteys verkkopankkiin. Tai
loppuu implisiittisesti kun lisää pyystöjä ei tule eli sisältää timeoutin.
http-pyyntö, usein get sen sijaan saa vastauksen. sitten tehdään uusi
get, istuntoa ei ole ja selain voisi tehdä seuraavan getin toisesta
ip:stä ja http-serveri antaisi siihen vastauksen,
Ei HTTPS:ssä ole tuossa suhteessa MITÄÄN eroa HTTP:hen. Yhteys pysyy
auki keepalive-timeoutin verran, ja jos siinä ajassa ei tule uutta
pyyntöä, niin yhteys laitetaan poikki. Tyypillisessä konfiguraatiossa
toi keepalive-timeout on ihan saman mittainen (samalla serverillä)
sekä HTTP:ssä että HTTPS:ssä, ja esim. cPanel-järjestelmissä tuon
pituus on oletusarvossaan viisi sekuntia. Ja vanilla-apachessakin on
muistaakseni sama oletusarvo. Ja jos palvelimella on paljon kuormaa,
niin tuota oletusarvoa on todennäköisesti jopa pienennetty.
Post by Reijo Korhonen
https-istunnossa sen sijaan istunto alkaa raskaahkolla
avaintarkistuksella.
Tuossa olet oikeassa, että avaintenvaihto on raskaampi operaatio kuin
salaamattoman HTTP-yhteyden avaus. Mutta muuten sulla ei näköjään ole
pienintäkään käsitystä siitä, miten webbipalvelut toimivat.
Post by Reijo Korhonen
molemmin päin. Jos nyt käyttöisin toista isp:tä tuohon istuntoon, niin se
ei voi millään onnistua,
Se voi onnistua tai voi olla onnistumatta - ihan samoin kuin pelkkää
HTTP:tä käytettäessä. Toi riippuu ihan siitä, miten webbipalvelun
sessionhallinta on toteutettu.
Post by Reijo Korhonen
eri porttiin ja aika fakiirisofta saisi olla, että keksisi että kahdessa
portissa on nyt loogisesti yksi istunto, jossa asiakkaana on sama
instanssi.
En tuota nyt fakiiritempuksi luonnehtisi, kun webbipalveluihin on
toteutettu sessionhallintaa kymmenillä eri tavoilla.
--
Arzka oh3mqu+***@hyper.fi - En halua follareita mailina
1. Valitse sopiva paikka, ei ihmisten tai rakennusten lahella, jossa
paukku voi aiheuttaa hairiota. - Iso-Kiinalaisen kayttoohje
Reijo Korhonen
2017-02-17 17:42:22 UTC
Permalink
Post by Ari Saastamoinen
Ei HTTPS:ssä ole tuossa suhteessa MITÄÄN eroa HTTP:hen. Yhteys pysyy
auki keepalive-timeoutin verran, ja jos siinä ajassa ei tule uutta
pyyntöä, niin yhteys laitetaan poikki.
Kyllä. ;ujtta tämä https-istunnos looginen taso on enenmmän kuin mitä on
http-yhteydessä. http-yhteydessä liikennöinti tapahtuu porttrien välillä
niin kauan kuin tavaraa liikkuu, mutta lopputuloksen kannalta ei ole
väliä vaikka yhteys katkeaisi ja otetaan vaikka toista kautta uusi
yhteys. Selain saa vastaukset ja rakentaa sivun.

https-istunto on oikea istunto ja ja yhteyden aikana tehdään sellasisia
asioita, joihin tuo yunnettu isyunnon aloittaja on okeutettu esimerkiksi
sisäänkirjautumisenn toikeuttamasna, mutta nuuta ei sitten tehdäkään. Jos
yhteys katkeaa, katseaa myöäs yhtreys ja toiminta loppuu siihen. Kun
käyttäjä ottaa uuden yhteuyen, niin istuntokin alkaa alusta. On
serveripäässä olevasta ohjlmistosta kiinni osaako se palata tilanteeseen,
jossa yheys katkesi.

Kahden isp:n tapauksessa nämä ovat eri tavalla haastavia tapauksia. On
aika selvää, että kun https-liikennissä on käsite sokewttiygteys voimassa
oleva istunto, niin samassa istunnossa on aika vaikea hyödyntää kahden
isp:n kautta kulkevia paketteja, sillä se merkitsee kahta samanaikaiksta
https-istuntoa ja on vaeka kuvitella että serveripään ohjelmisto millään
pystyisi niitä yhdistämään. Tälläiseen käyttötaspaukseen ei olla
varauduttu.

Mutta http-liikennöissä ei ole väliä, vaikka olisi kaksi porttia yhtä
aikaa auki samalle serverille. Ei ole väliä kumpaan get-pyynnöt mernevät,
sillä selöain odottaa osottavat vain vastausta ja serveri on halukas
vastaamaan, tuli pyuybtö kumman tahansa soketin kautta.

Tosin en usko, että selainohjelmat avaisivat samallöe serverille samasta
sivusta montaa sokettia, jolloin kuormantasaus ei taida aiheuttaa sitä
että tämä tilanne syntyisi. Sen sijaan www-sivu voi olla rakennettu ja
nykyään onkin hyvin usein rakennettu että sivun tavara haetaan usealta
serveriltä. Ainakin ne mainokset tulevat ihan erio serveriltä. Silloin
kuormantasauksesta voi olla hyötyä, sillä tavaraa haetaan kahden eri
isp:n kautta yhtä aikaa eri servereiltä.

En osaa sanoa, miten MARK-luormantasaus toimii. Parhaiten ja virmimmin se
minustra topimisi, jos se paketti, joka ottaa yhtreyden serverille,
merkitään. Kun serveri hyväksyy tcp-yhteyden, niin silloin alkaa se
liikenne, josta Ari puhuu. Silloin liikenne siirtyy eri porttiin. Jos nyt
tässä vaijeessa kuomantasaus ei enää vaihtele sitä, mille serverille
liikenne menee ja miksi vaihtelisi, sokettihan on auki, eikä soketissa
voi olla kuin kaksi päätä, niin kaikki menee hyvin. Kun asiaa ajattelee
tältä kannalta, niin vaikka kuorm,antasaus olisi päällä, sen pitäisi
toimi yhtä hyvin http- ja https-liikenteessä.

Runneleissakaan ei pitäisi olla ongelmia, mutta tunnelia ei voine millään
rakentaa niin, että liikenne kulkisi yhtä aikaa kahden isp:n kautta. Tai
voi, mutta tuollaisen ohjelmiston testaaminen on varsin hankalaa ja siis
kallista ja kun kysyntä on taatusti minimaalista, niin luulenpa että
tunneliohjelmistot käyttävät aina yhtä ja samaa isp:tä tunnelin
olemassaolon ajan, vaikka koneessa olisi kuorm,antasaus, mutta
kuormantasaus voi vaikuttaa siihen, kumman isp:n kautta tunnelia sillä
kertaa aletaan rakentamaan.
--
***@iki.fi.nospam.invalid
http://www.iki.fi/Reijo
Reijo Korhonen
2017-02-17 17:55:00 UTC
Permalink
Post by Ari Saastamoinen
Tuossa olet oikeassa, että avaintenvaihto on raskaampi operaatio kuin
salaamattoman HTTP-yhteyden avaus. Mutta muuten sulla ei näköjään ole
pienintäkään käsitystä siitä, miten webbipalvelut toimivat.
Sanoisin että sinulla ei ole mitään käsitystä miten wrpppipalvelut
toimivatt, kun et ole huomannut, että esimerkiksi pankkipalveluja ei
tosiaankaan rakenneta http-yhteyden varaan. Joten kyllä noissa
yhteystavoissa on aika iso periaatteelinen ero, vaikka molempia
käytetäänkin ihan samalla selaimella, jossa ne näyttävät samalta.

Keskustelu muistuttaa jo sotimista, joten sinne.
--
***@iki.fi.nospam.invalid
http://www.iki.fi/Reijo
Juhani Varemo
2017-02-18 09:44:13 UTC
Permalink
Post by Reijo Korhonen
Post by Ari Saastamoinen
Tuossa olet oikeassa, että avaintenvaihto on raskaampi operaatio kuin
salaamattoman HTTP-yhteyden avaus. Mutta muuten sulla ei näköjään ole
pienintäkään käsitystä siitä, miten webbipalvelut toimivat.
Sanoisin että sinulla ei ole mitään käsitystä miten wrpppipalvelut
toimivatt, kun et ole huomannut, että esimerkiksi pankkipalveluja ei
tosiaankaan rakenneta http-yhteyden varaan. Joten kyllä noissa
yhteystavoissa on aika iso periaatteelinen ero, vaikka molempia
käytetäänkin ihan samalla selaimella, jossa ne näyttävät samalta.
Pysyn nyt vielä täällä asiapuolella.

Käsite www-selailu on niin laajakirjoinen että lienee mahdotonta sanoa
mitään yksikäsitteistä.

Staattisten sivujen latailu yksitellen ei varmaan ole gatewayn vaihtumisesta
moksiskaan.

Käyttäjän tunnistava palvelu tuskin siitä tykkää. Toki nuo ovat kaikki jo
https ja pitääkin olla.

Jonkin live-streamin tms siirto http:n yli ei välttämättä jummarra kahta eri
reittiä käyttäjän koneelle

Https on selvä tapaus, se on no way.

Kuormanjako on helppoa jos voidaan jakaa eri käyttäjien tai eri prosessien
liikennettä. Failover on myös selvä tapaus. Mutta yhden ja saman prosessin
liikenteen tasaaminen vaatisi kai jotakin tukea myös niiden linjojen
toisessa päässä? Linjoista pitäisi muodostaa jonkinlainen läpinäkyvä
'trunk'. Eli jos katsoo leffaa Netflixistä, niin sitä siirtoa ei ihan
helpolla jaeta tasan kahdelle eri yhteydelle? Vaimo voi kyllä katsella
toista leffaa toisella vapaalla yhteydellä.

Palvelinyhteyksillä muistan että olen tehnyt sisääntulevien pyyntöjen tyhmää
jakoa DNS:n round-robinilla. Eli sulle-mulle-sulle-mulle...
Menetelmä ei ole kovin toimiva, kiitos mm DNS-cachen ja muun vastaavan.
Toimii parhaiten kun tarkastellaan pitkää aikaväliä ja suurta määrää
käyttäjiä. Minuutin aikana tulevaa yllättävää liikennepursketta se ei tasaa,
mutta koko vuorokauden aikana olevaa tasaista virtaa kyllä.
Ari Saastamoinen
2017-02-18 12:50:07 UTC
Permalink
Post by Juhani Varemo
Käyttäjän tunnistava palvelu tuskin siitä tykkää. Toki nuo ovat kaikki jo
https ja pitääkin olla.
Jos sessionhallintaan on ympätty mukaan myös asiakkaan IP-niin ei
toimi, mutta taitaa suurin osa toteutuksista olla sellaisia, jotka ei
IP:tä vertaa.
Post by Juhani Varemo
Jonkin live-streamin tms siirto http:n yli ei välttämättä jummarra kahta eri
reittiä käyttäjän koneelle
Ainakin joku jonkun flash-playerin käyttämä protokolla näytti olevan
sellainen, että se teki ihan webbirequestin, jossa pyysi pientä pätkää
videosta kohdasta X alkaen. Ja sitten pyysi seuraavaa jne...

Tuollainen toiminee ihan hyvin ja jokainen noista pikkurequesteista
tuliskin eri IP:stä.

Mutta jos taas kyseessä olisi esim. RTP-striimi, niin sen
reitittäminen noin ei oikein näppärästi onnistuisi.
Post by Juhani Varemo
Https on selvä tapaus, se on no way.
Kuten ekassa kohdassa. Jos sessionhallinnassa, on IP-vertailu eri
requestien välillä, niin ei toimi, mutta luullakseni suurin osa
toteutuksista on sellaisia, jotka ei vertaa (Kun joillain
operaattoreilla on pakkoproxyklustereita, niin palvelu ei toimisi
sellaisen läpi ihan kauhean hyvin jos se olisi liian ronkeli
IP-osoitteista)
--
Arzka oh3mqu+***@hyper.fi - En halua follareita mailina
1. Valitse sopiva paikka, ei ihmisten tai rakennusten lahella, jossa
paukku voi aiheuttaa hairiota. - Iso-Kiinalaisen kayttoohje
Juhani Varemo
2017-02-18 13:06:51 UTC
Permalink
Juu nämä menevät varmaan niin että enimmäkseen toimii. Mutta jos siihen
alkaa luottaa sataprosenttisesti niin varmaan löytää jonkin sellaisen
palvelun joka sitten ei toimikaan, ja tietämättömällä käyttäjällä saattaa
sitten olla ihmettelemistä.

Selaimella käytetään ja ohjataan nykyään internetin yli melko
turvallisuuskriittisiäkin juttuja :-/
Reijo Korhonen
2017-02-19 11:50:38 UTC
Permalink
Post by Juhani Varemo
Post by Reijo Korhonen
Post by Ari Saastamoinen
Tuossa olet oikeassa, että avaintenvaihto on raskaampi operaatio kuin
salaamattoman HTTP-yhteyden avaus. Mutta muuten sulla ei näköjään ole
pienintäkään käsitystä siitä, miten webbipalvelut toimivat.
Sanoisin että sinulla ei ole mitään käsitystä miten wrpppipalvelut
toimivatt, kun et ole huomannut, että esimerkiksi pankkipalveluja ei
tosiaankaan rakenneta http-yhteyden varaan. Joten kyllä noissa
yhteystavoissa on aika iso periaatteelinen ero, vaikka molempia
käytetäänkin ihan samalla selaimella, jossa ne näyttävät samalta.
Pysyn nyt vielä täällä asiapuolella.
Asiapuolella pysyen asiatkin pysyvät selkeinä eikä eksytä puhumaan asian
vierestä tai aidan seipäistä. Oma alkuperäinen näkökulmani oli kahdesn
isp:n hyödyntäminen kun kerran sellaiseen tilanteeseen olen ajautunut.
Hyvä että tämä näkökulma on esille eli kiitos siitä. Aidanseipäistä
voinee keskustella muissa keskustelupuissa jos siihen on tarvetta.
Post by Juhani Varemo
Käsite www-selailu on niin laajakirjoinen että lienee mahdotonta sanoa
mitään yksikäsitteistä.
Totta. Sivussa on monta elementtiä ka ne haetaan usein eri servereiltä.
Selain yhdistää saadut elementit parhaansa mukaan.
Post by Juhani Varemo
Staattisten sivujen latailu yksitellen ei varmaan ole gatewayn
vaihtumisesta moksiskaan.
Niin minäkin ajattelen. Maailma oli yksinkertainen kun vain näitä oli.
Post by Juhani Varemo
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. Kuormantasaus ei siis voi toimia niin, että
kesken istunnon kuormaa tasataan tähän istuntoon kuuluvissa yheyksissä
toiselle isp:lle. Tai voi toimia, mutta silloin toimii väärin. Silloin
palveluntarjoahan oikein toimiva serveri katkaisee toimet havaitessaan
väärinkäytön, jos palvelu on turvalliseksi rakennettu.
Post by Juhani Varemo
Jonkin live-streamin tms siirto http:n yli ei välttämättä jummarra kahta
eri reittiä käyttäjän koneelle
Tämänkin voi ajatella istunnoksi. Kyseessä on palvelu joka alkaa kun
striimi avataan ja tässäkin yhteyskäsite menee korkeammalle tasolle kuin
pelkkä sokettiyhteys. Tai voi mennä, riippuu toteutuksesta. Jos koko
striimi tulee yhden auki olevan sokettiyhteyden kautta ja kuormantasaus
ei varmaankaan sokettiyhteyttä mene siirtämään minnekään ensinnäkään
koska se on tehnisesti aikia vaikeaa tai oikeasti mahdotonta, sillä
dynaamisen soketin käsitettä ei taida olla olemassa, vaaan soketti on
käsite, jossa IP-numero ja porttinumero ovat kiinteitä sokettiyhteyden
avaamisen jälkeen.

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ää.
Post by Juhani Varemo
Https on selvä tapaus, se on no way.
Juuri näin, isp ei voi vaihtua istunnon aikana, Mutta esim.
pankkipalveluissa se ei vaihdu, sillä kaikki vastaukset tulevat samalta
serveriltä. Näin oletan. Eikä kuormantasauskaan siirtele auki olevia
sokettyhteyksiö isp:ltä toiselle ja sokettihan on auki koko https-
istunnon ajan. Mutta jos oletan väärin, kertokaa sellainen https-yhteyden
avulla toteutettu tunnistusta käyttävä palvelu jossa näette
potentiaalisen ongelman.
Post by Juhani Varemo
Kuormanjako on helppoa jos voidaan jakaa eri käyttäjien tai eri
prosessien liikennettä. Failover on myös selvä tapaus. Mutta yhden ja
saman prosessin liikenteen tasaaminen vaatisi kai jotakin tukea myös
niiden linjojen toisessa päässä? Linjoista pitäisi muodostaa
jonkinlainen läpinäkyvä 'trunk'. Eli jos katsoo leffaa Netflixistä, niin
sitä siirtoa ei ihan helpolla jaeta tasan kahdelle eri yhteydelle? Vaimo
voi kyllä katsella toista leffaa toisella vapaalla yhteydellä.
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
kuormanjakoajohan on toteutettu ip-tables tasolla eli aika alhaisella
tasolla. Perustapahan on mark eli merkitä lähteviä ja tulevia paketteja.
Tuo Mark pitäisi tehdä siellä ylempien käsitteiden käyttökohdassa eli
ohjelmistoissa ja siellä merkitä samaan kuuluva liikenne
yksikäsitteisellä merkillä. Tälläisen toteutus käsittääkseni puuttuu eikä
tämän tason kuormantasausta/liikenteenohjausta ole. Jos olisi, niin
esimerkiksi tunnelin tekeminen eri isp:den kautta jopa samanaikaisesti
olisi mahdollista, mutta mykypäivänä ei taida olla.
Post by Juhani Varemo
Palvelinyhteyksillä muistan että olen tehnyt sisääntulevien pyyntöjen
tyhmää jakoa DNS:n round-robinilla. Eli sulle-mulle-sulle-mulle...
Menetelmä ei ole kovin toimiva, kiitos mm DNS-cachen ja muun vastaavan.
Toimii parhaiten kun tarkastellaan pitkää aikaväliä ja suurta määrää
käyttäjiä. Minuutin aikana tulevaa yllättävää liikennepursketta se ei tasaa,
mutta koko vuorokauden aikana olevaa tasaista virtaa kyllä.
Eikös tämä ole päinvstainen ongelma kuin minulla, eli minä pyrin jakamaan
ulosmeneviä palvelupyyntöjä kahdelle eri isp:lle, jolloin vastauksetkin
tulevat kahdelta eri isp:ltä, aina siltä joka olisi nopeampi toimittamaan
vastauksen. Mutta ei siinäkään taida olla parempaa vaihtoehtoa kuin antaa
hommia vuorotellen kummallekin isp:lle. Minun ongelmassani cachetetusta
dns:stä ei luulisi olevan mitään ongelmaa vaan se sama hyöty joka dns:n
cachetuksesta yleenskäkin on.
--
***@iki.fi.nospam.invalid
http://www.iki.fi/Reijo
Ari Saastamoinen
2017-02-19 18:13:39 UTC
Permalink
Post by Reijo Korhonen
Post by Juhani Varemo
Post by Reijo Korhonen
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)
Post by Reijo Korhonen
Post by Juhani Varemo
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.
Post by Reijo Korhonen
Post by Juhani Varemo
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.
Post by Reijo Korhonen
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.
Post by Reijo Korhonen
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.
Post by Reijo Korhonen
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.
Post by Reijo Korhonen
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.
Post by Reijo Korhonen
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)
Post by Reijo Korhonen
Post by Juhani Varemo
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.
Post by Reijo Korhonen
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+***@hyper.fi - En halua follareita mailina
1. Valitse sopiva paikka, ei ihmisten tai rakennusten lahella, jossa
paukku voi aiheuttaa hairiota. - Iso-Kiinalaisen kayttoohje
Reijo Korhonen
2017-02-19 20:18:11 UTC
Permalink
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)
Minullahan ei ole vielä mitään kuormantasausimplementaatiota käytössä.
Mutta jotta voisimme puhua jostakin konkreettisets, kerron parhaatg ja
realistisemmat kuormantasauksetg jotka olen löytänyt

<http://serverfault.com/questions/93678/load-balancing-nat-ing-multiple-
isp-connections-on-linux>

Mark-menetelmä (CONNMARK mangling ) perustuu ip-tables-tauluun per isp.
Shorewall taas toteuttaa tämän, kunhn kaikki vaan määritellään sen
määrirtyksiin

<http://www.shorewall.net/MultiISP.html>

Shorewall on sen takia lupaava, että kun se tarjoaa toteutuksen, se ei
ole herkkä kirjoitusvirheille eikä unohduksille. Vaikka tietysti
säätötoiedostot pitää laittaa oikein, mutta jos ei heti mene oikein, niin
säätätiedostoja on paljon helpompi säätää kuin itse tehtyjä skriptejä.

Siinä on jopa tunnelisäätö (vpn), joten tuntuu että se ottaa kantaa
kaikkiin tässä keskustlupåuussa esitettyihin kysymyksiin. Jos ja kun
kahden isp:n kuormantasauksen toteutun, toteutan sen shorewallin avulla.
Si8llä taitaa olla paras tuki, vaikka se ei kaupallinen ohjelmisto
olekaan, vaan hommaa vetää yksi kaveri harrastuksenaan, ja luulenpa että
hänellä on reitityksestä paras asiantuntemus tällä hetkellä maapallolla
elossa ollevista ihmisistä.
--
***@iki.fi.nospam.invalid
http://www.iki.fi/Reijo
Ari Saastamoinen
2017-02-19 20:39:02 UTC
Permalink
Post by Reijo Korhonen
olekaan, vaan hommaa vetää yksi kaveri harrastuksenaan, ja luulenpa että
hänellä on reitityksestä paras asiantuntemus tällä hetkellä maapallolla
elossa ollevista ihmisistä.
Melko rohkea epäily. Linked-In -profiilin perusteella vaikuttaa ihan
pätevän oloiselta kaverilta, mutta ei ole työkokemusta
esim. verkko-operaattorihommista, joten en usko, että pääsee edes
top10:iin reitysasiantuntijoista. (Tosin tällä nyt ei liene mitään
relevanssia tähän puheena olevaan asiaan :)
--
Arzka oh3mqu+***@hyper.fi - En halua follareita mailina
1. Valitse sopiva paikka, ei ihmisten tai rakennusten lahella, jossa
paukku voi aiheuttaa hairiota. - Iso-Kiinalaisen kayttoohje
Reijo Korhonen
2017-02-21 17:44:23 UTC
Permalink
Post by Ari Saastamoinen
Post by Reijo Korhonen
olekaan, vaan hommaa vetää yksi kaveri harrastuksenaan, ja luulenpa
että hänellä on reitityksestä paras asiantuntemus tällä hetkellä
maapallolla elossa ollevista ihmisistä.
Melko rohkea epäily. Linked-In -profiilin perusteella vaikuttaa ihan
pätevän oloiselta kaverilta, mutta ei ole työkokemusta esim.
verkko-operaattorihommista, joten en usko, että pääsee edes top10:iin
reitysasiantuntijoista. (Tosin tällä nyt ei liene mitään relevanssia
tähän puheena olevaan asiaan :)
Tietenkin jokaisella on omatg rtarpeensa ja niitä tarpeita on varsin
erikoisiakin ja erikoistn terpeiden toteuttamiseen tarvitaan
erikoisihmisiä ja erkoisohjelmia. Joten mikä tai kuka kenenkin mielestä
on paras on varsin henkilökohtainen valinta. Itse en linkefinille laita
tässä tapauksessa painoa ja sehän on suosituimmuuskalenteri ja
tälläisessa kalenterissa suosituin on harvoin paras.

Mutta jos on jaksanut toteuttaa systeemin, jossa kaikki toiminnallisuus
saadaan määrirtelty järkevästi ja ymmärrettästi jaoteltujen ja
määriteltyjenm määritettelytioedostojen avulla ja vielä jaksaa tehdä
tästä tuotteen joka palvelee muita ja vastailla kysymyksiin ja päivittää
systeemiään muiden tarpeiden mukaan, niin kyllä pakostakin tulee varsin
hyväksi asiantuntijaksi. Kelpaa minulle. Ja aika monelle muulle.
Varsinkaan kun ei maksa mitään. Shorewallia en ehkä säätäisi työnantajan
verkkoon. Kotiini kyllä.

Minulle kelpaa kyllä kolmenneksitoistaklin paras maailmalla, jos tuote
on samaa tasoa kuin shorewall ;-)
--
***@iki.fi.nospam.invalid
http://www.iki.fi/Reijo
Ari Saastamoinen
2017-02-21 17:58:50 UTC
Permalink
Post by Reijo Korhonen
on paras on varsin henkilökohtainen valinta. Itse en linkefinille laita
tässä tapauksessa painoa ja sehän on suosituimmuuskalenteri ja
tälläisessa kalenterissa suosituin on harvoin paras.
Mikä ihmeen suosituimmuuskalenteri? Sinne jengi ite laittaa
työkokemuksensa, ja monesti myös koulutuksensa. Mitä tekemistä CV:llä
on suosituimmuuden kanssa?
--
Arzka oh3mqu+***@hyper.fi - En halua follareita mailina
1. Valitse sopiva paikka, ei ihmisten tai rakennusten lahella, jossa
paukku voi aiheuttaa hairiota. - Iso-Kiinalaisen kayttoohje
Reijo Korhonen
2017-02-21 22:38:55 UTC
Permalink
Post by Ari Saastamoinen
Post by Reijo Korhonen
on paras on varsin henkilökohtainen valinta. Itse en linkefinille laita
tässä tapauksessa painoa ja sehän on suosituimmuuskalenteri ja
tälläisessa kalenterissa suosituin on harvoin paras.
Mikä ihmeen suosituimmuuskalenteri? Sinne jengi ite laittaa
työkokemuksensa, ja monesti myös koulutuksensa. Mitä tekemistä CV:llä
on suosituimmuuden kanssa?
Se että siellä voi kehua kaveria. Tai kerätä itselleen
virtuaalikavereita. LinkedIn on tyypilllinen some-sivusto, hyvine ja
huonoine puolineen. Noissa ei tietenkään ole mitään varmuutta että siellä
edes on jonkin alan maailman paras, sillä sellaisten ei tarvitse
vaivautua. Totta kai noissa on kärjessä innokkaimmat, ei parhaat. Tai
extrovertit eli ulospäibsuuntautuneet sählääjät, vaikka tällä alalla
introvertit tekevät parempaa jälkeä. Tosin en usko että jos ei ole
vaihtamassa työpaikkaa, niin jaksaa nähdä vaivaa profiilinsa
rakentamisessa. Mutta onhan meitä moneksi.
--
***@iki.fi.nospam.invalid
http://www.iki.fi/Reijo
Ari Saastamoinen
2017-02-22 02:11:55 UTC
Permalink
Se että siellä voi kehua kaveria. Tai kerätä itselleen
virtuaalikavereita.
Niin noi. Emmä tuolta ikinä edes katto, että kuinka iso networkki siä
on. Jos sinne jotain tyyppiä etsiessä etsin, niin lähinnä kattelen
sitä, että missä se on ollu duunissa.

Ja toi koko virtuaalikaverijuttu on ihan typerä. Mä ainakin saan aina
silloin tällöin invitejä, mutta en hyväksy niistä kuin sellaiset
tyypit, jotka olen tavannu livenä useampaan kertaan.
--
Arzka oh3mqu+***@hyper.fi - En halua follareita mailina
1. Valitse sopiva paikka, ei ihmisten tai rakennusten lahella, jossa
paukku voi aiheuttaa hairiota. - Iso-Kiinalaisen kayttoohje
Reijo Korhonen
2017-02-23 20:09:08 UTC
Permalink
Post by Ari Saastamoinen
Ja toi koko virtuaalikaverijuttu on ihan typerä. Mä ainakin saan aina
silloin tällöin invitejä, mutta en hyväksy niistä kuin sellaiset tyypit,
jotka olen tavannu livenä useampaan kertaan.
Niin kai sen piti alun perin toimiakin. Muistan että palvelu ohjeisti
tuolla tavalla suhtautumaan kavepyyntöihin ja jopa rajoitti kelle saa
kaveripyyntöjä lähettää rli piti olla yhteistä historiaa. Ja niin minä
kevereita itse hyväksyn ja kutsun.

Mutta tuota voi joko kiertää tai sitten ehtoja on löysennetty, sillä
minullekin tulee kaveripyyntöjä sellaisilta joita en tunne, varsinkin
headhuntereilta, joilla sitten tuntuu olevan kavereita sitten niin
mahdottomasti. Ja jonkin listan kärkeen niillä klavereiden määrällä
ilmeisesti pääsee, silloinhan se kontaktiverkko on ainakin
laskennallisesti valtava eli extroverttipisteet huipussa, joka jossakin
duunissa voi olla plussaa ja ainakin headhunterihommassa taatusti onkin.

Sitten on niitä jotka julkaisevat tyhjänpäiväisiä artikkeleita ja jopa
näin mainostavat omaa koulutusbisnestään. Tuollakin tavalla ilmeisesti
pääsee jonkin listan kärkeen.

Ehkä LinkedIn helpottaa oikean tyypin palkkaamista töihin tai sittten
vaikeuttaa, en tiedä. Mutta ehkä parhaiten toimii se, että sinne voi
laittaa tiedoksi että haluaa vaihtaa työpaikkaa, niin tuo tieto leviää
tahoille joihin se ei välttämättä muuten leviäisi (jopa nykyisen
työnantajan tietoon). Ja luulen kuitenkin että kukaan ei LinkeInnin
perusteella sokkona ketään palkkaa, vaan vasta haastattelun ja
henkilökohtaisen tapaamisen pereusteella, joten luultavasti siinä
aiheessa seuloontuu hyvässä mielessä esille ne, jotka olisivat hyviä
valintoja, oli sitten hirveästi kevereita LinkedInnissä tai ei.
--
***@iki.fi.nospam.invalid
http://www.iki.fi/Reijo
Juha Häikiö
2017-03-24 19:06:18 UTC
Permalink
Post by Reijo Korhonen
Post by Ari Saastamoinen
Ja toi koko virtuaalikaverijuttu on ihan typerä. Mä ainakin saan aina
silloin tällöin invitejä, mutta en hyväksy niistä kuin sellaiset tyypit,
jotka olen tavannu livenä useampaan kertaan.
Niin kai sen piti alun perin toimiakin. Muistan että palvelu ohjeisti
tuolla tavalla suhtautumaan kavepyyntöihin ja jopa rajoitti kelle saa
kaveripyyntöjä lähettää rli piti olla yhteistä historiaa. Ja niin minä
kevereita itse hyväksyn ja kutsun.
Mutta tuota voi joko kiertää tai sitten ehtoja on löysennetty,
[ – – ]
Post by Reijo Korhonen
Sitten on niitä jotka julkaisevat tyhjänpäiväisiä artikkeleita ja jopa
näin mainostavat omaa koulutusbisnestään. Tuollakin tavalla ilmeisesti
pääsee jonkin listan kärkeen.
Ehkä LinkedIn helpottaa oikean tyypin palkkaamista töihin tai sittten
vaikeuttaa
Koulutusbisnesspämmit ovat oikeasti maanvaiva. Alkoivat ilmestyä
pari vuotta sitten.
--
Jurtsa
Reijo Korhonen
2017-02-16 22:24:56 UTC
Permalink
Post by Mikko Tuumanen
Jos saat tuollaisen kahden ips:n kuormantasauksen käyttöön,
olisikin mielenkiintoista kuulla missä tilanteissa se toimii ja missä ei.
Realistisimmalta kannanotolta kakden isp:n tvirittämiseen kuulöostaa eräs
vastaus. "Oletko ihan varma että haluat sitä ja kovastati?" Jatrkaen
niin, ettäö oletko almis säätämmä'm kaiken toimimattroman kuntoon. Omalta
kojdalötani sanoisin että en jahdesta isp:stä ihan ihan hirbestä hyösy.
vaikka tänäänkin sattui varmaankin varsin harvinainen tapaus eli pää-
isp:n yhteys oli alhaalla tunnin verran, mutta varayhteys oli ylhäällä,
mutta minulla ei ollut valmiina säätöjä joilla kotiverkon olisi saanut
käyttämään varayhtreyttä. Mutta kun yhteydet ivat yhtä nopeita ja
normaalistikaan yhjteys ei ole täynnä, niin en minä mitään mitattavaa
nopeushyötyä saane.

Mutta jospa kokeilisi ihan harrastuksen luoksi, tällä yhdellä koneella
ensin, niin en sotke kotioverkkoa. Kotiverkon sotkemisesta kun kotisärön
haittavaikutius on taatusti dekadin haitallisemoi kuin onnistumutkaan
nettiyjteuksien nopeuden nosta tai varmuuden lisäys.

Lupaavimmalta säätämisen kmmalta vakuttaa shorewall <http://
www.shorewall.net/MultiISP.html> Shorewallillöa saa tehtyä tuon mark-
ratkaisun pariin yksinkertaiseen säätötiedostoon, jonne kerroltasan mitä
halutaan, mutta shorewall tekee varsinaiset säädöt iptablesiin ja muihin
nettiliiikenteen säätötiedostoihin, joten kokeilussa ei mene
mahdottomasta aikaa säätämiseen ja varsinkaan säätöjen tarkistamiseen,
joka on aikaa vievää hommaa.
--
***@iki.fi.nospam.invalid
http://www.iki.fi/Reijo
Reijo Korhonen
2017-03-17 23:14:24 UTC
Permalink
Lupaavimmalta säätämisen kannalta vakuttaa shorewall <http://
www.shorewall.net/MultiISP.html> Shorewallillöa saa tehtyä tuon mark-
ratkaisun pariin yksinkertaiseen säätötiedostoon, jonne kerroltasan mitä
halutaan, mutta shorewall tekee varsinaiset säädöt iptablesiin ja muihin
nettiliiikenteen säätötiedostoihin, joten kokeilussa ei mene
mahdottomasta aikaa säätämiseen ja varsinkaan säätöjen tarkistamiseen,
joka on aikaa vievää hommaa.
Non ni, nyt on säädöt tehty lainauksessa mainitun shoreweallin mainion
esimerkin pohjalta, eli aika lailla toimii "out of the box". Ja henosti
muuten topimiikin, paremmin kuin kuvittelin. Minähän olen kahden
operaattorin sopimusloukussa. Molelemmilla dataa tulee sisään 10 Mbit/s.
Ja todellakin, kun nettinopeusmittarilla mittaa, niin kuormantasauksella
dataa tulee nyt sisään 20 Mbit/s, joka on sinänsä kummalista. Download ei
tule mittauskoneelta kokonaan saman operaattorin kautta eli ilmeisesti on
sen verran suuri aineisto, että sen lukupyynnöt voi jaksotella kahden
operaattorin reiteille ja vieläpä tasan. Silmämääräisestikin tarkastellen
nettiselailu on nopeutunut. Vai olla tietenkin psykologiostakin, sillä
jos ostat kalliin auton, niin eikös se tunnu liikkuvan vikkelästi ja
pehmeästi, vaiukka halvemopikin autoa saattaa liikkuka yhtä pehmeästi ja
vikkelästi ;-)

Öyhyt testijakso selätti pahimmat pelot eli sen, että kuormantasaus
rikkoisi istuntoja kun dataa tulee ha menee kahden operaatoprin reittejä
samalle serverille. Itseasiassa en vielä tiedä minkään toimivan huonosti
rli kaikki nettiliikenne näyttää toimivan kuten ennenkin, mutta
nopeammin. Nettipankkiyhteys näyttää toimivan OK, samoin Ylen Areenan TV-
kanavien katseselu, ja kokeilempa Youtubeakin <https://www.youtube.com/
watch?v=Fv3whtpfXLE> Hienosti toimii ja itse asiassa tuo video kertoo
englanninkielellä mikä Shotrwall on: Voit kuvata "policyn" jolle en tiedä
suomenkielistä vastinetta, mutta kuvata miten sen haluat toimivan, mutta
toteutusta ei tarvitse kuvata. Sitä voi katsella jos haluaa tietää mikä
shorewall on.

Säätämisessä oli muutama vaihe:
1) Verkkoarkkitehtuuri. Halusin langattonat yhteydet ettei ole turhia
johtoja. Turhat johdot aiheuttavat ääntä ja epämukavuutta. Eivät itse,
mutta ympäristöni turhiia johtoja kohdatessaan tekee niin, vaikka kuinka
yrittäisi kätkeä niitä mattojen alle ;-) Minulla onm siis lalsi wlan
kelpoista modeemia, toinen adsl-modeemi ja toinen kaapelimodeemi. Sekä
tietokoneessani kaksi wlan-laitetta, toinen sisäänrakennettu eli kortti
on koneen sisällä ja toinen pieni nysä usb-pistokkeessa. Yhdellä wlan-
laitteella ei saa yhteyttä kahteen wlan-tukiasemaan.

2)Pitää säätää IP-avaruudet niin, että ne eivät mene päällekkäin eli
aliverkkoja tulee minun tapauksessani kolme: br0 jossa eth0 ja pari
sisäistä virtuaalikonetta sekä muutama perheen tietokone. Sitten wlan0 ja
wlan1, kumpiklin omalle modeemilleen jotka johtava omalle
operaattorilleen internettiin. Nämä kolme laitetta vastaavat samalla
zoneja, joita ovat siis loc ja net ja net:ssä on kaksi laitetta ja noita
kahta laitetta vastaa kaksi provideria, joille määritellään Default
gateway. Ja säännöissä määritellään mark vastaamaan kumpaakin provoideria.

Ilman shorewalli verkkolaitteet nousevat opystyyn, mutta vain toisen
operaattorin reitti on pätevä, määrityksissähän on kaksi reittiä ulos ja
kaksi Deffaylt gatewayta. Kun käynnistää shorewallin, niin "route -n" ei
näytä ennä default gatewayta UG-tagilla, vaan kaksi yhteyttä UH-tagilla.
Se on merkki siitä, että kuormantasaus saattaa toimia. Ja toimiikin, jos
määritykset menivät oikein.

Tuossa määritykset yksinkertaisuudeszssaan ja sillä saa sulle/mulle 1:1
suhteessa tai muussakin suhteessajos providerien yhteydet ovat eri
nopeita.

Tuon lisäksi joutuu säätämään kliinteitä reittejä operaattoreiden
palvelimille sen mukaan, mitä palveluita käyttää. Tietekin aina pitää
kiinteästi säätää DNS-palvelukyuselyt oikean yhteyden kautta oikealle
operaattorille, sillä toisen operaatoottorin yhteyden kautta ei toisen
operaattorin nimipalvelu tietenkään vastaa. Sama juttu on ainakin
lähtevän postin kanssa. Operaattorien postipalvelimet eivät suostu
lähettämään postia kuin siitä verkosta jossa on heidän omia asikkaitaan
ainakaan ilman kirjautumista. Joka tapauksessa noista kiinteistä'
reiteistä ei haittakaan ole ja nopeuttavat toimintaa suoralla reitillä
operaattorin omille palvelimille joille ei voi päästä nopeammin muuta
reittiä.

Ei kuitenkaan kovin vaikeaa ja lopputulos shorewallin avulla on taatusti
parempi kuin jos itse rupeaa iptables-tauluja säätämään. Vaikka osaisi
periaatteet, niin jokin asia varmasti unohtuu. Tarkkana saa tosin olla
säätöjä tehdessään, sillä monta IP-numeroa tai osoiteavaruutta pitää
naputella. Minulla tuli yhden numeron virhe yhteen paikkaan ja etsin sitä
pitkää, Melkein toimi, mutta ei ihan, kun eksyi reitiltä. Toinen reitti
sen sijaan toimi, eli toimi joka toinen kerta ;-)
--
***@iki.fi.nospam.invalid
http://www.iki.fi/Reijo
Reijo Korhonen
2017-04-09 13:40:24 UTC
Permalink
Lyhyt testijakso selätti pahimmat pelot eli sen, että kuormantasaus
rikkoisi istuntoja kun dataa tulee ha menee kahden operaatoprin reittejä
samalle serverille. Itseasiassa en vielä tiedä minkään toimivan huonosti
eli kaikki nettiliikenne näyttää toimivan kuten ennenkin, mutta
nopeammin. Nettipankkiyhteys näyttää toimivan OK, samoin Ylen Areenan
TV- kanavien katseselu, ja kokeilempa Youtubeakin
Nyt on pidempi testijakso takana. Käyttö ei ole mahdottoman
intensiivistä, mutta mtrg-tilkastoissa näkyy kuinka piikit ero isp:den
välillä ovat korkeita ja harvakseltaan. Eli nettiyhtreydet toimivat
nopeasti kun käyttöä on, mutta kummankin isp:n käyttö on vasin vähäistä,
vuorokausitasolla käytän vain 2-4% maksiminopeudesta. Rli taloudellista
kyötyähän rästä kokeilusta ei tule ja käyttötasolla ei kahden isp:n
nopeampaa vastaikaa taida huomata mistään. Mutta kun kerran olen kahden
isp:n loukussa, niin otanpa kaiken irti8 tästä onnettomasta tilanteesta.
Pitäisio olla automaaginen varoyhteys, jos jonki kumpi yhteys on
alhaalla. Tuo kaapeliyhteys on tänä aikana ollut pari tuntioa pois
päältä. Tosin silloin minulla ri ollut voelä shorewall.säädöt päällä,
joten en tiedä olisi homma hoitunut OK. Tosin jos nyt jonpi kumpi isp käy
alhaalla, niin en ehkä huomaa koko asiaa mistään, joten seuraaminen
saattaa olla hankalaa.

Kaikki tosiaan yllä kuvattu toimii ja muutama muukin, eli tähän pivään
asti kaikki myös istuntoja vaativat, yleensä hppps-projokollaa käyttävät
palvelut ovat toimineet, tärkeimpänä tietysti verkkopnakki, mutta niin on
toiminut kaikki muukin.

Mutta tänään törmäsin yhteen verkkokauppatoteutukseen, joka ei toiminut.
muistikauppa.fi:llä istunto hukkui joka toisella klikkauksella, joten
ostoskori tyhjeni mystisesti.

Tästä selvisin sanommalla "sudo shorewall stop" joka laittaa shorewallin
pois päältä ja nostaa tai pitää huolta että se toinen internetyhteys on
päällä ja default gatewaynä.

Tämä todisti sen, että istuntoja ylläpidetään monella tekniikalla ja joku
tekniikka on sidottu reittiin, mutta tämä näyttää olevan poikkeus,
onneksi.

Ja kaikissa verkkokaupoissahan minä en ole käynyt, joen kaikkien
toimivuutta en voi taata kahden isp:n ratkaisussa. Toinen verkkokauppa
näyttää kuitenkin toimivan, kun vasta kokeilin. Nimeä en sano, etten
mainostaisi mutta edellisestä lauseesta sen voi päätellä ;-)
--
***@iki.fi.nospam.invalid
http://www.iki.fi/Reijo
Ari Saastamoinen
2017-04-09 14:53:09 UTC
Permalink
Post by Reijo Korhonen
Kaikki tosiaan yllä kuvattu toimii ja muutama muukin, eli tähän pivään
asti kaikki myös istuntoja vaativat, yleensä hppps-projokollaa käyttävät
palvelut ovat toimineet, tärkeimpänä tietysti verkkopnakki, mutta niin on
toiminut kaikki muukin.
Edelleenkään toi HTTPS ei eroa HTTP:stä muuten kuin, että yhteyden
aikana on linkki salattu, ja yhteys on täsmälleen yhtä pitkä kuin
HTTP:lläkin, eli jokainen klikkaus verkkopankissa muodostaa uuden
yhteyden ja siis myös uuden HTTPS-session. Ja se sessionhallinta
sinne itse pankkilogiikkaan on tehty ylemmällä tasolla, joka ei liity
mitenkään siihen käytetäänkö HTTPS:ää vai ei (Tosin pankin systeemit
lienee tehty niin, että ei toimi lankaan ilman ässää, mutta se ei
liity sessionhallintaan)
Post by Reijo Korhonen
Mutta tänään törmäsin yhteen verkkokauppatoteutukseen, joka ei toiminut.
muistikauppa.fi:llä istunto hukkui joka toisella klikkauksella, joten
ostoskori tyhjeni mystisesti.
Tämä todisti sen, että istuntoja ylläpidetään monella tekniikalla ja joku
tekniikka on sidottu reittiin, mutta tämä näyttää olevan poikkeus,
onneksi.
Kuten jo alkuperäisen keskustelun yhteydessä kerroin, niin joissakin
paikoissa sessionhallinta sitoo session IP-osoitteeseen ja joissain
toisissa ei.

Ja vahvistit vain epäilyni siitä, että tuo IP:seen sitominen ei ole
kauhean yleistä, kun se rikkoo monet kuormantasaussysteemit.
--
Arzka oh3mqu+***@hyper.fi - En halua follareita mailina
1. Valitse sopiva paikka, ei ihmisten tai rakennusten lahella, jossa
paukku voi aiheuttaa hairiota. - Iso-Kiinalaisen kayttoohje
Reijo Korhonen
2017-04-09 20:02:24 UTC
Permalink
Post by Ari Saastamoinen
Edelleenkään toi HTTPS ei eroa HTTP:stä muuten kuin, että yhteyden
aikana on linkki salattu, ja yhteys on täsmälleen yhtä pitkä kuin
HTTP:lläkin, eli jokainen klikkaus verkkopankissa muodostaa uuden
yhteyden ja siis myös uuden HTTPS-session. Ja se sessionhallinta sinne
itse pankkilogiikkaan on tehty ylemmällä tasolla, joka ei liity
mitenkään siihen käytetäänkö HTTPS:ää vai ei (Tosin pankin systeemit
lienee tehty niin, että ei toimi lankaan ilman ässää, mutta se ei liity
sessionhallintaan)
Edelleenkin https-yhteys on salattu kahden pisteen välillä, http-yhteys
taas ei, joten http-yhteydessä mm. man in the middle on mahdollinen, kun
taas https-yhteydessä ei eikä yhtään tälläista man in the middle-
tietomurtoa ole edelleenkään dokumentoitu.

Mutta minusta kiistat protokollastekniikasta eivät kuulu tänne. Wikisivut
sen sijaan pyydän kaikkien lukevan <https://en.wikipedia.org/wiki/HTTPS>
"https" on "http over tls" ja tls on istunnollinen.

Se että istunto tehdään ylemmällä tasolla liittyy tietenkin liikenteen
kerrokselliseen toteutuykseen, mutta sitä istuntokerrosta ei voida tehdä
ilman että alhaalla on tls.

Väittely menee minusta sivuraiteille jos joku alkaa vänkkäämään, että
kauppapaikkoja voi tehdä http-yhteyden päälle ihan yhtä hyvin kuin https-
yhteyden päälle. Tälläisia toteutuksia ei ole.
Post by Ari Saastamoinen
Post by Reijo Korhonen
Mutta tänään törmäsin yhteen verkkokauppatoteutukseen, joka ei
toiminut. muistikauppa.fi:llä istunto hukkui joka toisella
klikkauksella, joten ostoskori tyhjeni mystisesti.
Tämä todisti sen, että istuntoja ylläpidetään monella tekniikalla ja
joku tekniikka on sidottu reittiin, mutta tämä näyttää olevan poikkeus,
onneksi.
Kuten jo alkuperäisen keskustelun yhteydessä kerroin, niin joissakin
paikoissa sessionhallinta sitoo session IP-osoitteeseen ja joissain
toisissa ei.
Ja vahvistit vain epäilyni siitä, että tuo IP:seen sitominen ei ole
kauhean yleistä, kun se rikkoo monet kuormantasaussysteemit.
Onneksi ei näytä olevan ollenkaan yleistä. Minä olen tekemässä kahden
isp:n ratkaisua itselleni ja teen huomioita siitä, miten palvelut
toimivat ja se maailma, jonka näen kauppapaikoissa, todellakin käyttää
https-yhteyksiä ja muodostaa istunnot sen päälle ja lähes kaikki
kauppapaikat sekä kokeilemani verkkopankit )mo se oma) toimivat, vaikka
reitti vaihtuu istunnon välillä. Yksi kauppapaikka sen sijaan ei toimi ja
sen täytyy johtua siitä miten sinä on istunto rakennettu. Onneksi tämä
näyttää olevan poikkeus, koska kaikki muut kauppapaikat ja verkkopankit
ovat toimineet.
--
***@iki.fi.nospam.invalid
http://www.iki.fi/Reijo
Ari Saastamoinen
2017-04-09 20:28:23 UTC
Permalink
Post by Reijo Korhonen
Mutta minusta kiistat protokollastekniikasta eivät kuulu tänne. Wikisivut
sen sijaan pyydän kaikkien lukevan <https://en.wikipedia.org/wiki/HTTPS>
"https" on "http over tls" ja tls on istunnollinen.
Myös TCP (jonka päällä HTTP) toimii on tilallinen (Siis
istunnollinen). Yhteys avataan, sitä käytetään ja se yhteys
suljetaan.
Post by Reijo Korhonen
Se että istunto tehdään ylemmällä tasolla liittyy tietenkin liikenteen
kerrokselliseen toteutuykseen, mutta sitä istuntokerrosta ei voida tehdä
ilman että alhaalla on tls.
Sovelluksen istunnon hallinta voidaan tehdä myös ilman TLS:ää, joka ei
webbisovellukselle edes tarjoa mitään apua istuntojen hallintaan.

Lähes kaikki webbisovellukset on tehty niin, että ne toimisivat ihan
yhtä hyvin myös ilman TLS-kerrosta, mikäli tuota ei vain olisi
erikseen estetty.
Post by Reijo Korhonen
Väittely menee minusta sivuraiteille jos joku alkaa vänkkäämään, että
kauppapaikkoja voi tehdä http-yhteyden päälle ihan yhtä hyvin kuin https-
yhteyden päälle. Tälläisia toteutuksia ei ole.
Tiedän useammankin verkkokaupan, jossa ei ole SSL:ää käytössä (edes
tuotantokäyttövaiheesa). Ja kaikki toistaiseksi näkemäni asennukset
(olen nähnyt useita) ovat olleet sellaisia, että palvelun
testi-/rakennusvaiheessa niitä on käytetty ilman SSL:ää, ja toi
sertifikaatti on asennettu vasta kun palvelu on otettu
tuotantokäyttöön.
--
Arzka oh3mqu+***@hyper.fi - En halua follareita mailina
1. Valitse sopiva paikka, ei ihmisten tai rakennusten lahella, jossa
paukku voi aiheuttaa hairiota. - Iso-Kiinalaisen kayttoohje
Reijo Korhonen
2017-04-09 21:01:54 UTC
Permalink
Post by Ari Saastamoinen
Tiedän useammankin verkkokaupan, jossa ei ole SSL:ää käytössä (edes
tuotantokäyttövaiheesa). Ja kaikki toistaiseksi näkemäni asennukset
(olen nähnyt useita) ovat olleet sellaisia, että palvelun
testi-/rakennusvaiheessa niitä on käytetty ilman SSL:ää, ja toi
sertifikaatti on asennettu vasta kun palvelu on otettu tuotantokäyttöön.
Devausvaiheen logiikkoja voi titenkin rakentaa miten parhaiten saa
yhteydet toimimaan devausympäristöissä, mutta tuotantovaiheen kauppapaikka
on se, jonka kuluttaja näkee ja näkee tätä nykyä vain https-
prorotokollalla toimivia. Ainakaan minä en muita käyttäisi. MOT
--
***@iki.fi.nospam.invalid
http://www.iki.fi/Reijo
Ari Saastamoinen
2017-04-09 22:11:11 UTC
Permalink
Post by Reijo Korhonen
Devausvaiheen logiikkoja voi titenkin rakentaa miten parhaiten saa
yhteydet toimimaan devausympäristöissä,
Tuotantovaiheen ja testausvaiheen logiikat ovat täsmälleen samat (Tai
sitten pitäisi tehdä uusi testausvaihe sen jälkene kun logiikkaa
vaihdetaan)
Post by Reijo Korhonen
on se, jonka kuluttaja näkee ja näkee tätä nykyä vain https-
prorotokollalla toimivia. Ainakaan minä en muita käyttäisi. MOT
Noita salaamattomia on tuotannossa yllättävän monia. Ihan siitä
huolimatta, että sinä et sellaista käyttäisi. Minä saattaisin
harkintaa käyttäen käyttäkin kunhan se
luottokortti-/verkkopankkibrokeri edes käyttää salausta.


Ainakin noita paljon käytettyjä verkkokauppaohjelmistoja (Woocommerce,
Magento ja Clovershop) olen nähnyt asennettuna ja käytössä myös ilman
TLS-salausta.
--
Arzka oh3mqu+***@hyper.fi - En halua follareita mailina
1. Valitse sopiva paikka, ei ihmisten tai rakennusten lahella, jossa
paukku voi aiheuttaa hairiota. - Iso-Kiinalaisen kayttoohje
Reijo Korhonen
2017-04-10 19:44:40 UTC
Permalink
Post by Ari Saastamoinen
Post by Reijo Korhonen
Devausvaiheen logiikkoja voi titenkin rakentaa miten parhaiten saa
yhteydet toimimaan devausympäristöissä,
Tuotantovaiheen ja testausvaiheen logiikat ovat täsmälleen samat (Tai
sitten pitäisi tehdä uusi testausvaihe sen jälkene kun logiikkaa
vaihdetaan)
Voi ne yrittää tehdä samaksi, mutta kuten itse kirjoitit, devausympäristö
ei käyttänyt https-protokollaa, joten logiikat eivät voineet olla samat.
Itse ohjelmiston sisällä logiikka voi olla sama tai varmaan yritettiin
ainakin pidettäväksi samana, mutta http:n päällä olevassa tls-kerroksessa
ja siinä osassa joka tls:ää käytti, logiikkja ei tietenkään voinut olla
sama, koska tuo kerros puuttui. Ja kuten edellisen viestni linkissä
mainitaan, https:n käyttö todellakin voi vaikuttaa reititykseen
edustapalvelimen jolla https-liikenne tulee( ja ohjelkmistopalvelimen
välillä.

Mutta kuten aiemminkin sanoin, nyt eksytään siitä aiheesta josta haluan
keskustella elikä siitä toisesta päästä, kahta isp:tä hyödyntävästä
kuluttajapäästä, jossa shorewallilla toteutettuna kaikki toki toimii,
mutta on pari erikoistapausta, jossa kannattaa säätää yhteys tiettyihin
palveluihin yhden isp:n kautta kulkevaksi. Yksi on tietyllä erikoisalla
tavalla toteutetut kauppapaikat, joita on onneklsi harvassa ja toinen on
operaattorin tarjoamat palvelut vain kotiverkkoonsa kuten sähköposti ja
nimipalvelut.
--
***@iki.fi.nospam.invalid
http://www.iki.fi/Reijo
Ari Saastamoinen
2017-04-11 08:55:59 UTC
Permalink
Post by Reijo Korhonen
Voi ne yrittää tehdä samaksi, mutta kuten itse kirjoitit, devausympäristö
ei käyttänyt https-protokollaa, joten logiikat eivät voineet olla samat.
Olet oikeassa, mutta kummassakin tapauksessa sen verkkokaupan
rajapinta on sama, eli Apachen (tai nginx:n tai lighthttpd:n tai...)
skriptirajapinta, joka pysyy muuttumattomana vaikka se TLS-kerros
lisätäänkin siihen väliin, ja kun tuo web-palvelin (muualla) testattu
valmis tuote, niin tuo TLS ei ihan kauhean syvällistä testausta
varsinaisen verkkokaupan kehitystyön yhteydessä vaadi.
Post by Reijo Korhonen
tavalla toteutetut kauppapaikat, joita on onneklsi harvassa ja toinen on
operaattorin tarjoamat palvelut vain kotiverkkoonsa kuten sähköposti ja
nimipalvelut.
Eikö kaikilla operaattoreilla muka ole autentikoivia
sähköpostipalvelimia, joihin saa yhteyden ihan mistä tahansa?
--
Arzka oh3mqu+***@hyper.fi - En halua follareita mailina
1. Valitse sopiva paikka, ei ihmisten tai rakennusten lahella, jossa
paukku voi aiheuttaa hairiota. - Iso-Kiinalaisen kayttoohje
Reijo Korhonen
2017-04-11 18:09:13 UTC
Permalink
Post by Ari Saastamoinen
Eikö kaikilla operaattoreilla muka ole autentikoivia
sähköpostipalvelimia, joihin saa yhteyden ihan mistä tahansa?
Kaikilla operaattoreille joista palveluyhteys on ostettu on autentikoivat
sähköpalvelimet, mutta operaattorin kotiverkosta autentikointi voi olla
erilaista ja yksinkertaisempää. Nimittäin kun olaan operaattorin
kotiverkossa, niin operaattori voi yhteryden ip-numeron perusteella
autentikoida kuka palvelua käyttää. Jos yhteys tulee muualta, niin
sillolin autentikointi pitää tehdä käyttäjätunnuksen ja salasanan avulla.
TIetenkin se käyttäjätunnus jossain vaiheessa on annettava salasnoineen,
jotta pääsee omalle sähköpostilaatikolleen.

Mutta palvelun nopeus on tietenkin tapöisa kun ollaan aina kunkin
operaattorin kotiverkossa, koska siolloin ip-liikenmteessä on vähiten
solmuja matkalla.

En nyt muista miten olin sähköpostipalvelun säätänyt, operaattorin
kotiverkon ohjeiden mukaan vaiko operaattorin vierasverkosta tehtävän
käytön mukaan. Joka tapauksessa en halunnut muuttaa enkä tarkistaa
säätöjä, koska tietenkin operaattorin omat palvelut hoituvat nopeiten
operaattorin kotiverkosta käsin. Toisekseen tälläisen säädön tekeminen on
shorewalissa varsin simppeliä.
--
***@iki.fi.nospam.invalid
http://www.iki.fi/Reijo
Juhani Varemo
2017-04-12 05:02:25 UTC
Permalink
Post by Reijo Korhonen
Mutta palvelun nopeus on tietenkin tapöisa kun ollaan aina kunkin
operaattorin kotiverkossa, koska siolloin ip-liikenmteessä on vähiten
solmuja matkalla.
Sähköpostin tapauksessa nyt en laita suurta painoarvoa sille kestääkö
viestin lähteminen 100 ms kauemmin vai ei. Tuskin edes huomaan tuota eroa.

Jossain etä- / VPN-yhteydessä hitaus saattaa olla enemmän häiritsevää.
Reijo Korhonen
2017-04-16 20:35:18 UTC
Permalink
Post by Juhani Varemo
Post by Reijo Korhonen
Mutta palvelun nopeus on tietenkin tapöisa kun ollaan aina kunkin
operaattorin kotiverkossa, koska siolloin ip-liikenmteessä on vähiten
solmuja matkalla.
Sähköpostin tapauksessa nyt en laita suurta painoarvoa sille kestääkö
viestin lähteminen 100 ms kauemmin vai ei. Tuskin edes huomaan tuota eroa.
Jossain etä- / VPN-yhteydessä hitaus saattaa olla enemmän häiritsevää.
Jokainen säätää tietenkin sen verran kun on tarpeen ja haluaa. Kuten
aikaisemmissa viesteissäni kuvasin, säädin kunkin operaattorin palvelut
tulemaan operaattorin kotiverkosta eikä vierasverkosta, jo senkin takia
että se taatusti on nopeinta ja joitakin palveluita ei anneta
operaattorin verkosta vierasverkkoon tai palvelujen autenikointi on
erilainen tms. ja säätö on varsin yksinkertainen, säätötiedostoon
mertkitään vain ne palvelimet, jotka tavoittaa sen verkkoyhteyden kautta,
joka on tuon operaattorin kotiverkko. Palveluiden laatua elikkäportteja
ei tarvitse eritellä jos ri ole tarvetta ja tässä tapauksessa sitä ei
tietenkään kannata tehdä. Tuo säätö taitaa minne nopeammin kuin sen
pohtiminen, kannattaako säätö ihan takuuvarmasti kaikiulla paloveluilla
ja huomaako sitä mistään. Itse asiassa näissä asioissa sitä ei huomaa
mistään kun kaikki toimii optimaalisesti, mutta sen huomaa kun jokin ei
toimi. Joten no news on good news.

mrtg:llä tehty tilasto kertoi vasta, että yhden kerran sentään kahden
isp:n ratkaisu on tuottanut viiden minuutin ajan nopeampaa yhteyttä kuin
yhden isp:n maksiminopeus, joten takuuvarmasti joskus vasteajat ovat
olleet tällä ratkaisulla nopeammat kuin mihin yhden isp:n ratkaisu
pystyisi. Tosin kun vuorokausitasolla käyttö on alta prosentin yhden
isp:n maksiminopeudesta, niin siitä voi päätellä, että aika harvoin
lyhyempiä vasteikoja on tarvittu.
--
***@iki.fi.nospam.invalid
http://www.iki.fi/Reijo
Ari Saastamoinen
2017-04-17 07:28:04 UTC
Permalink
Post by Reijo Korhonen
mrtg:llä tehty tilasto kertoi vasta, että yhden kerran sentään kahden
isp:n ratkaisu on tuottanut viiden minuutin ajan nopeampaa yhteyttä kuin
yhden isp:n maksiminopeus, joten takuuvarmasti joskus vasteajat ovat
olleet tällä ratkaisulla nopeammat kuin mihin yhden isp:n ratkaisu
pystyisi.
Todennäköisesti vasteajat ovat paremmat, mutta tuosta mrtg:n
yhteysnopeuskäppyrästä et tätä voi päätellä. Sillä liittymän
kapasiteetilla ja vasteajoilla ei välttämättä ole toukkaa yhteyttä
toisiinsa. Mulla esim. on LTE-datassa suuremmat siirtonopeudet kuin
DSL-liittymässäni, mutta DSL:ssä on parempi vasteaika.
--
Arzka oh3mqu+***@hyper.fi - En halua follareita mailina
1. Valitse sopiva paikka, ei ihmisten tai rakennusten lahella, jossa
paukku voi aiheuttaa hairiota. - Iso-Kiinalaisen kayttoohje
Reijo Korhonen
2017-04-17 20:13:45 UTC
Permalink
Post by Ari Saastamoinen
Post by Reijo Korhonen
mrtg:llä tehty tilasto kertoi vasta, että yhden kerran sentään kahden
isp:n ratkaisu on tuottanut viiden minuutin ajan nopeampaa yhteyttä
kuin yhden isp:n maksiminopeus, joten takuuvarmasti joskus vasteajat
ovat olleet tällä ratkaisulla nopeammat kuin mihin yhden isp:n ratkaisu
pystyisi.
Todennäköisesti vasteajat ovat paremmat, mutta tuosta mrtg:n
yhteysnopeuskäppyrästä et tätä voi päätellä. Sillä liittymän
kapasiteetilla ja vasteajoilla ei välttämättä ole toukkaa yhteyttä
toisiinsa. Mulla esim. on LTE-datassa suuremmat siirtonopeudet kuin
DSL-liittymässäni, mutta DSL:ssä on parempi vasteaika.
Meilläpäin ei tarvitse turvautua suuren latenssin omaavaan LTE:hen
saadaseen kahden isp:n yhteyden, vaan minulla on käytössäni kaksi
tasavahvaa langallista yhteyttä samansuuruisilla kohtuullisilla
latensseilla ja download nopeuksilla. Toisessa on nopeampi upload, mutta
siitä en paljon hyödy, sillä kotikäyttäjänä ei ole tarve työntää tavaraa
internettiin ja download tarvitsee hyvin vähän uploadia saadakseen
pyynnöt perille, vuorokausitasolla alta 0.0% kapasiteetista ja 5 minuutin
maksimimääränä vain muutamia kilotalotaviuja sekunnisssa.

Noo, kun mrtg näyttää yhteenlasketun siirtomäärän ajan funktiona, niin
kyllä takuuvarmasti tuona viiden minuutin ajanjaksona, jona siirtonopeus
ylitti yhden isp:n siirtokapasiteetin, yksittäisiä siirtoja sen kummemmin
erittelemättä, nuo siirrot päättyivät aiemmin kuin miklä olisi
mahdollista yhden isp:n tapauksessa, joten kyllä sen kummemmin
käsitteillä venkoilemetta vastajat olivat nopeampia, koska vastajan
määritelmä on se, koska siirto on valmis. Siirrot olivat valmiita
aikaisemmin, mutta tulos on tietenkin keskimääräinen, sillä ei mrtg laske
yksittäisiä siirtoja vaan siirtyneen datan määrää aikaa kohti.
--
***@iki.fi.nospam.invalid
http://www.iki.fi/Reijo
Juhani Varemo
2017-04-18 08:11:59 UTC
Permalink
Post by Reijo Korhonen
Jokainen säätää tietenkin sen verran kun on tarpeen ja haluaa.
Joskus tulee säädettyä ihan säätämisen ilosta, ilman todellista tarvetta tai
hyötyä :-)
Reijo Korhonen
2017-04-19 19:44:58 UTC
Permalink
Post by Juhani Varemo
Post by Reijo Korhonen
Jokainen säätää tietenkin sen verran kun on tarpeen ja haluaa.
Joskus tulee säädettyä ihan säätämisen ilosta, ilman todellista tarvetta
tai hyötyä :-)
Entäs haittaa? Sillä minun säätöni kyllä toimivat ihan niin kuin kitaran
tai pianon viritys. On joko vireessä tai ei ole, mutta kun on säädetty
vireeseen, niin ei sitä parempaan vireeseen enää saa vaan huonompaan.
Niinpä kun saan säädöt kohdilleen, niin toimii loistavasti ja sen
paremmin ei voi saadakaan toimimaan ja siihen säätöön se saa jäädäkin,
useimmiten jopa vuosikausiksi ja jos jostain syystä menee epävireeseen,
niin sitten vasta säädetään. Tietenkin soitinvalikoimaa voi tarpeen
mukaan lisätä ja silloin uusi orkesterin jäsen oitää säätää samaan
vireenseen muiden vempaimien kanssa.
--
***@iki.fi.nospam.invalid
http://www.iki.fi/Reijo
Juhani Varemo
2017-04-20 17:10:10 UTC
Permalink
Post by Reijo Korhonen
Post by Juhani Varemo
Post by Reijo Korhonen
Jokainen säätää tietenkin sen verran kun on tarpeen ja haluaa.
Joskus tulee säädettyä ihan säätämisen ilosta, ilman todellista tarvetta
tai hyötyä :-)
Entäs haittaa?
Aikaa kuluu, voi törmätä ongelmiin joita ei tiennyt voivan olla olemassakaan
ja - mikä pahinta - sivutuotteena lisääntyvä tieto tuo lisää tuskaa.


Mutta:
Virityshän lasketaan onnistuneeksi jos suorituskyky ei laske yli 50% :-)
Sääntöön on myös poikkeus: jos virittämällä ääni kovenee niin myös
suurempikin tehon lasku hyväksytään.

Perinteinen moponvirittäjän mietelause.

Reijo Korhonen
2017-04-09 20:56:35 UTC
Permalink
Post by Reijo Korhonen
Mutta tänään törmäsin yhteen verkkokauppatoteutukseen, joka ei toiminut.
muistikauppa.fi:llä istunto hukkui joka toisella klikkauksella, joten
ostoskori tyhjeni mystisesti.
Tästä selvisin sanommalla "sudo shorewall stop" joka laittaa shorewallin
pois päältä ja nostaa tai pitää huolta että se toinen internetyhteys on
päällä ja default gatewaynä.
Parempi tapa olisi tietenkin ollut yksinkertaisen säännön laittaminen
shorewallin conffeihin, kumman isp:n kautta sille otetaan yhteydet ja
jatkossa tuokin kauppapaikka toimisi.

Tuon tyyppisiä sääntöjä on nyt vain nimipalveluiden suhteen, sillä
isp:den nimipalvelut harvemmin palvelevat vieraan isp:n verkosta tuleviin
palvelupyyntöihin ja totta kai toimivat nopeammin kun käytän tässä päässä
isp:n kotiverkkoa. Ja postipalvelimiinkin otan yhteydet kummankin isp:n
oman kotiverkon kautta.
--
***@iki.fi.nospam.invalid
http://www.iki.fi/Reijo
Nospam
2017-02-17 17:53:26 UTC
Permalink
Post by Reijo Korhonen
Näyttäisi siltä, että jäinkin kahden isp:n loukkuun. Samantasoista
palvelua lupaavat. Noh, asiat voi nähdä valoisastikin eli nyt on
tilaisuus ;-) Opetella ja säätää kuotmantasausta linuxilla.
Kone1-- ! !--- modeemi1 --- ISP1
Kone2-- Linux--
Kone3-- ! !--- modceemi2 -- ISP2
Toivottavasti kuva ei muutu matkalla. Noh, minulla on siis Linuc
rfeitiämässä muutamalle koneelle internettiä. Ja tämä linuc näkee kaksi
er1 modeemia joiden takana kaksi eri ISP:tä tarjoaa nettiä. Olisihan se
kiva että kun ylimääräistä maksua menee, niin molemmista ISP:stä saisi
vuorotellen tavaraa sisään. Jotenkin niin, että joku palikka katsoo että
jos toinen ISP ei ole ehtinyt vastaamaan edelliseen pyyntöön ja toinen ISP
on joutilas, niin seuraava pyyntö sillejoka on vapaana. Tämä tietysti
onnistuu istunnottomissa palveluissa (http) mutta eikös istunnollisissa
(https) palveluissa istunto pidä mennä koko istunnon ajan saman isp:n
kautta, sillä muuten vastapuoli luulee että otetaan toinen istunto ja
silloin kaksi istuntoa taitaa olla pian epäsovussa.
Miten tälläiset kuorman tasaukset/optimoinnit säädetään linuxissa?
Onko tätä [1] kukaan kokeillu koskaan? Itse en ole kun ei ole ollut
tarvetta. Mutta jos joku kokeilee kellä on kaksi ISP yhteyttä, niin
olisi kiva tietää toimiiko ja miten hyvin/huonosti.

Load balancing tuossa ei liene optimaalinen, koska se sanoo: "Note that
balancing will not be perfect, as it is route based, and routes are
cached. This means that routes to often-used sites will always be over
the same provider. "

[1] http://lartc.org/howto/lartc.rpdb.multiple-links.html

BR, Nospam
Tuska Pankki
2017-02-17 19:11:01 UTC
Permalink
Post by Nospam
Onko tätä [1] kukaan kokeillu koskaan? Itse en ole kun ei ole ollut
tarvetta. Mutta jos joku kokeilee kellä on kaksi ISP yhteyttä, niin
olisi kiva tietää toimiiko ja miten hyvin/huonosti.
En valitettavasti ehtinyt tehdä isompaa demoamista viimeksi
yhteyttä vaihtaessa. Silloin oli kaksi lankayhteyttä samaan
aikaan kuukauden verran.
Lanka + mobiili on testattu. Lähinnä siis tasolla, jossa tietyt
asiat / koneet ohjataan aina toiseen ja tietyt toiseen. Samoin
hyvin kevyellä tasauksella "jos lanka täynnä, käännä mobiiliin".
Tällä tasolla ei varsinaisia ongelmia mutta hyöty jäi pieneksi.
Jos molemmat yhteydet olisivat olleet nopeita ja vakaita, olisi
varmuuskopioinnit, streampalvelut ja muu vastaava ollut toki
helppo hoitaa toisen yhteyden kautta ja muu käyttö toisen. Tämä
olisi ollut käytännössä riittävä omaan käyttööni.
Syvällisempi testaus jäi varsin pieneksi joten siitä ei "oikeaksi
todistettua" testipohjaista kerrottavaa oikeastaan
ole.

Nyt olisi ylimääräinen mobiiliyhteys olemassa joten ajatuksena on
ollut jatkaa kokeiluja jossakin sopivassa välissä, joka tosin voi
olla ensi kesä. Mikäli jotain ehdottomasti kokeilemisen arvoista
on, voisi sen kertoa. Samalla kokeilulla menee JOS joskus alkuun
pääsee. Tarvetta tällaiselle ei varsinaisesti ole joten ei
myöskään ole aivan ensimmäisiä asioita tehtäväksi.

TP


----Android NewsGroup Reader----
http://usenet.sinaapp.com/
Loading...