Administrace komentářů

To je právě ono. Na první pohled do konfigurace to vypadá jednoduše a přehledně. Reálně ale často koukáte jak zjara, proč to nefunguje tak, jak by si člověk intuitivně představoval - a to i v přehlednějších případech, než je ten Váš. Na rozběhnutí IPSecu aby člověk študoval detaily toho protokolu z RFCček a nejlíp i zdrojáky OpenSwanu, aby zjistil, co ta zatracená věc zrovna dělá, jak se tahle konkrétní verze liší od verze před dvěma měsíci apod. Navíc "krade pakety ze vzduchu", takže se neřídí routovací tabulkou, takže si dělá bůhví co, a s interním schematem subsystémů netfilter+iproute2 interaguje bůhví jak. Že se tam dynamicky nahazují, timeoutují, obnovují apod. nějaké managementové relace, takže stavový mechanismus na každém konci, a teď se třeba správně nepotkají proti sobě, to už jsou spíš okrajové problémy ("aspoň se to rozběhlo a chvíli to běhalo, shnilo to až za někou dobu"). Omlouvám se, tyhle moje vzteklé žvásty možná s Vaším konkrétním problémem nesouvisí

Pokud má protistrana *nějaký* IPsec, prostě konkrétní implementaci v konkrétní verzi, tak máte docela kliku, pokud proti ní Vaše konkrétní implementace aspoň trochu funguje. To je celkový dojem z mých sporadických zkušeností za posledních cca deset let.

Jo aha, on IPsec pro tunely (ESP tunnel mode) používá svůj vlastní protokol nad IP, číslo 50 (tj. nejede nad TCP ani UDP). Pokud jsou vidět "naslouchající" sockety na UDP portu 500, jsou otevřené pro každou lokální IP adresu extra, nebo vidíte jenom 0.0.0.0:500 ? Tenhle naslouchající UDP port je pro ISAKMP. Čili soudím, že ISAKMP používáte...

Potažmo pro fungování IPSecu je potřeba ve filtrech po cestě povolit jednak IPSec protokol (číslo protokolu 50) pro holé tunely, jednak protokol UDP port 500 pro ISAKMP. Počítám, že tyhle díry ve filtrech máte správně...

Ještě jsem si všiml: Vaše pravidlo "iptables -t mangle" spadne implicitně do chainu FORWARD, tj. neuplatní se na lokálně generované pakety, tj. patrně ani na Váš IPSec (ehm: možná záleží, kam se IPSec zaháčkuje, = možná bude rozdíl mezi low-level tunelem a ISAKMP relací). Pokud byste tedy chtěl manglovat IPSec, správně byste měl to pravidlo vsadit do chainu OUTPUT (mangle table), tj. "-A OUTPUT". Viz opět KPTD. Ale souhlasím, že i pokud mangling nezabere, měl by se na to uplatnit "source routing" pomocí "ip rule 32765".

Pro sledování činnosti IPtables pravidel se dá použít třeba "log target", tj. -J LOG --log-prefix "Ahoj", případně "iptables -L -v", kde sloupec úplně vlevo je počítadlo průchodů pro každé pravidlo.

Už si přesně nepamatuju podrobnosti konfigurace IPSecu... nicméně mám pocit, že než začnou vůbec chodit užitečné pakety tam a zpátky, navazuje se napřed IPSec tunel, resp. pokud je použit ISAKMP pro řešení klíčů pro holý IPSec tunel, tak ISAKMP si ještě napřed musí navázat svoji komunikaci a dohodnout=spárovat odpovídající "security association"... Tak mě napadá, pokud by byly dva tunely na jeden společný "protější konec", a měly by chodit oba ze stejného lokálního stroje = z jediné lokální instance OpenSwanu, jestli třeba ISAKMP nezjistí, že mluví jenom dva stroje mezi sebou, a začne jednu z obou tras ignorovat. Nebo zjistí, že má jenom jednu destination, tak ani nenahodí druhou ISAKMP relaci z druhé lokální adresy - což může a nemusí znamenat, že pak nebude ani balit traffic do "IP protokolu 50" s druhou lokální adresou. Prostě dynamismus a vrstevnatost IPSecu s ISAKMP mi přijde potenciálně dost netriviální, možná se nepočítalo s "Vaším" případem, že chcete mít na jediném lokálním stroji dva různé "endpointy" (IP adresy lokálního konce tunelu) proti jedinému společnému protějšku...
Napadá mě: pokud se správně pamatuju, OpenSwan provozuje user-space démona (řeší ISAKMP a možná něco dalšího). Nešlo by spustit ho dvakrát paralelně? Tj. pro každé venkovní rozhraní oddělenou instanci, s konfigurací security associations pouze pro toto rozhraní. Tohle půjde pouze v případě, že OpenSwan(ISAKMP) binduje UDP port 500 pouze na konkrétní lokální IP adrese. Pokud OpenSwan binduje adresu 0.0.0.0 (všechna rozhraní), tak pokus o spuštění druhé instance skončí chybou. A pak ještě záleží na tom, jestli by reálně zafungovalo zřetězení kernelových háčků (netlink?) obou instancí.

Předpokládám, že IPSec NAT traversal se Vám do toho nemíchá...