IPSEC - prechod z ISA serveru

[Josef Hrabec]

> 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.