Napadla 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í!
Mozna 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.
mam 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.
mno. 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...