... eech, kazdy si toho asi vsimne a mavne rukou, ale jestli se to da jeste opravit, tak: "Dosáhnete doho pomocí IPTABLES"... ryma a v lete? A jeste.. netmask pobocky2 v obrazku nahore mel byt asi 192.168.2.0/24 a ne 192.168.0.0/24. Jinak Lemmingove celkem vladnou...
Názory k článku
Tuneluji, tuneluješ, tunelujeme: jak a k čemu
Re: prelkepy
celé vláknoTo by se dalo vysvetlit tim, ze mame v kancelari klimatizaci :-) Jinak jsem tam jeste objevil "treaceroute" :-/
Ohledne obrazku - samozrejme na Pobocce2 ma byt sit 192.168.2.0/24. Uz jsem poslal redakci opraveny obrazek.
Traceroute přes tunel
celé vláknoNapadla mě jedna věc - myslím že kromě problému
"...při trasování bude tolik nedosažitelných hostů, přes kolik jich jde tunel."
je tu ještě jeden, že se za tunelem tiše přeskočí tolik hostů, přes kolik vede tunel, neboť v zapouzdřeném paketu se TTL asi neodčítá že?
Pro ilustraci:
Tunel vede přes hopy 3,4,5.
šestý traceroute paket, pakety 4 a 5 se ztratily:
Hop 1-2-3=4=5-6-7-8
TTL 5-4-3-3-3-2-1-0
Odpoví až hop 8, hopy 6,7 se tiše přeskočí. I když nejsem si jist u výstupu z tunelu (hop 5), zda se neodečte TTL.
Jinak skvělý seriál, těším se na pokračování!
Re: Traceroute přes tunel
celé vláknoAno, mate pravdu. Presne je to takhle :-)
192.168.0.0/16
celé vláknoja bych radeji predpokladal ze mame sit 192.168.0.0/16 nez 0.0.0.0/0
Re: 192.168.0.0/16
celé vláknoJo, cisilka me nejak utikala :-( Ma tam byt /16 a ne /0.
Re: 192.168.0.0/16
celé vláknoTak priste min chlastat! :) Jen vtip, nic osobniho ;)
Re: 192.168.0.0/16
celé vláknoJe videt, ze mne neznas ;-) Je mozne mne podezirat ze vseho mozneho, ale z tohohle opravde ne :-)
Delegate
celé vláknoK tematu tunelovani doporucuji kouknou na programek DELEGATE na http://www.delegate.org/delegate/
Uspesne jsem ho pouzival na tunelovani ftp/pop3/icq a podobne prez http proxy.
pochvala
celé vláknodokonalej clanek, nejvic se ovsem tesim na IPSec :)
Reverze
celé vláknoZajimalo by me, jak muze nekdo v dane firme zjistit zda a jakym zpusobem je komunikace tunelovana. Predpokladam napriklad ze z tcpdumpu je videt vysledne MTU (resp. mss). Ja mam 1460 - to je normalni hodnota ?
Re: Reverze
celé vlákno1460 se mi zda jako normalni hodnota. Pokud by chodilo ICMP, talo by se zjistit ze na nekterem hopu klesne MTU na divnou hodnotu a z toho neco odvozovat... Jinak, pokud vim, IPSec tento problem s MTU nema.
Re: Reverze
celé vláknoMozna je to lamerina ale zajimalo me spis ktere programy to umi. Koukal jsem totiz ze traceroute a ping co mam (asi trochu starsi) jsou na informace pomerne skoupy a nemaji option na don't fragment .... idealni odpoved je treba stranka http://av.stanford.edu/books/tcpip/append_f.htm, kde najdu adresy viceoptionovych traceroute i par dalsich programu ktere muzu pripadne upravit. ping s don't fragment jsem porad nenasel.
Re: Reverze
celé vláknoPo precteni par dalsich clanku ze serie Sockety a C++ mi doslo jak velka lamerina to je :-).
filtrovani ICMP a GPRS u Eurotelu
celé vláknoQUOTE>>>
Bohužel někteří "administrátoři" zakazují šmahem celé ICMP, prý z "bezpečnostních důvodů". Jedním z důsledků je pak nefunkčnost výše popisovaného mechanismu "Path MTU discovery".
Re: filtrovani ICMP a GPRS u Eurotelu
celé vláknoJe to dost mozne. I kdyz ja jsem pristup na Internet pres GPRS pouzival a zadne problemy s nenatahujicimi se strankami jsem nemel.
Re: filtrovani ICMP a GPRS u Eurotelu
celé vláknojooo et s jejich gprs a sitovani na tom mi faaakt moc nejde pod fousy... ale pry se to ma zlepsit ;-)
form p800 160.218.195.39 :-)))
mtu
celé vláknomam takovy problem s mtu a dvema tunely:
oba dva aktivuju pomoci mpd, jeden se vytvari pro spojeni pres adsl a tim druhym se pripojuji do centraly, oba se uspesne vytvori a data vesele putuji prvnim tunelem do druheho tunelu a komunikace s centralou je zajistena. takze spojeni vypada nasledovne:
pc_p -> r_p -tunel-> adsl -tunel-> r_c -> n_c
kde pc_p je pocitac na pobocce
r_p je router pobocky
r_c je router centraly
n_c je sit centraly
ale v okamziku kdyz se pokusim prelozit pc_p na r_c tak icmp pakety jdou v pohode, ale tcp spojeni se navaze pouze smerem ven, odpoved zpet se vrati na r_c a r_c vrati serveru (venku) icmp odpoved ze pc_p je nedostupny z duvodu fragmentace paketu.
zkousel jsem si pohrat s nastavenim mtu toho druheho tunelu, ale nezadarilo se.
pomozte prosim.
Re: mtu
celé vláknojak jste poznal, ze je to fragmentaci paketu ?
gre
celé vláknomno. spise nez General Routing Encapsulation se imho pouziva Generic Routing Encapsulation(sice spise asi kosmeticke) a asi by nebylo od veci rict proc je generic. (protoze muze zapouzdrovat nejen protokol IP).
dale. lehce mi unikla logika nastavovani TTL kdyz pro traceroute se kazdy tunel jevi defacto jako jeden hop (alespon na ciscu urcite) a z logiky veci mi prijde ze to tak bude obecne. a duvod pro preskakovani hopu za tunelem mi take nejak unika :)
tunel a velikost paketu. je to trosicku jinak. k zahadnym jevum dochazi v pripade ze paket s mtu dorazi na zacatek tunelu, tam tunelujici zarizeni zjisti ze ho nelze obalit a poslat a bud neposle serveru ze je paket prilis velky, ze je zapotrebi fragmentovat (a hodnota na kolik je defacto prave path mtu discovery) a nebo ho tise rozfragmentuje a fragmenty posle tunelem. druhy konec tunelu je pak opet tise slozi a v puvodnim stavu posle dale)
dale by asi bylo vhodne rici ze pro hratky s velikosti paketu lze uspesne pouzit ping s parametry -D a -s (alespon na openbsd. -D je Don't Fragment a s je velikost posilanych dat bez hlavicek. za normalnich okolnosti je 1472 posledni velikost paketu ktera projde na ethernetu)
jen tak zbezne jsem clanek preletel tak je mozne ze jsem neco prehlidnul...
255.255.255.255
celé vláknovie mi niekto poradit co s paketami broadcastu... tie mi nie a nie cez tunel prejst... nemozem sa potom hrat hry.. :-( s uzivatelmi na druhej sieti.. ak sa pytam na totalnu blbost. pls. prepacte som len linux lama.

