Hvordan rutebasert IPsec fungerer med et XFRM-grensesnitt

Rutebasert IPsec overlater til rutetabellen en beslutning som policy-selektorer pleide å ta. På Linux er delen som gjør dette mulig XFRM-grensesnittet: en virtuell enhet der trafikken matches mot IPsec-tilstand via en grensesnittidentifikator i stedet for en selektor. Å opprette én tar én enkelt kommando og beviser ingenting om hvorvidt det finnes en tunnel. Enheten er en krok mellom ruting og sikkerhetspolicy, og begge sider av den kroken må konfigureres før noe er beskyttet.

Hva enheten er, og hva den ikke er

Et XFRM-grensesnitt er et rutehåndtak. Pakker som rutes inn i det, matches mot XFRM-policyer som refererer til samme grensesnittidentifikator, og hvis det finnes en policy og en tilstand, kapsles de inn. Uten dem finnes grensesnittet, tellerne står stille, og trafikken går ingen nyttig steder.

Det er den første diagnostiske oppdelingen. En rute inn i enheten er et rutingfaktum, en installert tilstand er et sikkerhetsfaktum, og en stigende teller på enheten er ingen av delene. Når folk sier at tunnelen er oppe fordi grensesnittet viser UP, beskriver de lenkeflaggene til en virtuell enhet som ikke har noen egen peer. Flagget betyr at enheten ble opprettet og aktivert, ikke mer.

Nok en grense: grensesnittidentifikatoren er ikke et navn. To enheter med lignende navn og ulike identifikatorer deler ikke tilstand, og en tilkobling konfigurert med feil identifikator installerer tilstand som ingen rute noen gang vil bruke.

Bygg én i riktig rekkefølge

Start med den ytre enheten og et tall du også setter i daemonkonfigurasjonen. Eksempelet bruker eth0 som ytre grensesnitt og 42 som identifikator, adresser du bør erstatte med dine egne.

Ta enheten opp, og bekreft 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 nå tilkoblingen i strongSwan med samme identifikator, siden daemonen må installere policyer og tilstander som refererer til den. Sett de lokale og eksterne trafikkselektorene til området du har tenkt å rute, og rut deretter det området inn i enheten. Daemonkonfigurasjonen og rutetabellen må være enige om både identifikatoren og destinasjonene, og ingen av dem leverer den andre.

Hold IKE og ESP utenfor tunnelruten

En standardrute som peker inn i XFRM-enheten fanger både de innkapslede pakkene og trafikken de bærer. Resultatet er en løkke: gatewayen prøver å sende sin egen ESP gjennom tunnelen som ESP skal bygge.

Løsningen er en mer spesifikk rute for peerens ytre adresse gjennom det fysiske grensesnittet, som vinner over standardruten fordi den matcher flere biter. Markbasert ruting gjør samme jobben når flere tunneler deler en tabell, og strongSwan dokumenterer begge tilnærmingene for rutebaserte utplasseringer.

Uansett hva du velger, må du verifisere at den ytre pakken forlater ukapslet. En rask sjekk er å pinge peerens ytre adresse etter at tunnelen er oppe; hvis det feiler mens grensesnittet er oppe, mistenk innfanging fremfor tilgjengelighet. Samme resonnement gjelder IKE-porten, fordi daemonens egen UDP-trafikk ikke må rutes inn i enheten den prøver å etablere.

Sjekk tellerne på to steder før du klandrer krypteringen

Grensesnitttellere og tilstandstellere måler ulike stadier. Pakker som rutes inn i enheten øker enheten selv når ingen tilstand matcher, mens tilstandstellerne bare beveger seg for trafikk som faktisk ble kapslet inn.

Les begge, og les deretter daemonens syn på barnetilkoblingen:

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

Stigende enhetstellere med tom tilstandsutskrift betyr at rutingen virker og policyen ikke matcher, vanligvis en feil i identifikator eller selektor. Stigende tilstandstellere mens fjernsiden ikke rapporterer noe, betyr at pakkene forlater men ikke ankommer eller feiler autentisering, noe som peker på banen eller peer-konfigurasjonen. En listet barnetilkobling uten trafikk er et selektorproblem i den ene enden, ikke en ødelagt chiffer.

Bestem hvem som installerer rutene

To eiere av én rutetabell er den vanlige kilden til flapping. Hvis daemonen installerer ruter automatisk, må nettverksbehandleren din ikke også installere en standardrute gjennom samme enhet, og en manuell rute lagt til av et oppstartsskript fjernes neste gang daemonen omkonfigureres.

Velg én eier og skriv det ned. Når daemonen eier rutene, hold oppstartsskriptet utenfor tabellen og la tilkoblingsdefinisjonen beskrive trafikkselektorene. Når nettverksbehandleren eier dem, slå av automatisk installasjon og godta at daemonen ikke reparerer en manglende rute ved gjenoppkobling.

Videresendings- og brannmurregler er en separat beslutning på toppen, fordi en gateway som slipper gjennom andre verters trafikk trenger begge. Rutebasert IPsec gjør den trafikken lett å uttrykke med vanlige rutingverktøy; det gjør ikke policylaget valgfritt.