Een openbaar prefix voor VPN-clients: wat het echt breekt

Een clientpool die is gekozen omdat de nummers er netjes uitzien, is een route die wacht om geïnstalleerd te worden. Het prefix hoeft niet privé te zijn wil de VPN werken, en het gebruik van een blok dat van iemand anders is, stelt je gebruikers ook niet automatisch bloot aan het internet. Wat het doet, is die adressen iets anders laten betekenen zolang de tunnel staat, en daarna weer iets anders wanneer hij wegvalt. Loop de vijf controles hieronder in volgorde door en stop waar het antwoord „elders toegewezen“ is.

Toewijzen is geen aankondiging

Een adres op een tunnelinterface zetten kondigt het niet aan het internet aan. Publieke bereikbaarheid vereist een route, een geautoriseerd pad en een provider die bereid is het te dragen, en niets daarvan verschijnt omdat een client het adres uit een pool heeft gekregen. Firewallbeleid en hostautorisatie zijn weer aparte beslissingen.

Daarom is het risico niet wat de meeste mensen aannemen. Het geleende prefix maakt je clients niet bereikbaar; het maakt de bestemmingen van iemand anders onbereikbaar vanaf je clients, wat een ander falen is met een andere eigenaar. Niemand wordt aangevallen en er ontsnapt geen aankondiging. Een gebruiker kan simpelweg een site niet openen die gisteren nog werkte, en de helpdesk heeft geen reden om de VPN-pool te verdenken.

Het onderscheid is belangrijk wanneer je een pool kiest. Als je enige zorg blootstelling aan het internet was, zou een openbaar blok veilig lijken omdat niets het aankondigt. De zorg is de lokale route die de client voor dat prefix installeert, en die route wordt geïnstalleerd of iemand anders hem kan zien of niet.

Wat de clientroute werkelijk vastlegt

Wanneer de tunnel omhoog komt, ontvangt de client een route voor het prefix van de pool, en die route wint van de standaardroute voor elke bestemming erbinnen. Een verzoek aan een legitieme host in dat blok gaat nu naar de VPN in plaats van naar het internet. Of het faalt, blijft hangen of de verkeerde server bereikt, hangt af van wat jouw kant ermee doet.

ip route get 198.51.100.20
ip -br addr show tun0
traceroute -n 198.51.100.20

Voer de opzoeking uit met de tunnel omhoog en opnieuw met de tunnel omlaag. Het adres betekent het ene in het eerste geval en iets heel anders in het tweede, en elke applicatie die een verbinding of een naamresolutie over die overgang heeft gecachet, gedraagt zich inconsistent. Die inconsistentie is moeilijker te ondersteunen dan een schone fout, omdat ze van timing afhangt. Een gebruiker die op het verkeerde moment opnieuw verbindt, krijgt een andere ervaring dan een die dat niet doet.

Daarom is een bekend IP-adres ook geen bewijs van identiteit. Behoud certificaat- en servernaamvalidatie voor de echte bestemming, want het numerieke adres dat je vijf minuten geleden bereikte, kan nu bij een ander gesprek horen.

Vergelijk de pool met elk netwerk dat je kent

RFC 1918 reserveert drie blokken voor privégebruik: 192.168.0.0/16, 172.16.0.0/12 en 10.0.0.0/8. Miljoenen afzonderlijke organisaties hergebruiken ze, dus privé is een uitspraak over toewijzing en nooit een belofte dat niemand anders dezelfde nummers heeft gekozen.

Vergelijk de kandidaatpool met kantoor-LAN's, cloud-VPC's, andere VPN-pools, partnerverbindingen en de bereiken die thuiswerkers waarschijnlijk thuis hebben. Het thuisgeval is geen reden om een vreemd prefix te bedenken; het is een reden om de pool klein en gedocumenteerd te houden.

Stem de toewijzing af met wie het routeren bezit, en leg de terugweg op dezelfde plek vast. Een pool waar niemand naartoe kan terugrouteren, is een pool die tijdens een storing opnieuw wordt ontdekt. Zet de pool in hetzelfde document als de sitebereiken, niet in een clientconfiguratie die maar één persoon heeft bewerkt. Het document is wat de volgende botsing vermijdbaar maakt.

Wanneer openbare adressering het juiste antwoord is

Organisaties met correct toegewezen wereldwijde ruimte kunnen heel goed een openbaar geadresseerde VPN-pool bouwen, en sommige doen dat bewust om vertaling te vermijden. Dat ontwerp heeft nog steeds routering, bronvalidatie, toegangsregels en clientauthenticatie nodig; de toewijzing levert daar niets van.

Wat het wel levert, is uniekheid, de eigenschap die het geleende prefix mist. Als je het blok bezit, wijst de route die je client installeert naar adressen die echt van jou zijn, en de betekenis verandert niet wanneer de tunnel wegvalt.

Voeg niet automatisch NAT toe om een poolkeuze te compenseren. Een gerouteerd privéontwerp met expliciete terugroutes is schoner dan vertaling die wordt toegepast omdat de adressering nooit is gepland, en IPv6 heeft zijn eigen bewuste plan nodig in plaats van een kopie van de IPv4-aannames.

Haal een slechte pool uit gebruik zonder toegang te verliezen

Als de pool al is uitgerold, maak dan een inventaris voordat je hem wijzigt: adresreserveringen, geïnstalleerde routes, DNS-records die in het blok oplossen, firewallbereiken en de applicaties die ervan afhangen. Plan daarna de wijziging met dezelfde zorg als elke andere routeringsovergang. Kondig hem aan bij de mensen die het zullen merken, want hun sessies vallen weg wanneer de pool verschuift. Een stille wijziging in clientadressering levert supporttickets op die niets met het werk te maken lijken te hebben.

Behoud een herstelpad dat niet afhangt van de pool die je verwijdert, want het moment waarop je hem intrekt is het moment waarop je externe toegang ermee kan verdwijnen. Valideer daarna beide richtingen: de beoogde privébestemmingen werken nog, en de internetbestemmingen die eerder werden gevangen, lossen nu op naar hun echte eigenaars.

Wat je wilt, is een pool die het netwerkteam als één samenhangend ding kan toewijzen, routeren en uit gebruik nemen. Een adresformaat op zichzelf vestigt noch veiligheid noch connectiviteit.