Selektory provozu v IPsec: co pokrývají a co ne

Selektory provozu pojmenovávají vnitřní provoz, který IPsec dohoda chrání, a dvojice se vyjednává, nikoli předpokládá. Dva koncové body se mohou navzájem dokonale ověřit a přesto se neshodnout, které pakety patří dovnitř tunelu. Tato neshoda je ve stavu spojení neviditelná, protože ten obvykle hlásí zdravý tunel. Přečíst selektory z obou konců a pak sledovat jeden cíl to najde rychleji než jakékoli úpravy politiky.

Čtěte je z obou konců

Každý koncový bod popisuje svou stranu jako lokální a druhou jako vzdálenou. Stejná dvojice prefixů se proto v obou konfiguracích jeví prohozená, a to je správné, nikoli protichůdné. Otočit perspektivu je první věc, kterou je třeba udělat, když funkční dohoda na papíře vypadá špatně. Porovnávat dva soubory vedle sebe bez prohození vytváří neshodu, která neexistuje.

Hodnoty nejsou vždy jednotlivé podsítě. Selektory IKEv2 mohou nést rozsahy adres, čísla protokolů a rozsahy portů, a tak politika chrání jednu službu místo celé sítě. Selektor užší než zamýšlený provoz vytváří tunel, který přenáší některé cíle a jiné tiše vylučuje.

Než cokoli změníte, napište obě strany do jedné tabulky. Toto cvičení obvykle otázku vyřeší, aniž by se sáhlo na konfigurační soubor.

Zužování je rozhodnutí respondera

Iniciátor navrhuje a responder může přijmout jen podmnožinu. IKEv2 umožňuje responderovi zúžit nabízené selektory provozu a zužující výsledek je to, co se skutečně nainstaluje. Čtení konfigurace iniciátora tedy popisuje nabídku, ne dohodu.

Proto podsíť přidaná klientovi může vytvořit funkční tunel, který nový cíl přesto odmítá. Server zúžil nabídku na to, co jeho politika dovoluje, zatímco klientský soubor stále uvádí širší rozsah. Pravdu ukazuje jen vyjednaný stav: v Linuxu ip xfrm policy a výpis child SA v dokumentaci IKEv2 od strongSwanu hlásí, co bylo nainstalováno, nikoli co bylo požadováno. Když se oba rozcházejí, měnit je třeba politiku respondera.

Odmítnutý návrh je jiný příznak než zúžený. Odmítnutí se objeví v protokolu vyjednávání a nezanechá vůbec žádnou child asociaci.

Sledujte jeden cíl od začátku do konce

Vyberte skutečný cíl plus zdrojovou adresu, kterou by pro něj klient použil, a pak tuto dvojici sledujte přes tři nezávislá rozhodnutí. Trasa volí cestu, selektor rozhoduje, zda je tato cesta chráněná, a firewall rozhoduje, zda je paket povolen. Každé může selhat samo o sobě a široký selektor neopraví žádné z ostatních.

ip route get 10.20.30.41
ip xfrm policy list
swanctl --list-sas

Dotaz na trasu pojmenuje rozhraní a zdrojovou adresu, které by paket nesly. Výpis politik ukazuje, zda pro tuto dvojici existuje odpovídající tunelová politika, včetně směru a úrovně. Výpis SA ukazuje vyjednané child selektory spolu s počítadly, takže child asociace s nulou paketů po pokusu o provoz je podpisem selektorů, které vylučují to, co se odesílá. Tři příkazy, tři různé odpovědi a jen jeden z nich vysvětluje tiché zahození.

Pokud se child počítadla hýbou, zatímco aplikace stále selhává, problém je za tunelem. To přesouvá vyšetřování k naslouchajícímu procesu nebo firewallu vzdáleného hostitele, nikoli k selektorům.

Držte oba cíle oddělené

Chránit kancelářskou podsíť a posílat celé prohlížení vzdáleným výstupem jsou různé požadavky s různými selektory. Profil postavený pro jedno se pro druhé hodí jen zřídka a jejich míchání dává buď únik, nebo rozbité rozdělení. Rozšíření chráněného rozsahu znamená změnit oba koncové body a jejich politiku předávání, protože jednostranná změna se stane odmítnutým návrhem. To je nejčastější způsob, jak funkční tunel po malé úpravě přestane fungovat.

Selektory popisují kryptografické pokrytí, trasy volí cesty a aplikace vynucují svá vlastní oprávnění. Tunel, který pokrývá všechno, přesto nedosáhne na službu navázanou na loopback, a trasa do tunelu přesto potřebuje selektor zahrnující cíl. Ověřte všechny tři proti stejnému testovacímu požadavku a neshoda se sama pojmenuje.