Dotaz: Problemy s multihomingom

[timeos]

Zdravim

riesim divne spravanie sa debiana, ktory aj napriek definovanym pravidlam posiela pakety inak ako ja pozadujem. Mam klasicky priklad. Linux router (debian etch), ktory ma internetovu konektivitu cez dvoch providerov ISP1 (lokalna adresa IP1) a ISP2 (lokalna adresa IP2). Standardne mam default routu na ISP1.

A teraz ku konfiguracii. Riesim problem ze mam ipsecovy tunel, ktory potrebujem tahat cez ISP2 so zdrojovou adresou IP2 a cielovou adresou VPNDestIP. Problem vsak je, ze sice smerom na ISP2 ta komunikacia ide, ale s adresou IP1, cim sa samozrejme nie je sanca zostavit spojenie. Konfiguracia:

ip rule:
0:      from all lookup 255
32759:  from all fwmark 0x2 lookup table_isp2
32760:  from all fwmark 0x1 lookup table_isp1
32764:  from IP1 lookup table_isp1
32765:  from IP2 lookup table_isp2
32766:  from all lookup main
32767:  from all lookup default

ip ro:
ISP1_NET dev eth1 scope link src IP1
ISP2_NET dev eth2 scope link src IP2
...
default via ISP1 dev eth1

ip ro sh table table_isp1:
ISP1_NET dev eth1 scope link src IP1
default via ISP1 dev eth1

ip ro sh table table_isp2:
ISP2_NET dev eth2 scope link src IP2
default via ISP2 dev eth2

zaroven mam v iptables nasledovne:

iptables -t mangle -A -d VPNDestIP -j MARK --set-mark 0x2

Taktiez v konfiguracii ipsec tunela mam presne definovane aka je left ip (IP2) a aka right ip (VPNDestIP). To teda znamena ze pakety by mali vyhoviet jednak ip rule 32759 a teda pre ich smerovanie by sa mala pozerat tabulka table_isp2, alebo keby som pakety nemarkoval, tak by sa mala zafungovat polozka ip rule 32765, ktora pakety so zdrojovou adresou IP2 bude tak ci onak smerovat cez table_isp2. Ale nedeje sa tak a ja netusim preco. Dokonca neviem, akym sposobom by som to mohol nejak nizkourovnovo oddebugovat.

Teraz to troska skomplikujem (v skutocnosti to take jednoduche nieje) ked napisem, ze tych tunelov je v systeme definovanych viac a ze niektore tunely idu spravne a ine zas nie. Avsak pre vsetky z nich je principialna konfiguracia rovnaka (cielovy VPN endpoint sa markuje cez iptables, a v ipsec.conf je pre kazdy tunel definovany left ip (IP2) aj right ip (VPNDestIPX)). Avsak pre vsetky tunely plati, ze ich zdrojova adresa je IP2.

Dalsia vec ktora to (mozno) komplikuje je to, ze na ISP2 je navesanych na jednom interfaci (eth2) niekolko IP adries s tym, ze IP2 je podla vypisu ip addr oflagovana ako secondary.

Mna teda zaujima ci je uvedeny postup konfiguracie spravny, a ak ano, tak ako je mozne, ze sa sice paket na zostavenie tunela posiela spravnym interfacom (eth2) ale s nespravnou zdrojovou IP adresou (IP1) - to ze je to naozaj tak mam overene cez tcpdump -i eth2 host VPNDestIP. Co to teda moze sposobovat? System sluzi zaroven aj ako router, teda z internych sieti sa smerom na ISP1 robi NAT, avsak NAT-ovacie pravidlo je zavesene vyslovene na interfaci eth1 (-t nat -A -o eth1 -j MASQUERADE).

A este verzie toho, co pouzivam:

debian etch 4.0, kernel-2.6.18-6-amd64, openswan-2.4.6+dfsg.2-1.1+etch2, iptables-1.3.6.0debian1-5

Dakujem za akukolvek radu.

---

---

Odpovědi

[frr]

Jak přesně vypadá konfigurace toho IPSecu? Kde mu říkáte, jakou lokální adresu má tunel použít?

Ehh... možná trochu o voze a o koze, ale: co použít OpenVPN? Dvě instance démona, každou nakonfigurovanou aby jela přes jinou lokální IP adresu. Ale pokud je Vám třeba IPSec shůry diktován, asi nemáte na vybranou. O IPsec jsem se pokoušel asi 3x (Cisco, BSD, Linux) v průběhu cca 10 let a pokaždé se mi z něho chtělo zvracet - částečně z některých principů, částečně z konkrétní implementace. Zato OpenVPN jela před pár lety na první škrtnutí, a pořád jede, k mé úplné spokojenosti.

IPSec holýma rukama v Linuxu jsem už dlouho neviděl, takže netuším, jestli pořád "krade pakety ze vzduchu", nebo jestli vytváří pro tunel virtuální rozhraní. OpenVPN to má jasné: vytváří virtuální rozhraní, přes která routuje. A vnější TCP/UDP sockety tunelů obsluhuje standardním způsobem user-space démon - nemá se kde splést, nemá výmluvu.

BTW, jsou ty běžící IPSecové relace vidět v "netstat -n" resp. "netstat -ln"? Pokud ano, jak vypadají?

[timeos]

Jak přesně vypadá konfigurace toho IPSecu? Kde mu říkáte, jakou lokální adresu má tunel použít?

Takto (z ipsec.conf):

conn spojenie
    left=IP2
    leftsubnet=MY_NET
    right=VPNDestIP
    rightsubnet=VPNDestIP_NET
    ...

Ehh... možná trochu o voze a o koze, ale: co použít OpenVPN? Dvě instance démona, každou nakonfigurovanou aby jela přes jinou lokální IP adresu. Ale pokud je Vám třeba IPSec shůry diktován, asi nemáte na vybranou. O IPsec jsem se pokoušel asi 3x (Cisco, BSD, Linux) v průběhu cca 10 let a pokaždé se mi z něho chtělo zvracet - částečně z některých principů, částečně z konkrétní implementace. Zato OpenVPN jela před pár lety na první škrtnutí, a pořád jede, k mé úplné spokojenosti.

Presne ako neskvor pisete, to ze je tam prave ipsec ja nedokazem ani v najmensom ovplyvnit. za druhe je jeho konfiguracia dost priehladna a da sa presne definovat aka ma byt IP, aky ma byt nexthop a pod, takze pre situacie, kedy mate viac exitpointov je dokonca toto ziaduce, ze mozte rovno povedat, aka ma byt src IP a teda nemusi to nejak robit system.

IPSec holýma rukama v Linuxu jsem už dlouho neviděl, takže netuším, jestli pořád "krade pakety ze vzduchu", nebo jestli vytváří pro tunel virtuální rozhraní. OpenVPN to má jasné: vytváří virtuální rozhraní, přes která routuje. A vnější TCP/UDP sockety tunelů obsluhuje standardním způsobem user-space démon - nemá se kde splést, nemá výmluvu.

Pouzita IPSec implementacia je KLIPS (cez openswan), a pre ziadny tunel sa nejake viditelne rozhranie nevytvara. Overit funkcnost tunela samozrejme problem nieje, dokazem si zistit stav a teda overit, ktory je up a ktory je freeznuty v nejakej faze.

BTW, jsou ty běžící IPSecové relace vidět v "netstat -n" resp. "netstat -ln"? Pokud ano, jak vypadají?

Nie, tam ich neuvidite, su to nontcp spojenia takze vo vypise maximalne vidiet iba LISTEN porty pre ipsecove porty 500.

[frr]

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

[timeos]

po dlhsom case sa vraciam k tomuto vlaknu aby som to nejak uzavrel. v prvom rade dik za vycerpavajucu odpoved, mam vsak taky pocit ze problem je vyrieseny. cele to spocivalo v tom, ze aplikovanie ip rule pravidiel a zmien v routovacich tabulkach sa vykonavalo ako posledne (rc.local, vtedy som nevedel o ziadnom rozumnejsiom sposobe aplikovania nastaveni na debiane). A teda predtym, ako sa pravidla zmeny aplikovali, nastartovali vsetky demony vratane vpn demonov na ipsec a pod a hned sa snazili o pripojenie (ktore bolo v tej chvili neuspesne). Darmo som sa mohol snazit hladat problem v pravidlach, niekedy niektore vpn tunely isli podla nich, ine podla pravidiel smerovania pred aplikaciou zmien.

A pritom cely ten cas bol problem v smerovacej cache, ktora ostavala persistentna aj po aplikacii zmien v ip rule a v smerovacich tabulkach. To znamena ze zmena nastaveni sa previedla, ale packet bol smerovany stale starym sposobom, lebo siel cez cache ktora tuto info stale drzala :)))) Skoro ma toto zistenie porazilo :)). Ponaucenie na zaver: pokial robite zmeny v smerovani zalozenych na urcitych pravidlach a viacerych branach, VZDY po aplikovani nastaveni premazte smerovaciu cache nasledujucim prikazom:

ip route flush cache

Tento ukon je nevyhnutny hlavne vtedy, pokial v pociatocej konfiguracii smerovania tiekli pakety (a hlavne tie, ktore chceme ovplivnit - ako v mojom pripade) a tym sa ta cache vytvorila. Ak by sa jednalo o stav aplikacie zmien pri spustani "networking" init skriptu po starte systemu (teda este pred spustenim akejkolvek sluzby), tak zmazanie cache potrebne podla mojho nazoru nieje. Tu vsak asi treba pouzit spravnu distro, ktora taketo zmeny (ip rule, viacere smerovacie tabulky) dokaze cez networking init skript realizovat (asi najviac sa mi to vidi na redhat like networking init skriptoch).

[Michal Kubeček]

A teda predtym, ako sa pravidla zmeny aplikovali, nastartovali vsetky demony vratane vpn demonov na ipsec a pod a hned sa snazili o pripojenie (ktore bolo v tej chvili neuspesne).

Co si vzpomínám na doby, kdy jsem ještě používal FreeS/WAN, tak tam šlo v konfiguraci nastavit, jestli se má rovnou vyjednat SA nebo ne. U ipsec-tools (což je IMHO na systémech s jádrem 2.6 vhodnější implementace) se to vždy nechává až na první paket odpovídající příslušné SP.