Een privéprefix via een VPN bereiken is een vereiste met een duur: die geldt zolang die verbinding bruikbaar is, en eindigt wanneer de verbinding eindigt. Een inlogscript kan dat niet uitdrukken, want inloggen en tunnel-op zijn verschillende momenten, en de tunnel die bij het inloggen bestaat is misschien niet degene die een minuut later verkeer draagt. De eerste beslissing is niet welk commando je uitvoert. Het is welke component het prefix bezit.

Het prefix heeft een eigenaar nodig, geen moment

Begin met de vereiste als een zin met een onderwerp te schrijven: bereik 10.77.0.0/24 via de Office-VPN terwijl die verbinding actief is. Die zin noemt het prefix, de verbinding en de voorwaarde, en sluit meteen twee populaire vervangers uit: een inloghook en een interfacenaam zoals ppp0 of utun2.

Interfacenamen worden tijdens runtime toegewezen en zijn niet stabiel tussen herverbindingen. Een hook die overeenkomt met de naam die hij vorige week zag, vuurt ofwel niet of vuurt op iemands anders interface. Beide uitkomsten lijken op een routeringsfout en niet op de verouderde aanname die ze zijn. Dezelfde tegenwerping geldt voor elk script dat vastzit aan een naam die alleen bestaat zolang één specifieke tunnel actief is.

Gebruik een ondersteunde bron van route-intentie

De gateway, een beheerd profiel of het gedocumenteerde routemechanisme van de bezittende client is de juiste plek, wanneer dat mechanisme de vereiste kan uitdrukken. Welke geldt hangt af van het protocol en de provider, en de sleutels reizen niet tussen hen, dus een waarde die een profiel configureert OpenVPN zegt je niets over de native L2TP- of IKEv2-client.

MechanismCan carry extra prefixesWho owns the lifetime
Gateway-pushed routesOften, if the gateway is configured for itThe connection
Managed profile settingsDepends on the client and profile formatThe profile
Provider tunnel settingsYes, as included and excluded routesThe provider process
Manual commandYes, onceNobody

Voor ontwikkelaars van pakkettunnels stellen Apples IPv4-tunnelinstellingen inbegrepen en uitgesloten routes expliciet beschikbaar, en IPv6 heeft zijn tegenhanger. Dat zijn API's die de provider gebruikt, geen bewijs dat elk native VPN-paneel een beheerder een willekeurige routelijst biedt. Als de huidige combinatie de prefixen die je nodig hebt niet kan uitdrukken, is de volgende stap een ondersteund configuratiepad van de operator, niet een andere app die wordt geïnstalleerd in de hoop dat die zich beter gedraagt.

De levensduur omvat opruimen

Soms is een externe helper echt nodig, en dan is «voeg de route toe» het kleinste deel van zijn werk. Hij moet weten welke verbinding hij dient en welke interface die verbinding gebruikt, wachten tot de relevante netwerkstatus tot rust komt, idempotent blijven wanneer hij twee keer achter elkaar draait, en niets opruimen wat hij zelf niet heeft geïnstalleerd.

Die laatste clausule is degene die pijn doet. Een helper die elke route verwijdert die bij het kantoorprefix past, zal vroeg of laat een route verwijderen die hij niet heeft toegevoegd. De daaruit volgende storing wordt op de VPN-client afgeschoven, omdat de client het deel is dat de gebruiker ziet. Beslissen wat een helper bezit voordat je hem schrijft is goedkoper dan achteraf uitleggen waarom een lokaal subnet niet meer antwoordde.

De race bij het herverbinden

Denk aan een snelle herverbinding. Sessie A valt weg, sessie B komt op en installeert zijn route, en dan draait eindelijk de vertraagde opruiming van A. Als die opruiming routes op prefix verwijdert, neemt ze de geldige toestand van B mee, en de verbinding die een seconde geleden werkte, routeert nu naar niets.

Dit is een eigendomsrace, en een slaap aan het script toevoegen verandert alleen welke kant hem wint. De oplossing is opruimen afhankelijk te maken van identiteit: vergelijk de interface en sessie die de helper installeerde met de nog geldende, en verwijder alleen bij overeenkomst.

Wat te testen, en wat een route niet kan

Acceptatie moet vier overgangen dekken: de eerste verbinding, een herverbinding naar een andere interface, een mislukte verbindingspoging en de definitieve verbreking. Lees na elk daarvan de route die het systeem werkelijk koos voor een adres aan de andere kant, niet degene die je verwachtte.

route -n get 10.77.0.5
netstat -rn -f inet

Neem de lastige gevallen mee in dezelfde ronde: IPv6 waar dat nodig is, een lokaal prefix dat het externe overlapt, en de route naar het publieke VPN-eindpunt zelf, die moet blijven werken zolang de tunnel actief is. Schrijf dan op wat een route niet is. Hij selecteert pakketten; hij verleent geen toestemming aan de andere kant en maakt geen terugweg, en dat blijven aparte vereisten met aparte eigenaars.

Het resultaat dat je wilt is een prefix dat zijn ondersteunde verbindingseigenaar door elke overgang volgt, en niet een commando dat toevallig één keer slaagde op de machine waar het werd geschreven.

Gerelateerde artikelen