Korleis rutebasert IPsec fungerer med eit XFRM-grensesnitt

Rutebasert IPsec overlèt til rutetabellen ei avgjerd som policy-selektorar pleidde å ta. På Linux er delen som gjer dette mogleg XFRM-grensesnittet: ei virtuell eining der trafikken blir jamført med IPsec-tilstand via ein grensesnittidentifikator i staden for ein selektor. Å opprette éi tek éin einaste kommando og beviser ingenting om det finst ein tunnel. Eininga er ein krok mellom ruting og tryggleikspolicy, og begge sidene av den kroken må konfigurerast før noko er verna.

Kva eininga er, og kva ho ikkje er

Eit XFRM-grensesnitt er eit rutehandtak. Pakkar som blir ruta inn i det, blir jamførte med XFRM-policyar som viser til same grensesnittidentifikator, og dersom det finst ein policy og ein tilstand, blir dei kapsla inn. Utan dei finst grensesnittet, teljarane står stille, og trafikken går ingen nyttig stad.

Det er den første diagnostiske oppdelinga. Ei rute inn i eininga er eit rutingfaktum, ein installert tilstand er eit tryggleiksfaktum, og ein stigande teljar på eininga er ingen av delane. Når folk seier at tunnelen er oppe fordi grensesnittet viser UP, skildrar dei lenkjeflagga til ei virtuell eining som ikkje har nokon eigen peer. Flagget tyder at eininga vart oppretta og slått på, ikkje meir.

Ennå ei grense: grensesnittidentifikatoren er ikkje eit namn. To einingar med liknande namn og ulike identifikatorar deler ikkje tilstand, og ei tilkopling konfigurert med feil identifikator installerer tilstand som inga rute nokon gong vil bruke.

Bygg éi i rett rekkjefølgje

Start med den ytre eininga og eit tal du også set i daemonkonfigurasjonen. Dømet brukar eth0 som ytre grensesnitt og 42 som identifikator, adresser du bør bytte ut med dine eigne.

Ta eininga opp, og stadfest deretter identifikatoren kjernen registrerte før du rører VPN-konfigurasjonen:

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 no tilkoplinga i strongSwan med same identifikator, sidan daemonen må installere policyar og tilstandar som viser til han. Set dei lokale og eksterne trafikkselektorane til området du har tenkt å rute, og rut deretter det området inn i eininga. Daemonkonfigurasjonen og rutetabellen må vere samde om både identifikatoren og destinasjonane, og ingen av dei leverer den andre.

Hald IKE og ESP utanfor tunnelruta

Ei standardrute som peikar inn i XFRM-eininga fangar både dei innkapsla pakkane og trafikken dei ber. Resultatet er ei løkke: gatewayen prøver å sende sin eigen ESP gjennom tunnelen som ESP skal byggje.

Løysinga er ei meir spesifikk rute for den ytre adressa til peeren gjennom det fysiske grensesnittet, som vinn over standardruta fordi ho passar fleire bitar. Markbasert ruting gjer same jobben når fleire tunnelar deler ein tabell, og strongSwan dokumenterer begge tilnærmingane for rutebaserte utplasseringar.

Uansett kva du vel, må du stadfeste at den ytre pakken forlèt ukapsla. Ein rask sjekk er å pinge den ytre adressa til peeren etter at tunnelen er oppe; dersom det feilar medan grensesnittet er oppe, mistenk innfanging framfor tilgjenge. Same resonnementet gjeld IKE-porten, fordi daemonen sin eigen UDP-trafikk ikkje må rutast inn i eininga han prøver å etablere.

Sjekk teljarane på to stader før du klandrar krypteringa

Grensesnittteljarar og tilstandsteljarar måler ulike stadium. Pakkar som blir ruta inn i eininga, aukar eininga sjølv når ingen tilstand passar, medan tilstandsteljarane berre flyttar seg for trafikk som faktisk vart kapsla inn.

Les begge, og les deretter daemonen sitt syn på barnetilkoplinga:

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

Stigande einingsteljarar med tom tilstandsutskrift tyder at rutinga verkar og policyen ikkje passar, vanlegvis ein feil i identifikator eller selektor. Stigande tilstandsteljarar medan fjernsida ikkje rapporterer noko, tyder at pakkane forlèt men ikkje kjem fram eller feilar autentisering, noko som peikar på banen eller peer-konfigurasjonen. Ei lista barnetilkopling utan trafikk er eit selektorproblem i den eine enden, ikkje ein øydelagd chiffer.

Avgjer kven som installerer rutene

To eigarar av éin rutetabell er den vanlege kjelda til flapping. Dersom daemonen installerer ruter automatisk, må nettverkshandsamaren din ikkje også installere ei standardrute gjennom same eining, og ei manuell rute lagt til av eit oppstartsskript blir fjerna neste gong daemonen omkonfigurerer.

Vel éin eigar og skriv det ned. Når daemonen eig rutene, hald oppstartsskriptet utanfor tabellen og lat tilkoplinga si skildring beskrive trafikkselektorane. Når nettverkshandsamaren eig dei, slå av automatisk installasjon og godta at daemonen ikkje reparerer ei manglande rute ved gjenoppkopling.

Vidaresendings- og brannmurreglar er ei separat avgjerd på toppen, fordi ein gateway som slepper gjennom trafikken til andre vertar treng begge. Rutebasert IPsec gjer den trafikken lett å uttrykke med vanlege rutingverkty; det gjer ikkje policylaget valfritt.