Hvem svarer egentlig på VPN'ets dedikerede adresse?

En adresse, der ligger ubrugt i organisationens tildeling, er ikke en lytter, og at føje den til en firewall skaber ingen. Noget skal afslutte IKE på den adresse, og mekanismen afhænger af, om gatewayen ejer adressen, eller om en opstrøms enhed oversætter den. Pakkestien er det, der skelner de to, og den afgør, hvilken platformsfunktion du har brug for, før nogen åbner en ændringsanmodning. Modellér stien først, og vælg derefter.

Pakkestien bag adressen

En peer sender IKE til den adresse, den har fået, på UDP 500 eller på UDP 4500, når NAT-gennemtrængning er i spil. Den enhed, der holder adressen på stien, modtager enten datagrammet lokalt og svarer på det, eller videresender det et andet sted hen. Det er de eneste to muligheder, og alt andet i denne artikel følger af, hvilken der er sand.

Lokal modtagelse betyder, at der findes en socket på den enhed, bundet til den adresse. Videresendelse betyder, at datagrammet omskrives og sendes videre til et andet endepunkt, som så har socket'en. En firewallregel, der tillader UDP 500, fortæller dig intet om, hvilken af de to der sker.

Skriv registreringen, før du rører noget: den adresse, peers kontakter, hvordan opstrømsnettet leverer den, det lokale interface eller logiske endepunkt, der modtager den, og den proces, der svarer på IKE. Fire linjer, og hver kan kontrolleres. Når en af dem er ukendt, er det ukendte designarbejdet snarere end en implementeringsdetalje, der afgøres senere. At udfylde dem, efter ændringsanmodningen er godkendt, er hvordan en oversættelsesregel bliver føjet til den forkerte enhed.

Model A: gatewayen ejer adressen

I den første model holder gatewayen selv adressen, enten som sekundær adresse på et eksisterende interface, som adresse på et dedikeret interface eller som loopback, som platformen understøtter som tunnelendepunkt. Det er tre forskellige funktioner med tre forskellige konfigurationsveje, og en platform, der understøtter den ene, understøtter måske ikke de andre.

Bekræft, at platformen og udgivelsen understøtter præcis den ordning, før du designer omkring den. En routet blok, en ekstra adresse på et interface og et loopback-endepunkt kan ikke udskiftes, og dokumentation for én udgivelse lover ikke, at den næste opfører sig på samme måde.

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

Den lyttende socket er beviset. Hvis intet er bundet til adressen, er gatewayen ikke terminator, uanset hvad routingtabellen siger, og en pakkefangst vil vise datagrammerne ankomme uden noget, der svarer dem.

Anbring ikke et andet interface i et subnet, der allerede findes andre steder i topologien, og gå ikke ud fra, at platformen løser det. Overlappende interface-subnet giver tvetydig kildevalg og på mange platforme en hel afvisning af at konfigurere.

Model B: en opstrøms enhed oversætter den

I den anden model holder en opstrøms firewall den dedikerede adresse og videresender trafikken til en anden VPN-gateway. Det er en destinationsoversættelse med en returvej, og det er et fuldstændig gyldigt design, så længe det dokumenteres som sådant.

Det, den ikke er, er bevis for, at den opstrøms enhed har fået en lokal VPN-socket. Oversættelsen videresender pakker; den gør ikke den øverste boks til IKE-responder. Hvis opstrømsreglen fjernes, eller dens returvej bryder, stopper VPN'en, selv om gatewayen er sund og dens egne lyttere intakte.

Registrér begge adresser: den, peers kontakter, og den, gatewayen faktisk ser. Registrér derefter transporten og returvejen, fordi en oversættelse, der virker for UDP 500 men ikke for indkapslet ESP, vil forbinde og derefter ikke kunne bære trafik, hvilket er en forvirrende fejl at fejlfinde senere.

Identitet er ikke den ydre adresse

IPsec adskiller tunnelendepunktet fra den trafik, det beskytter, og arkitekturen holder disse beslutninger forskellige steder. At ændre den adresse, peers kontakter, ændrer ikke automatisk, hvilke indre præfikser der tillades, hvilke ruter der installeres, eller hvilke ressourcer sessionen kan nå.

Den godkendte identitet er igen separat. IKEv2 bærer en identitetsnyttelast og en godkendelsesudveksling, som ikke behøver at matche den ydre pakkeadresse, og det er netop derfor et oversat design stadig kan godkende korrekt.

Den uafhængighed er nyttig og også en fælde. To DNS-navne, der opløses til én almindelig lytter, vælger ikke forskellige VPN-backends, og et certifikat, der navngiver én identitet, tilfredsstiller ikke en peer, der forventer en anden. Bekræft, hvad peer'en validerer, før du antager, at adressen alene afgør det.

Accepter designet ved at se på én forbindelse

Undersøg, hvor en ny autoriseret forbindelse faktisk leveres, hvilken identitet der svarer, og hvilken privat flow der derefter tillades. Tre observationer, tre forskellige lag, og et vellykket offentligt opslag af adressen tester ingen af dem.

Behold også det negative tilfælde: en peer, der ikke bør accepteres, eller et indre præfiks, der ikke bør være nåbart, verificeret efter ændringen. Den registrering, du skrev i starten, er det, der gør den test mulig uden at rekonstruere designet fra hukommelsen.

Pointen med alt dette er at lade netværksejeren vælge en understøttet tildelingsmetode i stedet for at stole på en generel påstand om, hvad enhver firewall kan gøre med en ekstra adresse. Den påstand er præcis, hvor disse designs går galt, fordi den lyder plausibel på enhver platform og generelt ikke er sand på nogen af dem. Registreringen på fire linjer afgør det for din platform på ti minutter.