Sådan virker rutebaseret IPsec med en XFRM-grænseflade

Rutebaseret IPsec giver routingtabellen en beslutning, som politikvælgere plejede at træffe. På Linux er den del, der gør det muligt, XFRM-grænsefladen: en virtuel enhed, hvis trafik matches mod IPsec-tilstand via en grænsefladeidentifikator i stedet for en vælger. At oprette en tager en enkelt kommando og beviser intet om, hvorvidt der findes en tunnel. Enheden er en krog mellem routing og sikkerhedspolitik, og begge sider af den krog skal konfigureres, før noget er beskyttet.

Hvad enheden er, og hvad den ikke er

En XFRM-grænseflade er et routinghåndtag. Pakker, der routes ind i den, matches mod XFRM-politikker, som refererer til den samme grænsefladeidentifikator, og hvis der findes en politik og en tilstand, indkapsles de. Uden dem findes grænsefladen, tællerne står stille, og trafikken går ingen nyttig steder hen.

Det er den første diagnostiske opdeling. En rute ind i enheden er et routingfaktum, en installeret tilstand er et sikkerhedsfaktum, og en stigende tæller på enheden er ingen af delene. Når folk siger, at tunnelen er oppe, fordi grænsefladen viser UP, beskriver de linkflagene på en virtuel enhed, som ikke har nogen egen peer. Flaget betyder, at enheden blev oprettet og aktiveret, ikke mere.

Endnu en grænse: grænsefladeidentifikatoren er ikke et navn. To enheder med lignende navne og forskellige identifikatorer deler ikke tilstand, og en forbindelse konfigureret med den forkerte identifikator installerer tilstand, som ingen rute nogensinde vil bruge.

Byg en i den rigtige rækkefølge

Start med den ydre enhed og et tal, som du også sætter i daemonkonfigurationen. Eksemplet bruger eth0 som ydre grænseflade og 42 som identifikator, adresser du bør erstatte med dine egne.

Bring enheden op, og bekræft derefter den identifikator, som kernen registrerede, før du rører 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]*'

Konfigurer nu forbindelsen i strongSwan med den samme identifikator, da daemonen skal installere politikker og tilstande, som refererer til den. Sæt de lokale og fjernede trafikvælgere til det interval, du vil route, og rut derefter det interval ind i enheden. Daemonkonfigurationen og routingtabellen skal være enige om både identifikatoren og destinationerne, og ingen af dem leverer den anden.

Hold IKE og ESP ude af tunnelruten

En standardrute, der peger ind i XFRM-enheden, fanger både de indkapslede pakker og den trafik, de bærer. Resultatet er en løkke: gatewayen forsøger at sende sin egen ESP gennem den tunnel, som ESP skal bygge.

Løsningen er en mere specifik rute til peerens ydre adresse gennem den fysiske grænseflade, som vinder over standardruten, fordi den matcher flere bit. Markbaseret routing gør det samme, når flere tunneler deler en tabel, og strongSwan dokumenterer begge tilgange til rutebaserede udrulninger.

Uanset hvad du vælger, skal du bekræfte, at den ydre pakke forlader ukapslet. Et hurtigt tjek er at pinge peerens ydre adresse, efter tunnelen er oppe; hvis det fejler, mens grænsefladen er oppe, så mistænk indfangning frem for tilgængelighed. Samme ræsonnement gælder IKE-porten, fordi daemonens egen UDP-trafik ikke må routes ind i den enhed, den forsøger at etablere.

Tjek tællere to steder, før du bebrejder krypteringen

Grænsefladetællere og tilstandstællere måler forskellige stadier. Pakker, der routes ind i enheden, øger enhedens tæller, selv når ingen tilstand matcher, mens tilstandstællerne kun flytter sig for trafik, der faktisk blev indkapslet.

Læs begge, og læs derefter daemonens syn på child-associationen:

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

Stigende enhedstællere med tom tilstandsudskrift betyder, at routing virker, og at politikken ikke matcher, normalt en fejl i identifikator eller vælger. Stigende tilstandstællere, mens fjernsiden intet rapporterer, betyder, at pakkerne forlader, men ikke ankommer eller fejler godkendelse, hvilket peger på stien eller peer-konfigurationen. En listet child uden trafik er et vælgerproblem i den ene ende, ikke en ødelagt cipher.

Beslut, hvem der installerer ruterne

To ejere af en routingtabel er den sædvanlige kilde til flapping. Hvis daemonen installerer ruter automatisk, må din netværksadministrator ikke også installere en standardrute gennem den samme enhed, og en manuel rute tilføjet af et opstartsscript fjernes næste gang, daemonen omkonfigurerer.

Vælg én ejer, og skriv det ned. Når daemonen ejer ruterne, så hold opstartsscriptet ude af tabellen og lad forbindelsesdefinitionen beskrive trafikvælgerne. Når netværksadministratoren ejer dem, så slå automatisk installation fra og accepter, at daemonen ikke reparerer en manglende rute ved genopkobling.

Videresendelses- og firewallregler er en separat beslutning ovenpå det, fordi en gateway, der sender andre hosts trafik videre, har brug for begge. Rutebaseret IPsec gør den trafik nem at udtrykke med almindelige routingværktøjer; det gør ikke politiklaget valgfrit.