Hoe routegebaseerde IPsec werkt met een XFRM-interface

Routegebaseerde IPsec geeft de routingtabel een beslissing die voorheen door policy-selectors werd genomen. Op Linux is het onderdeel dat dit mogelijk maakt de XFRM-interface: een virtueel apparaat waarvan het verkeer via een interface-identificatie in plaats van via een selector aan IPsec-status wordt gekoppeld. Er één aanmaken kost één commando en bewijst niets over het bestaan van een tunnel. Het apparaat is een haak tussen routing en beveiligingsbeleid, en beide kanten van die haak moeten zijn geconfigureerd voordat iets is beschermd.

Wat het apparaat is en wat het niet is

Een XFRM-interface is een routing-handgreep. Pakketten die erin worden gerouteerd, worden gekoppeld aan XFRM-beleid dat naar dezelfde interface-identificatie verwijst, en als er een beleid en een status bestaan, worden ze ingekapseld. Zonder die bestaan het apparaat wel, blijven de tellers stilstaan en gaat het verkeer nergens nuttig heen.

Dat is de eerste diagnostische splitsing. Een route het apparaat in is een routingfeit, een geïnstalleerde status is een beveiligingsfeit, en een oplopende teller op het apparaat is geen van beide. Als mensen zeggen dat de tunnel omhoog is omdat de interface UP toont, beschrijven ze de linkflags van een virtueel apparaat zonder eigen peer. De flag betekent dat het apparaat is aangemaakt en ingeschakeld, meer niet.

Nog een grens: de interface-identificatie is geen naam. Twee apparaten met vergelijkbare namen en verschillende identificaties delen geen status, en een verbinding die met de verkeerde identificatie is geconfigureerd, installeert status die geen enkele route ooit zal gebruiken.

Bouw er één in de juiste volgorde

Begin met het buitenste apparaat en een nummer dat je ook in de daemonconfiguratie zet. Het voorbeeld gebruikt eth0 als buitenste interface en 42 als identificatie, adressen die je door je eigen moet vervangen.

Breng het apparaat omhoog en bevestig dan de identificatie die de kernel heeft vastgelegd voordat je de VPN-configuratie aanraakt:

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]*'

Configureer nu de verbinding in strongSwan met dezelfde identificatie, want de daemon moet beleid en statussen installeren die ernaar verwijzen. Zet de lokale en externe verkeersselectors op het bereik dat je wilt routeren en routeer dat bereik vervolgens het apparaat in. De daemonconfiguratie en de routingtabel moeten het zowel over de identificatie als over de bestemmingen eens zijn, en geen van beide levert de andere.

Houd IKE en ESP buiten de tunnelroute

Een standaardroute die het XFRM-apparaat in wijst, vangt zowel de ingekapselde pakketten als het verkeer dat ze dragen. Het resultaat is een lus: de gateway probeert zijn eigen ESP door de tunnel te sturen die ESP zou moeten bouwen.

De oplossing is een specifiekere route voor het buitenste adres van de peer via de fysieke interface, die de standaardroute verslaat omdat hij op meer bits past. Mark-gebaseerde routing doet hetzelfde wanneer meerdere tunnels een tabel delen, en strongSwan documenteert beide benaderingen voor routegebaseerde implementaties.

Wat je ook kiest, verifieer dat het buitenste pakket ongekapseld naar buiten gaat. Een snelle controle is de buitenste adressen van de peer pingen nadat de tunnel omhoog is; als dat mislukt terwijl de interface omhoog is, verdenk dan onderschepping in plaats van bereikbaarheid. Dezelfde redenering geldt voor de IKE-poort, omdat het eigen UDP-verkeer van de daemon niet naar het apparaat gerouteerd mag worden dat hij probeert op te zetten.

Controleer tellers op twee plaatsen voordat je de versleuteling de schuld geeft

Interfacetellers en statustellers meten verschillende fasen. Pakketten die het apparaat in worden gerouteerd, verhogen het apparaat zelfs als er geen status overeenkomt, terwijl de statustellers alleen bewegen voor verkeer dat daadwerkelijk is ingekapseld.

Lees beide en lees daarna de kijk van de daemon op de child-associatie:

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

Oplopende apparaattellers bij lege statusuitvoer betekenen dat routing werkt en het beleid niet overeenkomt, meestal een fout in identificatie of selector. Oplopende statustellers terwijl de externe kant niets meldt, betekenen dat de pakketten vertrekken maar niet aankomen of de authenticatie falen, wat op het pad of de peer-configuratie wijst. Een vermelde child zonder verkeer is een selectorprobleem aan één kant, geen kapot cijfer.

Bepaal wie de routes installeert

Twee eigenaren voor één routingtabel zijn de gebruikelijke bron van flapping. Als de daemon routes automatisch installeert, mag je netwerkbeheerder niet ook een standaardroute via hetzelfde apparaat installeren, en een handmatige route uit een opstartscript wordt verwijderd de volgende keer dat de daemon zich opnieuw configureert.

Kies één eigenaar en schrijf dat op. Als de daemon de routes bezit, houd het opstartscript buiten de tabel en laat de verbindingsdefinitie de verkeersselectors beschrijven. Als de netwerkbeheerder ze bezit, schakel automatische installatie uit en accepteer dat de daemon een ontbrekende route bij herverbinden niet repareert.

Doorstuur- en firewallregels zijn een aparte beslissing daarbovenop, omdat een gateway die verkeer van andere hosts doorlaat beide nodig heeft. Routegebaseerde IPsec maakt dat verkeer makkelijk uit te drukken met gewone routingtools; het maakt de beleidslaag niet optioneel.