Vestigings-VPN over 4G: houd de identiteit stabiel als het IP verschuift

Begin bij de vestiging zelf, op de WAN-statuspagina van de 4G-router. Als het adres dat je ziet in de privéruimte van de provider ligt in plaats van in een publieke, zal geen enkele port-forward op dat apparaat de hub ooit binnen laten bellen, en moet de tunnel van de vestiging naar buiten toe worden gebouwd. Die ene observatie bepaalt het ontwerp. De rest van het werk is zorgen dat de hub de vestiging herkent aan iets beters dan een adres dat elk paar uur verandert.

Waar de tunnel moet beginnen

Controleer het adres tegen de gedeelde adresruimte die providers voor hun eigen NAT gebruiken, 100.64.0.0/10, en tegen de gewone privéranges. Een daarvan op een mobiele uplink zien betekent meestal dat NAT op providerniveau tussen de vestiging en het internet zit, en dat inkomende verbindingen niet beschikbaar zijn voor welke prijs de vestiging dan ook kan betalen. Als het WAN-adres publiek is maar verandert, heb je een ander, eenvoudiger probleem.

Dynamische DNS helpt alleen in het tweede geval. Het geeft een veranderend publiek adres een stabiele naam om naartoe te bellen, en het kan geen mapping maken die de provider nooit heeft gegeven. Het is toch de moeite waard om het voor het publieke geval in te stellen, omdat het de enige handmatige stap bij een hernummering wegneemt. Wat het niet mag worden, is het antwoord voor een vestiging die de provider nooit bereikbaar heeft gemaakt.

Scheid het adres dat je belt van de identiteit die je matcht

De hub heeft iets stabiels nodig waarop hij te vinden is, een goedgekeurd vast adres of een onderhouden hostnaam. De vestiging heeft een stabiele manier nodig om herkend te worden, en in IKEv2 is dat de identiteitspayload die ze tijdens de authenticatie presenteert, los van het bronadres dat haar pakketten toevallig dragen. Een string als @branch-a.vpn.example werkt als die identiteit zelfs terwijl het mobiele adres elk uur verandert.

Die string wordt tegen beleid gematcht, niet via DNS opgelost, dus verwacht geen opzoeking bij het opzetten van de tunnel. De configuratie van de hub moet de verwachte identiteit expliciet benoemen, en bij certificaatauthenticatie moet de identiteit ook kloppen met wat het certificaat werkelijk beweert.

Elke identiteit accepteren omdat het bronadres plausibel lijkt, is de faalmodus die je moet vermijden. Aan de responder-kant betekent dat elke peer accepteren, met een identiteits-wildcard en een gedeeld geheim, wat een string authenticeert in plaats van een apparaat.

Schrijf de hubkant als een benoemde peer

In strongSwan-termen is de responder-kant een verbinding met right=%any, die een peer van elk bronadres accepteert, plus [email protected], dat vastzet als wat die peer zich moet voordoen. Voeg rightsubnet=10.20.0.0/16 toe voor de LAN's van de vestiging, auto=add zodat de verbinding wordt geladen zonder gebeld te worden, dpd_delay=30s voor levendigheid, en mobike=yes zodat een adreswijziging wordt geabsorbeerd in plaats van als nieuwe peer behandeld.

Andere leveranciers drukken dezelfde objecten onder andere namen uit, meestal een dynamisch peer- of filiaalkantoortype met een identiteitsveld en een veld voor het beschermde subnet. Vul beide in; een generiek dynamisch vinkje is geen compatibiliteitsplan.

Houd de vestiging als initiator

Op de vestiging geldt het spiegelbeeld: left=%defaultroute zodat het lokale mobiele adres wordt gebruikt zoals het nu is, [email protected] om de identiteit te presenteren, right=hub.example.com voor de stabiele hubnaam, en auto=start zodat de tunnel omhoog komt zonder mens. Als de mobiele link opnieuw verbindt, initieert de vestiging opnieuw en matcht de hub dezelfde identiteit tegen hetzelfde beleidsobject.

Sta IKE toe op UDP 500, NAT-traversal op UDP 4500 en de ingekapselde ESP die volgt, aan beide kanten. Laat ze daarna toegestaan: een regel die alleen tijdens kantooruren opengaat, zal als een wisselvallige tunnel lijken.

Test de adreswijziging, niet alleen de eerste handshake

Breng de tunnel omhoog, bevestig hem, en dwing de vestiging dan naar een nieuw adres door mobiele data of vliegtuigmodus een minuut aan en uit te zetten. Kijk naar de lijst met security-associations op de hub en controleer dat het peer-adres veranderde terwijl de identiteit dat niet deed. Een tunnel die alleen werkt tot de eerste hertoewijzing door de provider is helemaal niet getest.

Controleer daarna de beschermde subnetten apart. Een gevestigde SA zegt dat de peers zich hebben geauthenticeerd; hij zegt niet dat de hub een route naar de LAN van de vestiging heeft of dat de vestiging verkeer van de hubkant accepteert. Lees de routingtabel en het firewallbeleid apart, en stuur dan een ping vanaf een host in plaats van vanaf de gateway, want de gateway is het minst representatieve apparaat op elk netwerk.

Een stabiele identiteit maakt van de vestiging een beleidsobject dat de hub kan benoemen. Het maakt een carrier-NAT-adres niet bereikbaar, en het geeft de rest van de organisatie niet vanzelf toegang tot de vestiging.