Hvem svarer egentlig på VPN-ens dedikerte adresse?

En adresse som ligger ubrukt i organisasjonens tildeling, er ikke en lytter, og å føye den til en brannmur skaper ingen. Noe må avslutte IKE på den adressen, og mekanismen varierer etter om gatewayen eier adressen eller en oppstrøms enhet oversetter den. Pakkestien er det som skiller de to, og den avgjør hvilken plattformfunksjon du trenger før noen åpner en endringsforespørsel. Modeller stien først, og velg deretter.

Pakkestien bak adressen

En peer sender IKE til adressen den har fått, på UDP 500 eller på UDP 4500 når NAT-traversering er i spill. Den enheten som holder adressen på stien, mottar enten datagrammet lokalt og svarer på det, eller videresender det et annet sted. Det er de eneste to mulighetene, og alt annet i denne artikkelen følger av hvilken som er sann.

Lokal mottak betyr at det finnes en socket på den enheten, bundet til den adressen. Videresending betyr at datagrammet skrives om og sendes videre til et annet endepunkt, som da har socketen. En brannmurregel som tillater UDP 500, forteller deg ingenting om hvilken av de to som skjer.

Skriv ned registreringen før du rører noe: adressen peeren kontakter, hvordan oppstrømsnettet leverer den, det lokale grensesnittet eller det logiske endepunktet som mottar den, og prosessen som svarer på IKE. Fire linjer, og hver kan kontrolleres. Når én av dem er ukjent, er det ukjente designarbeidet og ikke en implementasjonsdetalj som avgjøres senere. Å fylle dem ut etter at endringsforespørselen er godkjent, er hvordan en oversettelsesregel havner på feil enhet.

Modell A: gatewayen eier adressen

I den første modellen holder gatewayen adressen selv, enten som sekundæradresse på et eksisterende grensesnitt, som adresse på et dedikert grensesnitt, eller som loopback som plattformen støtter som tunnelendepunkt. Det er tre ulike funksjoner med tre ulike konfigurasjonsveier, og en plattform som støtter den ene, støtter kanskje ikke de andre.

Bekreft at plattformen og utgivelsen støtter nøyaktig denne ordningen før du designer rundt den. En rutet blokk, en ekstra adresse på et grensesnitt og et loopback-endepunkt kan ikke byttes om, og dokumentasjonen for én utgivelse lover ikke at den neste oppfører seg likt.

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

Den lyttende socketen er beviset. Hvis ingenting er bundet til adressen, er ikke gatewayen terminatoren uansett hva rutetabellen sier, og en pakkefangst vil vise datagrammene ankomme uten at noe svarer dem.

Ikke sett et andre grensesnitt inn i et subnett som allerede finnes andre steder i topologien, og ikke anta at plattformen ordner det. Overlappende grensesnitt-subnett gir tvetydig kildevalg og, på mange plattformer, en blank avvisning av å konfigurere.

Modell B: en oppstrøms enhet oversetter den

I den andre modellen holder en oppstrøms brannmur den dedikerte adressen og videresender trafikken til en annen VPN-gateway. Det er en destinasonsoversettelse med en returvei, og det er et fullstendig gyldig design så lenge det dokumenteres som sådant.

Det den ikke er, er bevis for at den oppstrøms enheten har fått en lokal VPN-socket. Oversettelsen videresender pakker; den gjør ikke den øverste boksen til en IKE-responder. Hvis den oppstrøms regelen fjernes eller returveien bryter, stopper VPN-en selv om gatewayen er sunn og dens egne lyttere intakte.

Registrer begge adressene: den peeren kontakter, og den gatewayen faktisk ser. Registrer deretter transporten og returveien, fordi en oversettelse som virker for UDP 500 men ikke for innkapslet ESP, vil koble til og deretter ikke klare å bære trafikk, noe som er en forvirrende feil å feilsøke senere.

Identitet er ikke den ytre adressen

IPsec skiller tunnelendepunktet fra trafikken det beskytter, og arkitekturen holder disse beslutningene på ulike steder. Å endre adressen peeren kontakter, endrer ikke automatisk hvilke indre prefikser som er tillatt, hvilke ruter som installeres, eller hvilke ressurser sesjonen kan nå.

Den autentiserte identiteten er igjen separat. IKEv2 bærer en identitetsnyttelast og en autentiseringsutveksling som ikke trenger å samsvare med den ytre pakkeadressen, og nettopp derfor kan et oversatt design fortsatt autentisere riktig.

Den uavhengigheten er nyttig og samtidig en felle. To DNS-navn som løses til én vanlig lytter, velger ikke forskjellige VPN-backender, og et sertifikat som navngir én identitet, vil ikke tilfredsstille en peer som forventer en annen. Bekreft hva peeren validerer før du antar at adressen alene avgjør det.

Godta designet ved å se på én tilkobling

Undersøk hvor en ny autorisert tilkobling faktisk leveres, hvilken identitet som svarer, og hvilken privat flyt som deretter tillates. Tre observasjoner, tre ulike lag, og et vellykket offentlig oppslag av adressen tester ingen av dem.

Behold også det negative tilfellet: en peer som ikke skal godtas, eller et indre prefiks som ikke skal være nåbart, verifisert etter endringen. Registreringen du skrev i starten, er det som gjør den testen mulig uten å rekonstruere designet fra hukommelsen.

Poenget med alt dette er å la nettverkseieren velge en støttet tildelingsmetode i stedet for å stole på en generell påstand om hva enhver brannmur kan gjøre med en ekstra adresse. Det er nettopp den påstanden som er stedet der disse designene går galt, fordi den høres plausibel ut på enhver plattform og generelt ikke er sann på noen av dem. Registreringen på fire linjer avgjør det for plattformen din på ti minutter.