XFRM-standardruta slukte IKE og ESP: hald den ytre vegen

Trafikken er verna, tunnelen er oppe, og så døyr han ved neste nøkkelnye. Ei standardrute gjennom XFRM-grensesnittet skildra trafikken du ville verne. Ho slukte òg pakkane som trengst for å halde fram med å verne han.

Dei to involverte destinasjonane er ikkje utskiftbare. Rutinga må seie det eksplisitt.

Kvar peer-oppslaget faktisk går

Noter dei aktive reglane, tabellen som held XFRM-ruta og den offentlege adressa til peeren. Sjå så på vegen den ytre sambandet ville ta med si reelle kjelde og markering. Ein generell destinasjon seier ingenting om den kontrollvegen. Berre den faktiske kjelda og markeringa gir eit nyttig svar.

Eit vellukka første samband provar òg lite. Feilen dukkar ofte opp etter at ein ruteinstallasjon har endra svaret. Oppstarten lukkast, deretter gjer ikkje den første fornyinga det.

ip rule show
ip route show table 220
ip -4 route get 198.51.100.44 from 10.40.0.2
ip xfrm policy list

Viss oppslaget for peeren endar i XFRM-grensesnittet, blir dei ytre pakkane ruta inn i tunnelen dei sjølve byggjer. Det er løkka, synleg i éin kommando.

Uteglingsval på ein moderne gateway

Dokumentasjonen til strongSwan om rutebasert VPN legg fram to praktiske svar. Det eine merkar IKE og ESP slik at regelen mot XFRM-tabellen ikkje treff dei. Det andre lèt ei peer-rute eller ei uteglenging stå som oppslaget framleis kan nå.

Vel den regelsettet ditt kan uttrykkje utan biverknader. Ei markering er rein når resten av stakken alt brukar markeringar. Ho er ein fare når same maske tyder noko anna i ein annan regel. Begge pakketypane treng handsaminga uansett.

Å merke berre IKE lèt datapakkane bli på den fanga vegen. Det gir ein tunnel som gjer handtrykket og deretter ikkje ber noko.

Markeringa er éin bit i fwmark til pakken som ingenting anna på gatewayen krev: 0x1 med maske 0x1 er det vanlege valet, og ho må setjast to stader for at uteglenginga skal verke. Charon treng henne på IKE-socketen, og dei inngåande og utgåande markinnstillingane til barnesambandet treng same verdien for at òg innkapsla pakkar skal gå ut merkte. Ei maske på 0x1 i staden for 0xffffffff lèt dei resterande bita vere frie, noko som tel når eit anna undersystem alt merkar pakkar på same verten. Når begge er sette, blir regelen skriven som ei uteglenging, slik at merkte pakkar hoppar over tabellen som held XFRM-ruta og fell gjennom til hovudtabellen:

ip rule add not fwmark 0x1/0x1 lookup 220 pref 1000
ip -4 route get 198.51.100.44 from 10.40.0.2 mark 0x1

Les så svaret med markeringa brukt. Utan henne granskar du vegen den verna trafikken tek, som er det motsette av spørsmålet i denne delen.

Kva automatisk installasjon føreset om bygget

Automatisk ruteinstallasjon for eit XFRM-grensesnitt avheng av strongSwan-versjonen og konfigurasjonen hans. Grensesnitt-ID-en, den installerte policyen og assosiasjonen må alle vise til dei tiltenkte objekta. Eit avvik viser seg som ei rute som stille peikar ein reell stad.

Å kopiere eit tabellnummer eller ei markmaske frå ein annan gateway er måten kollisjonar startar på. Sjekk først kva som alt brukar det. Ein kollisjon påverkar trafikk langt utover tunnelen du ville endre, og symptomet peikar sjeldan på kopien.

Endringar av peer-adressa høyrer heime i designet. Ei vertsrute for gårsdagens adresse er ikkje ein gjenopprettingsplan for endepunktet, medan ei markering overlever den endringa.

Fylg med på den første fornyinga

Kontroller den ytre vegen etter at dei verna rutene er installerte, ikkje før. Fylg så med på neste fornying og éin applikasjonsutveksling. Feilen viser seg vanlegvis ved den overgangen og ikkje ved oppstart.

ip -4 route get 198.51.100.44
sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or esp'

Å fjerne standardruta mellombels gjenopprettar vanlegvis sambandet. Resultatet er diagnostisk, ikkje endeleg.

Målet er ei stabil deling mellom indre trafikk og dei ytre pakkane som ber han. Skriv den valde mekanismen og tabellen eller markeringa i notata til gatewayen. Elles vil neste person som rører reglane gjeninnføre løkka.