Hur ruttbaserad IPsec fungerar med ett XFRM-gränssnitt

Ruttbaserad IPsec lämnar till routingtabellen ett beslut som policy-väljare brukade fatta. På Linux är delen som gör detta möjligt XFRM-gränssnittet: en virtuell enhet vars trafik matchas mot IPsec-tillstånd via en gränssnittsidentifierare i stället för en väljare. Att skapa en tar ett enda kommando och bevisar ingenting om huruvida en tunnel finns. Enheten är en krok mellan routing och säkerhetspolicy, och båda sidorna av den kroken måste konfigureras innan något skyddas.

Vad enheten är och vad den inte är

Ett XFRM-gränssnitt är ett routinghandtag. Paket som routas in i det matchas mot XFRM-policyer som refererar till samma gränssnittsidentifierare, och om en policy och ett tillstånd finns kapslas de in. Utan dem finns gränssnittet, räknarna står stilla och trafiken går ingen nyttig väg.

Det är den första diagnostiska uppdelningen. En rutt in i enheten är ett routingfaktum, ett installerat tillstånd är ett säkerhetsfaktum, och en stigande räknare på enheten är inget av dem. När folk säger att tunneln är uppe för att gränssnittet visar UP, beskriver de länkflaggorna för en virtuell enhet som inte har någon egen peer. Flaggan betyder att enheten skapades och aktiverades, inget mer.

Ännu en gräns: gränssnittsidentifieraren är inte ett namn. Två enheter med liknande namn och olika identifierare delar ingen tillstånd, och en anslutning som konfigurerats med fel identifierare installerar ett tillstånd som ingen rutt någonsin kommer att använda.

Bygg en i rätt ordning

Börja med den yttre enheten och ett nummer som du också anger i daemonkonfigurationen. Exemplet använder eth0 som yttre gränssnitt och 42 som identifierare, adresser du bör ersätta med dina egna.

Ta upp enheten och bekräfta sedan identifieraren som kärnan registrerade innan du rör VPN-konfigurationen:

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip link set xfrm0 up
ip -d link show xfrm0 | grep -o 'if_id [0-9]*'

Konfigurera nu anslutningen i strongSwan med samma identifierare, eftersom daemonen måste installera policyer och tillstånd som refererar till den. Ställ in de lokala och externa trafikväljarna på det intervall du tänker routa och routa sedan det intervallet in i enheten. Daemonkonfigurationen och routingtabellen måste vara överens om både identifieraren och destinationerna, och ingen av dem levererar den andra.

Håll IKE och ESP utanför tunnelrutten

En standardrutt som pekar in i XFRM-enheten fångar både de inkapslade paketen och trafiken de bär. Resultatet är en slinga: gatewayen försöker skicka sin egen ESP genom tunneln som ESP ska bygga.

Lösningen är en mer specifik rutt för peerens yttre adress via det fysiska gränssnittet, som vinner över standardrutten eftersom den matchar fler bitar. Markbaserad routing gör samma jobb när flera tunnlar delar en tabell, och strongSwan dokumenterar båda metoderna för ruttbaserade driftsättningar.

Vad du än väljer, verifiera att det yttre paketet lämnar okapslat. En snabb kontroll är att pinga peerens yttre adress efter att tunneln är uppe; om det misslyckas medan gränssnittet är uppe, misstänk infångning snarare än nåbarhet. Samma resonemang gäller IKE-porten, eftersom daemonens egen UDP-trafik inte får routas in i enheten den försöker etablera.

Kontrollera räknarna på två ställen innan du skyller på krypteringen

Gränssnittsräknare och tillståndsräknare mäter olika steg. Paket som routas in i enheten ökar enheten även när ingen tillstånd matchar, medan tillståndsräknarna bara rör sig för trafik som faktiskt kapslades in.

Läs båda och läs sedan daemonens syn på barnassociationen:

ip -s link show xfrm0
sudo ip xfrm state list | grep -E 'src|proto|mode'
sudo swanctl --list-sas

Stigande enhetsräknare med tom tillståndsutskrift betyder att routingen fungerar och policyn inte matchar, vanligtvis ett fel i identifierare eller väljare. Stigande tillståndsräknare medan fjärrsidan inte rapporterar något betyder att paketen lämnar men inte anländer eller misslyckas med autentisering, vilket pekar på vägen eller peer-konfigurationen. En listad barnassociation utan trafik är ett väljarproblem i ena änden, inte en trasig chiffer.

Bestäm vem som installerar rutterna

Två ägare av en routingtabell är den vanliga källan till flapping. Om daemonen installerar rutter automatiskt får din nätverkshanterare inte också installera en standardrutt genom samma enhet, och en manuell rutt som lagts till av ett startskript tas bort nästa gång daemonen omkonfigureras.

Välj en ägare och skriv ned det. När daemonen äger rutterna, håll startskriptet utanför tabellen och låt anslutningsdefinitionen beskriva trafikväljarna. När nätverkshanteraren äger dem, stäng av automatisk installation och acceptera att daemonen inte reparerar en saknad rutt vid återanslutning.

Vidarebefordrings- och brandväggsregler är ett separat beslut ovanpå detta, eftersom en gateway som släpper igenom andra värdars trafik behöver båda. Ruttbaserad IPsec gör den trafiken lätt att uttrycka med vanliga routingverktyg; det gör inte policylagret valfritt.