Monitorování rozhraní tunelu IPsec: co číst

Návrh IPsec založený na trasách instaluje virtuální rozhraní a toto rozhraní dává monitorování konkrétní objekt: něco s názvem, čítači a trasou, která k němu patří. Samo o sobě to není signál zdraví. Rozhraní může existovat, zatímco není nainstalováno žádné použitelné přidružení, a přidružení může být zdravé, zatímco žádná trasa k němu neposílá zajímavý provoz. Právě společné čtení čtyř stavů promění počítadlo paketů v diagnózu.

Projděte je popořadě a zastavte se u prvního, které selže.

Co rozhraní přináší do obrazu

V návrhu založeném na zásadách žije výběr v tabulce zásad IPsec a jádro rozhoduje, co je chráněno, podle selektorů provozu. Návrh založený na trasách přidává rozhraní a trasu, takže tcpdump a čítače rozhraní vidí jednu hranici místo sady selektorů. To je skutečný přínos pro diagnostiku a pro směrovací protokoly, které potřebují rozhraní pro peering.

Přínos je administrativní, ne kryptografický. Rozhraní hlásí provoz, který nese, a neříká nic o tom, zda je ochrana na straně protějšku právě použitelná.

Přečtěte čtyři stavy, než obviníte tunel

Začněte rozhraním a trasou, pak přidružením, pak aplikací. Každé má svůj příkaz a svůj podpis selhání. Čistý výsledek na jedné vrstvě není čistým výsledkem na další. Spusťte všechny čtyři, než uděláte závěr. Jeden zelený řádek málokdy něco vyřeší.

ip -s link show xfrm0
ip route get 10.20.30.40
ip xfrm state
ip xfrm policy
swanctl --list-sas
tcpdump -ni xfrm0 -c 20 host 10.20.30.40

Rozhraní s rostoucím čítačem, ale bez odpovídající položky stavu, popisuje provoz vstupující na cestu, kde ho nic nechrání, což je horší než tunel, který prostě spadl. Položka stavu bez trasy vybírající rozhraní znamená, že kryptografie je připravená a nevyužitá.

Test aplikace přichází nakonec a záměrně: úspěšný ping na druhou stranu tunelu nedokazuje, že služba za ním přijímá spojení.

Porovnejte vnitřní čítače s vnějšími

Čítače na rozhraní tunelu měří vnitřní provoz; čítače a odchyty na fyzickém rozhraní ukazují zapouzdřenou výměnu. Ty dvě se nebudou shodovat jedna k jedné, protože zapouzdření přidává hlavičky, opakované přenosy duplikují některé pakety a účtování implementace se řídí vlastními pravidly. Očekávejte poměr, ne rovnost.

Umístění odchytu také rozhoduje o tom, jaká soukromá data sbíráte, proto používejte úzké filtry a neškodnou testovací adresu místo úplného odchytu produkčního provozu.

Pokud vnitřní čítače rostou a vnější ne, chybějícím krokem je obvykle trasa nebo zásada, která posílá pakety do tunelu, ne tunel sám.

Sledujte to při obnově klíčů a přepnutí

Sledujte obnovu klíčů, událost detekce mrtvého protějšku a přepnutí spoje při sledování stejných čtyř stavů. Rozhraní může zůstat přítomné během obnovy klíčů, která nikdy neskončí, a přepnutí může zanechat položku stavu ukazující na adresu protějšku, která už není dostupná.

Alarmujte na cestě služby, na které skutečně závisíte, se stavem přidružení jako kontextem, místo na jediném příznaku nahoru nebo dolů. Uchovejte název rozhraní, adresu protějšku a trasu v obsahu alarmu, aby je ten, kdo reaguje, nemusel rekonstruovat.

strongSwan dokumentuje svůj vlastní model rozhraní XFRM a jiné platformy ekvivalentní objekt pojmenovávají a implementují odlišně. Přečtěte si srovnání založené na trasách pro zařízení, které máte před sebou, než přenesete předpoklady z jiné implementace. Šablona monitorování, která sedí čítačům jednoho dodavatele, bude u jiného tiše mást.