thus spoke juraj in 'hiding traffic' :: Remember, remember, the velvet November


node:	thus spoke juraj in 'hiding traffic'
template:	4
parent:	thus spoke maniac in 'hiding traffic'
owner:	juraj
viewed by:
created:	23.09.2004 - 14:13:05

cwbe coordinatez:
101
63540
63542
1098481
1109443
1137310
1137567
1137595

ABSOLUT
KYBERIA

permissions
you:	r,
system:	public
net:	yes

jasne, ze to chodi. robil som tak load balanced access cez dva rozne konekty.

000001010006354000063542010984810110944301137310011375670113759501139070

hm a nerobi problem tcp konekt ked prichadzaju cielovemu hostu pakety z roznych zdrojovych ipckiek ?

00000101000635400006354201098481011094430113731001137567011375950113907001142782

toto je odpoved aj na nudzov aj na maniacov prispevok.

v podstate to funguje tak, ze pri nadvazovani spojenia sa pred odoslanim nastavi zdrojova ipcka na dany interfejs. ked chodia odpovede, tak chodia priamo na tu ipcku, cize na odchode uz ma packet spravnu zdrojovu ipcku a je podla toho deterministicky odroutovany.

cize nie len tcp spojenia, ale aj icmp, udp a vsetko zalozene na ip ide v pohode. nie je k tomu vobec potrebny ani connection tracking.

prevazne som to spravil podla lartc.org, akurat som tam pridal este staticke routy na checkovacie body, ktore sa pingaju (cez ten-konkretny interfejs) a podla toho sa zistuje, ci je jeden hore.

v mojom konkretnom pripade, ktory som nakoniec realizoval to bolo este trosku jednoduchsie, kedze jedna z tych liniek je adsl a tam sa prislusne skripty naviazu na ppp up a ppp down akcie. Potom sa uz len checkuje pingovanim mikroska, ci zije a podla toho sa pridava a vyhadzuje v default route, ci ju ma alebo nema pouzit. Funguje to pekne, ked ktorekolvek spojenie padne, tak vsetky nove connectiony idu len cez ten interfejs, ktory funguje. Vyhoda toho, ze sa tam nepouziva connection tracking je v tom, ze pri znovunahodeni druheho konektu sa zacne v podstate automaticky pouzivat a existujuce spojenia nespadnu.

00000101000635400006354201098481011094430113731001137567011375950113907001139379

Ee... Spojenia sa nadvazuju na striedacku... raz z jednej, potom z druhej sietovky... a weight udava pomery, ze kolko na ktoru... tcp konekt potom ostane az do uzatvorenia na tej jednej sietovke...

00000101000635400006354201098481011094430113731001137567011375950113907001139109

myslim ze jeden tcp konekt chodi len cez ten iface cez ktory bol nadviazany

0000010100063540000635420109848101109443011373100113756701137595011390700113910901139213

imho treba k tomu conntrack a cez netfilter matchovat
teraz som s tym haluzil, poriesil 10 ipciek na vsetky openvpn nahodil a loadbalancoval cez tunely, natoval na servery secko(conntrack si zapametal z ktoreho interfejsu ide stream), ficalo, <> len keby signal bol lepsi :)

zase je na <>(napr. v pripade piratenia wifi) ked mas vela volnych ipciek kazdy shapnutu na 64kbit, ze ti 1 stream viac neda, to by skor bolo treba na nizsej vrstve balancovat v openvpn napr. s tym ze by si videl jeden tun interface ale posielal by kazdy paket round robinom po danych ipckach na 1 cielovu a ta by uz vedela co s tym, ale to som uz odbehol od temy daleko asi

000001010006354000063542010984810110944301137310011375670113759501139070011391090113921301139557

mohol by si o tomto spravit samostatny prispevok v tomto fore, na ciscu sa to robi cez ppp multilink - t.j. vsetky packety sa sekaju na mensie a potom aj tcp konekt moze ist po viacerich linkach. pripadne este per-packet load balancing na ciscu.

zbezne som na googli nasiel zopar liniek evnujucim sa tomuto na linuxe

00000101000635400006354201098481011094430113731001137567011375950113907001139109011392130113955701142776

jo, urobim, par ludi sa ma na to uz pytalo