Hoe je een adressenpool voor VPN-clients plant die past

Begin in het poolveld op de VPN-server, niet in een spreadsheet. Wat je daar typt, wordt de interne adresruimte voor elke client die daarna verbindt, en die moet samengaan met het LAN dat die clients bereiken, de gerouteerde locaties erachter en elk adres dat de client thuis al heeft. Verbind één client zodra de pool is opgeslagen, want die eerste verbinding vertelt je of de waarde in de praktijk werkt. Van daaruit beweegt de rondleiding naar buiten: het adres dat de client kreeg, het pad dat een antwoord volgt en de notitie die je achterlaat.

Begin bij het poolveld, voordat er een client verbindt

Elk product toont dit anders, dus zoek het object dat adressen werkelijk toewijst. OpenVPN heeft een poolrichtlijn aan de serverkant die het volgende vrije adres uitgeeft, een IKEv2-gateway heeft een poolsectie die aan de peer-configuratie is gebonden, en WireGuard heeft geen van beide omdat elke peer zijn eigen adres in zijn configuratiebestand draagt. Een poolrichtlijn en een adres per peer zijn niet uitwisselbaar, en de verkeerde bewerken verspilt de rest van de rondleiding.

Als je het veld hebt, som dan de bereiken op die al bestaan: het kantoor-LAN, elke gerouteerde locatie, de cloud-VPC en elke andere pool die nog in gebruik is. Overlap wordt beslist door prefix-rekenkunde, niet door of de hostnummers vertrouwd lijken, dus vergelijk het aggregaat met elk van die bereiken. Twee bereiken die er beide als 10.x uitzien, zijn onschadelijk wanneer hun aggregaten elkaar niet snijden en een supportincident wanneer ze dat wel doen.

Beslis daarna of het adres een functie is van wie verbindt of van wanneer ze verbinden. Dynamische toewijzing deelt uit wat vrij is, terwijl toewijzing per identiteit een vast adres aan een referentie koppelt. Schrijf de keuze op, want die verandert hoe een herverbinding er later uit moet zien.

Lees het adres dat de client werkelijk ontving

Verbind één client en lees wat de tunnel meldt, niet wat de pool beloofde. De client toont zijn interne adres in de verbindingsstatus, en op Linux draagt de interface het rechtstreeks.

Vergelijk dat adres met het bereik dat je hebt opgeslagen. Ligt het buiten het bereik, dan kijk je naar een ander toewijzingspad dan het pad dat je bewerkte. Controleer ook de prefixlengte, want een client met een /32 heeft geen peer op de verbinding en stuurt elke bestemming via zijn standaardroute.

ip -4 addr show tun0
ip route get 192.168.50.20

Een client die verbindt vanaf een thuisrouter met hetzelfde bereik, verbindt en bereikt daarna bijna niets. De client houdt zijn lokale route voor dat prefix, zodat het tunneladres botst met het netwerk erachter en verkeer via de verkeerde interface vertrekt. Dat geval is op de server niet te repareren; de gedocumenteerde oplossing is het thuisnetwerk hernummeren of een poolbereik kiezen dat ver genoeg weg ligt om botsingen zeldzaam te houden. Noteer zowel de fout als de oplossing, want de helpdesk komt hem opnieuw tegen.

Verbind dezelfde client opnieuw en let op het adres. Een dynamische pool kan dezelfde waarde of een andere teruggeven en beide zijn juist, terwijl een pool per identiteit die het adres wijzigt de binding niet respecteert. Die controle kost seconden en beslist of de modus die je in de eerste sectie noteerde, de modus is die geldt.

Volg een antwoord terug vanaf de dienst

De pool werkt alleen wanneer antwoorden terug kunnen reizen. Een dienst op het LAN antwoordt op het interne adres, dus de gateway ervan heeft een route voor de pool nodig of een vertaling voor de dienst. Wanneer een verzoek via de tunnel binnenkomt en het antwoord via een ander pad vertrekt, laat een stateful firewall of een reverse-path-controle het vallen, en de client ziet een dienst die verbindt en dan blijft hangen. Zet de pool in het routingontwerp als één samenvatbaar blok in plaats van routes per host toe te voegen.

Vertaling verandert wat de rest van het systeem ziet. Wanneer de bron wordt herschreven, is het adres in de hostfirewall en in het applicatielog het vertaalde, dus een regel die tegen het pooladres is geschreven, matcht niets en een logregel is niet naar een client te herleiden. De strongSwan-documentatie over doorsturen dekt de serverkant van dat pad voor een IKEv2-gateway. DNS draagt dezelfde beperking, want een naam die naar een adres resolvet dat de client niet kan bereiken, faalt later en elders.

Twee clients, dan één intrekking

Verbind twee clients tegelijk en lees beide adressen. Ze moeten verschillend, bruikbaar en binnen de pool zijn, en elk moet de dienst bereiken waarvoor het bedoeld is. Een pool die dubbele adressen uitgeeft, toont zich meestal hier en niet in de eerste test met één client.

Trek één referentie in terwijl de andere client verbonden blijft, en probeer daarna de dienst vanaf de overlevende client. Een intrekking die de andere sessie verstoort, wijst op gedeelde toestand, meestal één referentie of één adres dat over apparaten wordt hergebruikt. Verbind de ingetrokken client opnieuw en bevestig dat hij wordt geweigerd in plaats van het vrijgekomen adres te krijgen.

Sluit af met een bestemming die geweigerd zou moeten worden. Een client die alles bereikt, is verbonden, niet getest.

Schrijf de vier waarden waar de volgende wijziging ze vindt

De notitie is kort: het poolbereik en het prefix, de toewijzingsmodus, het terugpad of de vertaling in gebruik en de DNS-omvang die voor die bestemmingen antwoordt. Leg hem naast de serverconfiguratie in plaats van in een ticket, en dateer hem. Wie later een van de vier wijzigt, heeft de andere drie voor zich nodig, want een wijziging van de poolgrootte breekt de route en een routewijziging breekt het DNS-antwoord.

Houd de eigendomsnotitie erbij: het tunnelbereik is van de VPN-server, en een reservering in het DHCP-bereik van het LAN reserveert niets voor een client binnen de tunnel. Die ene regel voorkomt het meest voorkomende herwerk, waarbij iemand een reservering toevoegt en verwacht dat het tunneladres die volgt.