Blijvende routes voor een Mac-VPN: networksetup of een verbindingshook?

Een route die na elke verbinding wordt getypt, lost het moment op en niet de week. Op macOS is de duurzame keuze meestal een prefix dat bij de VPN-dienst wordt opgeslagen, omdat de dienst het bij elke verbinding opnieuw installeert en verwijdert wanneer de dienst niet draait. De alternatieven zijn een tijdelijk route add om te testen en een verbindingshook voor adressen die pas na de onderhandeling bekend zijn.

Bepaal of de route bij de dienst of bij de sessie hoort

Vraag waar het prefix van afhangt. Als het een vast privénetwerk achter een native VPN-dienst is, hoort de route bij die dienst. Als het afhangt van een peeradres dat per verbinding verandert, kan een hook of een statusgestuurde taak de betere eigenaar zijn. Als je alleen een pad voor de komende vijf minuten controleert, is een tijdelijke route genoeg.

De aan de dienst gebonden route heeft de schoonste levenscyclus. Hij verschijnt met de dienst en verdwijnt wanneer de dienst niet verbonden is, dus hij kan de tunnel waarnaar hij wijst niet overleven. Die eigenschap is meer waard dan het gemak van een commando van één regel.

Een aan de sessie gebonden route hoort bij de interface, en dat nummer verandert zonder waarschuwing. Een herverbinding kan de tunnel een andere utun-naam geven dan de vorige sessie gebruikte, waardoor een hardgecodeerd commando een route wordt die nergens naar wijst of, erger, naar een andere tunnel.

Lees de huidige route- en dienststatus

Begin met de namen die het systeem echt gebruikt. De dienstnaam in Netwerkinstellingen is de identificatie voor de onderstaande commando's, en de huidige routetabel laat zien wat de verbonden client heeft geïnstalleerd. Lees beide terwijl de tunnel actief is.

scutil --nc list
networksetup -listnetworkserviceorder
netstat -rn | head -30
route get 10.20.5.5

Die opzoeking laat zien welke gateway en interface de kernel op dit moment voor dit adres zou kiezen. Als hij al de tunnel kiest, is het prefix gedekt en zou een nieuwe route overbodig zijn. Als hij de lokale router kiest, ontbreekt dat prefix in de tunnel.

Noteer het peeradres terwijl je verbonden bent. Het wordt de gatewaywaarde in de aan de dienst gebonden route, en het is meestal de bestemming die voor de standaardroute van de tunnel in netstat -rn wordt getoond.

Sla het prefix op met networksetup

Het hulpmiddel networksetup koppelt extra routes aan een netwerkdienst. Voor een dienst met de naam OfficeVPN en een privéprefix dat via de peer van de tunnel bereikbaar is, is de vorm:

sudo networksetup -setadditionalroutes OfficeVPN 10.20.0.0 255.255.0.0 10.8.0.6
networksetup -getadditionalroutes OfficeVPN

Elke drietal na de dienstnaam geeft een bestemming, de netmasker en de peer van de tunnel als gateway. Eén aanroep kan meerdere prefixen dragen, en een lege aanroep wist de opgeslagen lijst. De lezer is de verificatiestap; als de lijst leeg is, is de set niet toegepast op de dienst die je bedoelt.

De gateway moet de peer van de tunnel zijn, niet de fysieke router. Een route die de lokale gateway noemt, stuurt het privéprefix via de fysieke interface naar buiten, wat de oorspronkelijke fout met extra stappen is. Een verouderde peer is de meest voorkomende reden waarom een correct uitziende route nooit verkeer draagt. Lees de peer opnieuw uit de verbonden toestand in plaats van een adres uit een oude notitie te kopiëren.

Gebruik route add alleen voor een test

Een directe route is nuttig om te bewijzen dat een prefix werkt voordat je het permanent maakt. De interfacevorm vermijdt een gatewayopzoeking:

sudo route -n add -net 10.20.0.0/16 -interface utun4

De route verdwijnt bij de volgende herverbinding en hangt af van het interfacenummer dat vandaag bestaat. Dat maakt het een diagnose, geen uitrol. Als de test werkt en de aan de dienst gebonden route niet, vergelijk dan eerst de gatewaywaarde; dat is het veld dat het vaakst fout is.

Wees voorzichtig met advies dat de standaardroute van de VPN vervangt om splitgedrag af te dwingen. Een client die een volledige tunnel afdwingt, kan zijn routes na een herverbinding of een beleidsvernieuwing opnieuw installeren, zodat de handmatige wijziging stil wordt teruggedraaid. Een handvol privéprefixen is een routeringsprobleem; al het internetverkeer lokaal houden tegen een full-tunnelbeleid is een beslissing aan de serverkant.

Kies alleen een hook wanneer het adres wordt onderhandeld

Voor op PPP gebaseerde verbindingen zoals L2TP voert macOS /etc/ppp/ip-up uit zodra de verbinding tot stand is. Het script ontvangt de interfacenaam en de onderhandelde lokale en externe adressen, zodat het een route kan toevoegen die afhangt van de peer die de server heeft toegewezen. Dat is precies het geval dat een vaste dienstroute niet kan uitdrukken.

IKEv2 en leveranciersclients gebruiken dat PPP-pad misschien helemaal niet, wat betekent dat het script de hele sessie stil kan blijven. Wanneer dat gebeurt, is een launchd-taak die scutil --nc status bevraagt en op een statuswijziging reageert, het equivalente mechanisme, met een kleine vertraging.

Welke hook je ook gebruikt, maak hem idempotent en laat hem alleen routes verwijderen die hij zelf heeft aangemaakt. Een script dat elke route verwijdert die de tunnel noemt, zal uiteindelijk de route verwijderen die de VPN-server bereikbaar houdt, en de verbinding valt weg zodra het lukt.

Sluit af met het controleren van de privébestemming, gewoon browsen en een herverbindings- of slaapcyclus. Inspecteer daarna scutil --dns, want naamresolutie is een apart beleid en een werkende route bewijst niet dat de privénamen worden opgelost.