Så planerar du en adresspool för VPN-klienter som passar

Börja i poolfältet på VPN-servern, inte i ett kalkylblad. Det du skriver där blir det inre adressutrymmet för varje klient som ansluter efteråt, och det måste samsas med det LAN som dessa klienter når, de routade platserna bakom det och varje adress som klienten redan har hemma. Anslut en klient så snart poolen är sparad, eftersom den första anslutningen berättar om värdet fungerar i praktiken. Därifrån rör sig genomgången utåt: adressen klienten fick, vägen ett svar tar och anteckningen du lämnar efter dig.

Börja vid poolfältet, innan någon klient ansluter

Varje produkt visar detta olika, så hitta objektet som faktiskt tilldelar adresser. OpenVPN har ett pooldirektiv på serversidan som delar ut nästa lediga adress, en IKEv2-gateway har en poolsektion bunden till peer-konfigurationen, och WireGuard har ingen av dem eftersom varje peer bär sin egen adress i sin konfigurationsfil. Ett pooldirektiv och en adress per peer är inte utbytbara, och att redigera fel en slösar bort resten av genomgången.

När du har fältet, lista intervallen som redan finns: kontorets LAN, varje routad plats, molnets VPC och varje annan pool som fortfarande är i drift. Överlapp avgörs av prefixaritmetik, inte av om värdnumren verkar bekanta, så jämför aggregatet med vart och ett av dessa intervall. Två intervall som båda ser ut som 10.x är ofarliga när deras aggregat inte skär varandra och en supportincident när de gör det.

Bestäm sedan om adressen är en funktion av vem som ansluter eller av när de ansluter. Dynamisk tilldelning delar ut det som är ledigt, medan tilldelning per identitet binder en fast adress till en autentiseringsuppgift. Skriv ned valet, eftersom det ändrar hur en återanslutning ska se ut senare.

Läs adressen som klienten faktiskt fick

Anslut en klient och läs vad tunneln rapporterar, inte vad poolen lovade. Klienten visar sin inre adress i anslutningsstatusen, och på Linux bär gränssnittet den direkt.

Jämför den adressen med intervallet du sparade. Om den ligger utanför intervallet ser du en annan tilldelningsväg än den du redigerade. Kontrollera också prefixlängden, eftersom en klient med en /32 inte har någon on-link-peer och skickar varje destination via sin standardrutt.

ip -4 addr show tun0
ip route get 192.168.50.20

En klient som ansluter från en hemrouter med samma intervall ansluter och når sedan nästan ingenting. Klienten behåller sin lokala rutt för det prefixet, så tunneladressen krockar med nätet bakom den och trafiken lämnar via fel gränssnitt. Det fallet kan inte repareras på servern; den dokumenterade åtgärden är att numrera om hemnätet eller välja ett poolintervall som ligger tillräckligt långt bort för att kollisioner ska förbli sällsynta. Notera både felet och åtgärden, eftersom helpdesken kommer att möta det igen.

Anslut samma klient igen och följ adressen. En dynamisk pool kan returnera samma värde eller ett annat och båda är korrekta, medan en pool per identitet som ändrar adressen inte respekterar bindningen. Den kontrollen tar sekunder och avgör om läget du noterade i första avsnittet är läget som gäller.

Följ ett svar tillbaka från tjänsten

Poolen fungerar bara när svar kan resa tillbaka till den. En tjänst på LANet svarar på den inre adressen, så dess gateway behöver en rutt för poolen eller en översättning framför tjänsten. När en begäran kommer genom tunneln och svaret lämnar via en annan väg, släpper en tillståndsbaserad brandvägg eller en omvänd ruttkontroll det, och klienten ser en tjänst som ansluter och sedan hänger. Sätt in poolen i routingdesignen som ett enda sammanfattningsbart block i stället för att lägga till rutter per värd.

Översättning ändrar vad resten av systemet ser. När källan skrivs om är adressen i värdens brandvägg och i applikationsloggen den översatta, så en regel skriven mot pooladressen matchar ingenting och en loggrada kan inte spåras tillbaka till en klient. strongSwan-dokumentationen om vidarebefordran täcker serverhalvan av den vägen för en IKEv2-gateway. DNS bär samma begränsning, eftersom ett namn som löses till en adress klienten inte kan nå misslyckas senare och någon annanstans.

Två klienter, sedan en återkallelse

Anslut två klienter samtidigt och läs båda adresserna. De måste vara olika, användbara och inne i poolen, och var och en måste nå tjänsten den är avsedd för. En pool som delar ut dubbeladresser visar sig vanligtvis här och inte i det första testet med en klient.

Återkalla en autentiseringsuppgift medan den andra klienten är kvar ansluten, och prova sedan tjänsten från den överlevande klienten. En återkallelse som stör den andra sessionen pekar på delat tillstånd, oftast en autentiseringsuppgift eller en adress som återanvänds mellan enheter. Anslut den återkallade klienten igen och bekräfta att den nekas i stället för att få den frigjorda adressen.

Avsluta med en destination som borde nekas. En klient som når allt har blivit ansluten, inte testad.

Skriv de fyra värdena där nästa ändring hittar dem

Anteckningen är kort: poolintervallet och prefixet, tilldelningsläget, returvägen eller översättningen i bruk och det DNS-omfång som svarar för dessa destinationer. Lägg den bredvid serverkonfigurationen i stället för i ett ärende, och datera den. Den som senare ändrar en av de fyra behöver de andra tre framför sig, eftersom en ändring av poolens storlek bryter rutten och en ruttändring bryter DNS-svaret.

Håll ägandeanteckningen tillsammans med den: tunnelintervallet tillhör VPN-servern, och en reservation gjord i LANets DHCP-omfång reserverar ingenting för en klient inne i tunneln. Den enda raden förhindrar det vanligaste omarbetet, där någon lägger till en reservation och förväntar sig att tunneladressen följer den.