> Takze - kyvadlove ESP pakety naznacuji, ze ping na druhou stranu dojde, > je spravne pochopen a vyvola odpoved, ktera prijde.
Tak, ted si musim nasypat popel na hlavu, to interface enc0 opravdu nebylo up. Kdyz jsem jej dal up tak uz je na nem videt komunikace, ktera vysvetluje ony kyvadlove esp pakety. Odchozi pakety jsou moje ping-y a prichozi jsou nejake jine pakety od serveru z druhe strany, ktere nejsou urceny pro me. Tedy, tcpdump -ni enc0 vidi: echo ode mne na druhou stranu 06:38:04.163836 (authentic,confidential): SPI 0x1516a724: IP A.A.A.A > B.B.B.B: ICMP echo request, id 512, seq 15618, length 40 kde A.A.A.A je muj klient a B.B.B.B je server na druhe strane tunelu dale vidi moje echo vlozne do tunelu: 06:38:04.163843 (authentic,confidential): SPI 0x1516a724: IP C.C.C.C > D.D.D.D: IP A.A.A.A > B.B.B.B: ICMP echo request, id 512, seq 15618, length 40 (ipip-proto-4) kde C.C.C.C je zacatek tunelu na me strane (externi IP routeru) a D.D.D.D je konec tunelu na druhe strane (externi IP blackboxu) ale uz neni videt odpoved, pouze vidim jak z tunelu na mou stranu vypadavaji pakety: 06:38:04.278451 (authentic,confidential): SPI 0x0cc97139: IP D.D.D.D > C.C.C.C: IP E.E.E.E.2512 > F.F.F.F.1352: S 3040121534:3040121534(0) win 65535 <mss 1460,nop,nop,sackOK> (ipip-proto-4) kde E.E.E.E je jiny server na vzdalene strane tunelu a F.F.F.F je klient v mem rozsahu, ktery v okamzik kdy provadim test neni na sit pripojen druhy paket pro E.E.E.E > F.F.F.F uz videt neni, coz ale muze byt zpusobeno tim, ze F.F.F.F v dany okamzik nekomunikuje, BSD router jej ARP dotazem nemuze nalezt (zitra rano jej zkusim zapojit do testu take) > Takze je treba proverit, > jestli navracejici se ESP paket ma "spravne" SPI - tedy totez, ktere ma > odpovidajici SPD zaznam. Pokud ne, zname potiz. Pokud ano, mel by takovy > paket smerovat k desifrovani. POkud si pamatuju dobre, tak v SAD se > eviduje kolik byte bylo danym klicem zasifrovano/desifrovano (tedy > doufam, ze se tam nascitavaji obe operace). Pokud se to cislo po > prichodu paketu zvysi, pak by mel byt spravne desifrovan. Pokud se nam > ztraci az ten, melo by se to projevit nekde v netstat statistikach ... Diky za typ se SPI, rano jsem si sice neuschoval aktualni setkey -D, ale zitra to provedu znova i s uschovanim aktualniho vypisu SAD. Nic mene, ale kdyz vidim jak mi z tunelu vyleti paket ktery je smerovan ze vzdalene strany ma mou stranu a vidim zdrojove i cilove IP vcetne portu, pak tusim ze desifrovani probehlo v poradku. Myslis, ze je mozne, ze v pripade kdy vidim sve pakety vstupovat do tunelu a cizi pakety z nej vystupovat, ale nevidim z tunelu vystupovat zadne pakety ktere by byly odpovedi na ty me, ze vzdalena strana nerozumi? Ze by desifrovani na druhe strane koncilo neuspechem? Myslel jsem, ze kdyz je tunel navazan a pakety lze tunelem poslat jednim smerem, ze by to melo jit zaroven i smerem opacnym... coz vypada, ze ale asi nejde. (vratim-li konfiguraci zpet na server s Windows, pak se na druhou stranu pingnout lze, takze cil na druhe strane mi mezitim neumrel :) > V pripade IPSECu zadne routovani neexistuje. Ale to predbihame. > Nekomplikujme si zivot, dokud na to neni spravny cas. Nejprve je treba > rozfungovat komunikaci mezi obema stroji na koncich toho tunelu. Teprve > az budes mit tohle, muzeme zacit resit takove veci jako je komunikace > jinych stroju pres ten tunel. > Anebo mozna bude problem lezet prave nekde v komunikaci jinych stroju. Diky za pomoc, Pepa. -- FreeBSD mailing list ([email protected]) http://www.freebsd.cz/listserv/listinfo/users-l
