IPSEC - prechod z ISA serveru

[Dan Lukes]

Josef Hrabec wrote:
>> 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. 

To nic. To se mi bezne stava u "nadrizeneho" interfacu v pripade VLANu
taky. Prestoze vim, ze musi byt UP ;-)

> Odchozi pakety jsou moje ping-y a prichozi jsou nejake jine pakety od serveru z druhe strany

Tak to je spatny, protoze to znamena, ze muj predpoklad o obousmerne
komunikaci neni splneny.

> echo ode mne na druhou stranu
...
> dale vidi moje echo vlozne do tunelu:
...
> ale uz neni videt odpoved

To je spatny. To muze znamenat prilis mnoho veci - ale prvni je, ze
paket je pro druhou nedesifrovatelny. Treba je zasifrovan nespravnym
klicem. Nebo je pozit jiny sifrovaci algoritmus. Nebo je nekonzistentne
pouzit jiny argument (digest, PFS). A je takrka nemozne odhadnout z nasi
strany co je problem. Paket proste neni pro protistranu dostatecne
spravny. A nebo spravny je - ale po desifrovani nevyhovi mistnimu
firewallu nebo necemu jinemu a sezere ho ten.

, 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

Pak by melo zpatky jit prinejmensim ICMP unreachable. Ale i tak vidime,
ze alespon tunel k tobe je ustaven korektne. Coz je pro tuto stranu
dobra zprava, ale pro komunikaci v druhem smeru to nerika celkem nic
moc, protoze ty pultunely jsou v podstate nezavisle.

I kdyz, zase je divne, ze by se v jednom smeru dohodly klice dobre a v
druhem spatne.

>> jestli navracejici se ESP paket ma "spravne" SPI - tedy totez, ktere ma
>> odpovidajici SPD zaznam.

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

Ano, to je zrejme.


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

Jak vyse receno, presne to je jedna az moznosti. Parametry v obou
smerech jsou v podstate nezavisle - a nejen hesla, ale i algoritmy. Na
druhou stranu, neni obvykle, aby se pro kazdy ze smeru dohadovaly ruzne
(krome hesel).

Ale mohlo by se stat, ze nejakou chybou v implementaci IKE dojde ke
"skryte nedohode" - to jest - strany si mysli, ze se dohodly, ale ve
skutecnosti nemaji parametry uplne shodne. Ale protoze n kazde stran eje
implementace ruzna, muze se stat, ze v jednom smeru domluveni jsou tak,
ze si rozumi a v druhem si to jen mysli, ale nejsou. Ja nerikam, ze to
tak je - jen, ze to tak byt muze.


> Anebo mozna bude problem lezet prave nekde v komunikaci jinych stroju.

To mozna jo. Ale tim se opravdu nema smysl zabyvat, dokud nam nebudou
navzajem komunikovat oba endpointy spolu. Krome varianty "explicitne
zakazano firewallem" je prakticky vylouceno, abychom uspesne rozchodili
komunikaci ne-koncovych stroju aniz by nam fungovala komunikace tech
koncovych.

Pokud by byli na druhem konci ochotni spolupracovat alespon minimalne,
at dodaji LOG. Podle meho vlastniho zkoumani (ten disassembler se nekdy
opravdu hodi, protoze dokumentace stoji za kocku a co clovek nevylame z
DLL to nema) potrebny LOG na strane Woken ziskaji zapnutim:

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\PolicyAgent\Oakley]
"EnableLogging"=dword:00000001
"Debug"=dword:000000ff

Alespon na W2k to tak chodilo (ten muj navod je uz sedm let stary)

log se vytvari v %SystemRoot%\debug\oakley.log - ale format neni nikde
popsany, takze je nutna intuice a znalost ISAKMP protokolu.

Bylo by rozhodne pekne mit moznost porovnat tvuj a jejich vysleek IKE.
Muzu se ti s tim pokusit nejak pomoct, ale pripadne delsi LOGy, a zejmen
alogy z Woken asi spis nepatri do teto konference, takze kdyztak mimo.
Az/pokud na neco prijdeme, muzeme sem dat vedet vysledek.

Ovsem, pokud nelze z druhe strany vylamat zadnou, ani minimalni,
spolupraci, tak to muze byt dost tezke ...


						Dan