thus spoke juraj in 'defaultroute thru tunnel on linux' :: Remember, remember, the velvet November


node:	thus spoke juraj in 'defaultroute thru tunnel on linux'
template:	4
parent:	thus spoke maniac in 'defaultroute thru tunnel on linux'
owner:	juraj
viewed by:
created:	24.07.2005 - 14:52:59

cwbe coordinatez:
101
63540
63542
1098481
1799412
1800063
1800092
1800232

ABSOLUT
KYBERIA

permissions
you:	r,
system:	public
net:	yes

v mojej zmluve je, ze na chello napojim len jeden pocitac. to je moj nat server.

a okrem toho to v chelle nikto neriesi. ficim tak uz dlho a aj kopec dalsich ludi a nikto s tym problem nemal. manik, co mi to chello instaloval mi este daval tipy ako si ponastavovat velkost send buffra, aby mi to islo lepsie a zahlasil, ze freebsd je najlepsi system :).

takze no stress.

inak, preco pouzivas openvpn a nie ipsec?

000001010006354000063542010984810179941201800063018000920180023202110459

"v mojej zmluve je, ze na chello napojim len jeden pocitac. to je moj nat server."

tato veta sa mi paci uplne najviac :D ale chlapec mas pravdu a nikto ti nic nemoze, pretoze to co je za nat masinou je tvoja lokalka do ktorej ti nemozu ani len kuknut :D no ale na tu krasnu vetu budem dlho spominat =)

"v mojej zmluve je, ze na chello napojim len jeden pocitac. to je moj nat server."

00000101000635400006354201098481017994120180006301800092018002320211045902160155

v zmluve sa nepise o pocitaci ale o "koncovom zariadeni" a to je myslene kusok inaksie a presnejsie. takze tak.

000001010006354000063542010984810179941201800063018000920180023201805931

"co mi to chello instaloval mi este daval tipy ako si ponastavovat velkost send buffra"
no aky velky ?
d.

000001010006354000063542010984810179941201800063018000920180023201800763

preto openvpn lebo potrebujem volnost, ipsec je dost tazkopadny v tomto
napr uz som presiel tunnel z udp na tcp koli tomu ze cisco co ma routuje malo vyhulene cpu pri velkom udp trafficu a pri tcp je to v pohode (inac dost haluz ;) )
a dalsie veci koli performance chcem este tunovat (to je ten dalsi clanok co bude coskoro)

00000101000635400006354201098481017994120180006301800092018002320180076301801106

cez tcp je to zloba cista, mas tam meltdown efekt a zbytocne retransmisie. ipsec ti tiez vyhuli cpu? aj ked nepouzijes UDP ako transport, ale iba ESP ako protokol?

meltdown efekt (pre ludi co nevedia) je problem, ked sa tuneluje tcp v tcp. V pripade stratovosti packetov dochadza k exponencialnemu zhorseniu kvality linky. Ak su timery nastavene inak, tak ked vrchnejsia vrstva ziada o retransmisiu packetu, kym to pride, poziada o nu aj spodna tcp vrstva. Tym padom o jednu retransmisiu viac (2 packety navyse, ak spravne ratam). V pripade, ze ten spodny timer je nastaveny este o cosi horsie, tak sa cela situacia bude uz len zhorsovat. Vytazenie linky sposobi dalsie znizenie kvality atd.

Nepredpokladam, ze by to bol realny problem, ak sa ta linka nevyuziva naplno, ale akonahle sa zacne naplno tahat, tak k strate packetov urcite dojde (tak sa pride na to, ze je v sieti congestion, ak nie je zapnute ECN) a toto bude asi vazny problem....

Zaujimalo by ma, ake je to este na dnesnych rychlych linkach relevantne, ale tcp by som v tcp velmi nerad tuneloval.

Inac pekny navod, asi to spravim aj ja (ale cez IPSec), mas pravdu, chello nema co checkovat nielen kolko tam mam kompov, ale ci vobec browsim... Not their business.

0000010100063540000635420109848101799412018000630180009201800232018007630180110601804372

Cez IPSec ti to nepojde... IPSec tuneluje dve konkretne siete, nie konkretna siet vs. zvysok sveta... Teda aspon tak to je v Linux implementacii... Da sa to vyonacit dalsim GRE tunelom nad IPSec-om... volakedy som to mal tak riesene nad FrameRelay od ST, ked este svet nechyroval o OpenVPN a ine veci sa mi zdali pochybne...
BTW, ked uz riesis tunel do hostingu... a via chello, tak urcite budes xiet aj kompresiu pouzit... A v tomto smere je OpenVPN na tom lepsie, lebo ma efektivnejsie algoritmy a co je dolezitejsie, su adaptivne, t.j. sa vypinaju, ked idu uz zbalene veci, cize zbytocne nezvacsuju objem...

Jeden moj PoC:
Private cooperative "LAN" - kedze OpenVPN pouziva tun ifc., t.j. kvazi realna sietovka, da sa to lachko zlepit do bridge a prehanat po tom aj broadcasty. Overovanie via X.509 certs. Serverik v hostingu... a daju sa riesit kvazi LAN-ky medzi roznymi ludmi na roznych koncoch sveta. No kedze existuju aj WIN klienti, tak sa to da aj takemuto typu ludi ponuknut... urcite sa potesia, ked kliknu na networ neigh. a uvidia kompy svojich znamich... hocigkde sa pripoja... ;-)

0000010100063540000635420109848101799412018000630180009201800232018007630180110601801168

no teoria je to pekna a znie aj logicky.
zial v praxi je to picovina a aj napriek teoriam (aj dalsim dovodom preco by malo byt udp lepsie) je tcp naozaj rychlejsie.

ad stratovost pri vyhulenej linke - nie, nieje, nema byt preco, nikto mi nezahadzuje packety, obcas sa nejaky strati, ale je to asi menej ako 1%. za normalnych okolnosti ked je zahulena linka tak sa akurat caka na ack a zase caka sa este dost dlho na to aby som mal take odozvy ze by sa to pokladalo za strateny packet.
bezim na to mikrovlnke ktorej kapacita je nieco medzi 1,7 a 2 mbps a 1 mbps chelle.

000001010006354000063542010984810179941201800063018000920180023201800763018011060180116801801272

no, caka sa ak je velkost tvojej queue taka, ze stiha vyprazdnovat. ak nie, tak sa zakonite packety stracat musia. to iste queue na druhej strane. keby sa nestracali, mas externy meltdown.

proste queue ma urcitu konstantnu velkost (napr. 10MB). ak mas 1Mbps linku a posielas 2Mbps, tak sa queue zaplna, az kym nezaplni tych 10MB a potom sa packety musia stracat. Ak by si mal prilis velku queue, chodili by ti packety, ktore by si uz davno retransmitoval (a su v queue vzadu) a koneksn by sa ti vyhulila zase naplno bordelom.

Samozrejme, tcp je dost rozumne a v pripade, ze nema dost ack (alebo sa prekroci window size), tak spomali posielanie. Co je jediny dovod, preco sa ti ten meltdown efekt neprejavuje. Skus tam nieco streamovat cez udp (voip, videolan, dalsi tunel :-) alebo nieco take) a do toho stahovat cez tcp a uvidis meltdown v plnej krase...
alebo staci 300 tcp konektov ;).

to, ze je tcp rychlejsie ako udp je zjavne nejaka stupidita v openvpn (predpokladam, ze ma sifru v cbc mode a ma horsie riesene retransmisie ako tcp samotne).

00000101000635400006354201098481017994120180006301800092018002320180076301801106018011680180127201801452

to ze je to rychlejsie v tcp je koli tomu ze cisco a vyhulene cpu pri routovani udp (niekde som to tam spominal)

no, "posielat 2mbps po 1mbps linke" sa nejak ani moc teoreticky pri tcp neda, vzdy sa caka na ACKy, a v tom prvom prispevku si prave spominal ze sa jedna o efekt kde sa enkapsuluje tcp v tcp a nie uz udp stramy ako spominas tu

0000010100063540000635420109848101799412018000630180009201800232018007630180110601801168018012720180145201802161

no, ved caka na ack, to je jasne. ale v praxi mas asi malokedy jednu koneksn.

staci ti jedno tcp spojenie a udp zahlcujuce linku a to tcp ti spravi okamzite meltdown. to udp tam je len ako priklad, kedy sa ti moze stat, ze mas zahltenu linku a stracaju sa ti packety a ako vysvetlenie, preco sa ti to nestava, ked stahujes dva subory cez ftp :)

riesil si to cisco, ze preco ma vyhulene cpu? vsak to nie je normalne, nemas na nom nastaveny nejaky stavovy firewall ("connection" tracking)?

000001010006354000063542010984810179941201800063018000920180023201800763018011060180116801801272018014520180216101802203

nie, nic take tam nieje, vsetko som daval prec az na plain konfig a stale ho to udp hulilo.
je to stary shit, ale aj tak nechapem preco je taky rozdiel medzi tcp a udp hm