Vem svarar egentligen på VPN:ets dedikerade adress?

En adress som ligger oanvänd i organisationens tilldelning är inte en lyssnare, och att lägga till den i en brandvägg skapar ingen. Något måste avsluta IKE på den adressen, och mekanismen varierar beroende på om gatewayen äger adressen eller en uppströms enhet översätter den. Det är paketvägen som skiljer de två, och den avgör vilken plattformsfunktion du behöver innan någon öppnar en ändringsbegäran. Modellera vägen först och välj sedan.

Paketvägen bakom adressen

En peer skickar IKE till adressen den fått, på UDP 500 eller på UDP 4500 när NAT-traversering är inblandat. Den enhet som håller adressen på vägen tar antingen emot datagrammet lokalt och svarar på det, eller vidarebefordrar det någon annanstans. Det är de enda två möjligheterna, och allt annat i den här artikeln följer av vilken som är sann.

Lokal mottagning betyder att det finns en socket på den enheten, bunden till den adressen. Vidarebefordran betyder att datagrammet skrivs om och skickas vidare till en annan ändpunkt, som då har socketen. En brandväggsregel som tillåter UDP 500 säger ingenting om vilken av de två som sker.

Skriv registreringen innan du rör något: adressen peeren kontaktar, hur uppströmsnätet levererar den, det lokala gränssnittet eller den logiska ändpunkten som tar emot den, och processen som svarar på IKE. Fyra rader, och var och en kan kontrolleras. När en av dem är okänd är det okända designarbetet och inte en implementationsdetalj som avgörs senare. Att fylla i dem efter att ändringsbegäran godkänts är hur en översättningsregel hamnar på fel enhet.

Modell A: gatewayen äger adressen

I den första modellen håller gatewayen adressen själv, antingen som sekundäradress på ett befintligt gränssnitt, som adress på ett dedikerat gränssnitt, eller som loopback som plattformen stöder som tunneländpunkt. Det är tre olika funktioner med tre olika konfigurationsvägar, och en plattform som stöder den ena stöder kanske inte de andra.

Bekräfta att plattformen och utgåvan stöder exakt denna ordning innan du designar runt den. Ett routat block, en extra adress på ett gränssnitt och en loopback-ändpunkt är inte utbytbara, och dokumentationen för en utgåva lovar inte att nästa beter sig likadant.

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

Den lyssnande socketen är beviset. Om ingenting är bundet till adressen är gatewayen inte terminatorn oavsett vad routingtabellen säger, och en paketfångst visar datagrammen anlända utan att något svarar dem.

Placera inte ett andra gränssnitt i ett subnät som redan finns någon annanstans i topologin och anta inte att plattformen löser det. Överlappande gränssnitts-subnät ger tvetydigt källval och, på många plattformar, en blank vägran att konfigurera.

Modell B: en uppströms enhet översätter den

I den andra modellen håller en uppströms brandvägg den dedikerade adressen och vidarebefordrar trafiken till en annan VPN-gateway. Det är en destinationsöversättning med en returväg, och det är en fullständigt giltig design så länge den dokumenteras som sådan.

Vad den inte är, är bevis på att den uppströms enheten har fått en lokal VPN-socket. Översättningen vidarebefordrar paket; den gör inte den övre boxen till en IKE-svarare. Om den uppströms regeln tas bort eller dess returväg bryts, stannar VPN:et även om gatewayen är frisk och dess egna lyssnare intakta.

Registrera båda adresserna: den peeren kontaktar och den gatewayen faktiskt ser. Registrera sedan transporten och returvägen, eftersom en översättning som fungerar för UDP 500 men inte för inkapslad ESP ansluter och sedan misslyckas med att bära trafik, vilket är ett förvirrande fel att felsöka senare.

Identitet är inte den yttre adressen

IPsec skiljer tunneländpunkten från trafiken den skyddar, och arkitekturen håller dessa beslut på olika ställen. Att ändra adressen peeren kontaktar ändrar inte automatiskt vilka inre prefix som tillåts, vilka rutter som installeras eller vilka resurser sessionen kan nå.

Den autentiserade identiteten är återigen separat. IKEv2 bär en identitetsnyttolast och ett autentiseringsutbyte som inte behöver stämma med den yttre paketadressen, och det är just därför en översatt design fortfarande kan autentisera korrekt.

Det oberoendet är användbart och samtidigt en fälla. Två DNS-namn som löser till en vanlig lyssnare väljer inte olika VPN-backends, och ett certifikat som namnger en identitet kommer inte att tillfredsställa en peer som förväntar sig en annan. Bekräfta vad peeren validerar innan du antar att adressen ensam avgör det.

Acceptera designen genom att observera en anslutning

Undersök var en ny auktoriserad anslutning faktiskt levereras, vilken identitet som svarar och vilket privat flöde som sedan tillåts. Tre observationer, tre olika lager, och ett lyckat offentligt uppslag av adressen testar ingen av dem.

Behåll också det negativa fallet: en peer som inte ska accepteras, eller ett inre prefix som inte ska vara nåbart, verifierat efter ändringen. Registreringen du skrev i början är det som gör det testet möjligt utan att rekonstruera designen ur minnet.

Poängen med allt detta är att låta nätverksägaren välja en stödd tilldelningsmetod i stället för att lita på ett allmänt påstående om vad varje brandvägg kan göra med en extra adress. Det är just det påståendet som är stället där dessa designer går fel, eftersom det låter rimligt på varje plattform och generellt inte är sant på någon av dem. Registreringen på fyra rader avgör det för din plattform på tio minuter.