Zašto OpenVPN ruta gubi od strongSwan XFRM politike
Određena OpenVPN ruta ne nadjačava XFRM politiku: pročitajte rutu i selektore politike, pa suzite, izuzmite ili prijeđite na XFRM interfejs.
Paketi mogu slijediti OpenVPN rutu i ipak biti zahvaćeni IPsec politikom, a ta kombinacija iz svakog ugla izgleda kao greška u rutiranju osim iz pravog. Linux razrješava rutu i zatim konsultuje odvojenu bazu sigurnosnih politika, pa konkretnija ruta do odredišta ne potiskuje odgovarajuću XFRM politiku. Vidljivi simptom je saobraćaj koji napušta host i nikad ne stigne, dok oba tunela sebe prijavljuju zdravim. Tri opcije to rješavaju, a koju ćete izabrati zavisi od toga koja od dvije putanje treba nositi taj prefiks.
Dvije odluke, ne jedna
Izbor rute odgovara na usko pitanje: koji sljedeći hop i izvorna adresa treba nositi ovaj paket. Baza sigurnosnih politika odgovara na drugo: zahtijeva li ovaj paket IPsec zaštitu i pod kojim selektorima. Oba rade za isti paket, i ispunjavanje prvog ne govori ništa o drugom. Zato promjena metrike ili dodavanje statičke rute može ostaviti simptom netaknutim.
Širok IPsec selektor je uobičajen uzrok. Politika koja štiti 172.16.0.0/12 pokriva i 172.20.8.0/24, do kojeg administrator možda namjerava stići kroz OpenVPN tunel. Namjera postoji samo u tabeli rutiranja, a baza politika o njoj nikad nije saznala.
Tretirajte to kao sukob između dvije konfigurisane zaštitne putanje, a ne kao nadmetanje dvije metrike. Popravka pripada onoj komponenti koja je konfigurisana s pogrešnim obuhvatom.
Pročitajte rutu koju kernel zaista bira
Počnite s pretragom koju kernel izvodi, uključujući izvornu adresu i svako pravilo politike koje je može preusmjeriti u drugu tabelu. Ruta u glavnoj tabeli možda nikad neće biti razmotrena ako ranije pravilo izabere drugu tabelu, a podudaranje najdužeg prefiksa vrijedi samo unutar tabele koju pravilo izabere.
ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15
Posljednja komanda je ona koja je važna, jer ispisuje izabranu rutu zajedno s izvornom adresom koju bi kernel koristio. Uporedite taj izlaz sa selektorom s kojim se IPsec politika podudara. Kada ruta pokazuje na OpenVPN interfejs, a politika se i dalje podudara s istim parom, reproducirali ste sukob bez nagađanja.
Držite ispise bez nepovezanih adresa prije nego stignu u tiket. Tabela rutiranja s produkcijskog hosta nosi unutrašnju topologiju, a samo linije koje odgovaraju na pitanje vrijedi zalijepiti.
Pročitajte politiku koja se također primjenjuje
Spisak politika pokazuje smjer, selektore i šablon koji odlučuje šta se dešava sa podudarnim paketom. Prvo čitajte odlazni smjer, pa ulaznu stranu za povratni saobraćaj, jer jednostrano izuzeće stvara vezu koja počinje i nikad se ne završava.
ip -s xfrm policy
swanctl --list-sas
Uporedite selektore na spisku s prefiksima koje je veza dogovorila. Onemogućavanje instalacije ruta u strongSwan-u ne uklanja te politike, a promjena metrike ne mijenja koji par izvora i odredišta politika štiti. Ta dva lažna rješenja vrijedi isključiti rano jer ih ljudi prvo pokušavaju.
Ako spisak ne sadrži politiku za prefiks koji ste očekivali, problem je drugdje i tabela rutiranja vjerovatno govori istinu. Ako sadrži širu politiku koja pokriva prefiks, pronašli ste zahvat.
Tri opcije kada su oba puta legitimna
Sužavanje IPsec selektora najčišća je opcija kada je široki prefiks bio pogodnost, a ne zahtjev. Smanjenje selektora udaljenog saobraćaja na podmreže koje zaista pripadaju iza IPsec-a uklanja sukob za svaki host odjednom, i košta ponovno dogovaranje ključa, a ne novu komponentu.
Passthrough izuzeće je hirurška opcija kada široki selektor mora ostati. strongSwan podržava odvojenu vezu čije dijete koristi pass režim, što kernelu govori da se podudarni saobraćaj ne smije obrađivati kroz IPsec. Loopback udaljena adresa čuva tu vezu od izbora za dolazne peerove, a selektori moraju opisivati stvarni odobreni par, a ne sve.
connections {
openvpn-exception {
remote_addrs = 127.0.0.1
children {
openvpn-exception {
local_ts = 10.44.7.0/24
remote_ts = 172.20.8.0/24
mode = pass
start_action = trap
}
}
}
}
Primjeri konfiguracije strongSwan dokumentuju ovaj tip politike i konvenciju loopback peera. Treća opcija je dizajn zasnovan na rutiranju s XFRM interfejsima, koji politiku veže za saobraćaj rutiran kroz imenovani interfejs umjesto za globalni selektor. To je migracija, a ne podešavanje, i saobraćaj i dalje mora zadovoljiti dogovorene selektore.
| Option | Use it when | Cost |
|---|---|---|
| Narrow the selector | The broad prefix was convenience | A rekey and a policy review |
| Passthrough child | The broad selector must stay | One exception per intended pair |
| XFRM interface | Policy should follow routing | A design migration |
Dokažite izuzeće bez slabljenja ostalog
Nakon učitavanja promjene, testirajte izuzeće i obično odredište koje mora ostati zaštićeno. Provjerite oba smjera, zatim spustite OpenVPN tunel i potvrdite šta se dešava s izuzetim saobraćajem. Izuzeće koje tiho šalje taj prefiks otvoreno kad je tunel pao je odluka o politici koju trebate donijeti namjerno, a ne otkriti tokom incidenta.
Zabilježite koji prefiks koristi koji put i zašto. Inače će sljedeći inženjer koji vidi širok selektor ponovo otvoriti istu istragu, a odgovor će stajati u commit poruci koju niko ne čita.