Extra Mac VPN-rutter behöver en ägare, inte ett inloggningsskript
En rutt som läggs till en gång vid inloggning är inte en återanslutningspolicy. Ge avlägsna prefix en ägare och bestäm hur de visas, ändras och försvinner med den anslutningen.
Att nå ett privat prefix genom en VPN är ett krav med varaktighet: det gäller så länge den anslutningen är användbar, och det slutar när anslutningen slutar. Ett inloggningsskript kan inte uttrycka det, eftersom inloggning och tunnel-upp är olika ögonblick, och tunneln som finns vid inloggning är kanske inte den som bär trafik en minut senare. Det första beslutet är inte vilket kommando som ska köras. Det är vilken komponent som äger prefixet.
Prefixet behöver en ägare, inte ett ögonblick
Börja med att skriva kravet som en mening med ett subjekt: nå 10.77.0.0/24 genom Office-VPN medan den anslutningen är uppe. Den meningen namnger prefixet, anslutningen och villkoret, och den utesluter genast två populära ersättare: en inloggningshook och ett gränssnittsnamn som ppp0 eller utun2.
Gränssnittsnamn tilldelas vid körning och är inte stabila mellan återanslutningar. En hook som matchar namnet den såg förra veckan utlöses antingen inte eller utlöses mot någon annans gränssnitt. Båda utfallen framstår som ett routingfel snarare än det föråldrade antagandet de är. Samma invändning gäller för varje skript som är knutet till ett namn som bara finns medan en viss tunnel är uppe.
Använd en stödd källa för ruttavsikt
Gatewayen, en hanterad profil eller den ägande klientens dokumenterade ruttmekanism är rätt plats, när den mekanismen kan uttrycka kravet. Vilken som gäller beror på protokollet och leverantören, och nycklarna reser inte mellan dem, så ett värde som konfigurerar en profil OpenVPN säger ingenting om den inbyggda L2TP- eller IKEv2-klienten.
| Mechanism | Can carry extra prefixes | Who owns the lifetime |
|---|---|---|
| Gateway-pushed routes | Often, if the gateway is configured for it | The connection |
| Managed profile settings | Depends on the client and profile format | The profile |
| Provider tunnel settings | Yes, as included and excluded routes | The provider process |
| Manual command | Yes, once | Nobody |
För utvecklare av pakettunnlar exponerar Apples IPv4-tunnelinställningar uttryckligen inkluderade och exkluderade rutter, och IPv6 har sin motsvarighet. Det är API:er som leverantören använder, inte bevis för att varje inbyggd VPN-panel erbjuder en administratör en godtycklig ruttlista. Om den nuvarande kombinationen inte kan uttrycka de prefix du behöver, är nästa steg en stödd konfigurationsväg från operatören, inte en annan app installerad i hopp om att den ska bete sig bättre.
Livstiden omfattar städning
Ibland är en extern hjälpare verkligen nödvändig, och då är «lägg till rutten» den minsta delen av dess arbete. Den måste veta vilken anslutning den tjänar och vilket gränssnitt den anslutningen använder, vänta tills det relevanta nätverkstillståndet har lagt sig, förbli idempotent när den körs två gånger i rad, och inte städa något som den inte själv har installerat.
Den sista klausulen är den som gör ont. En hjälpare som raderar varje rutt som matchar kontorsprefixet kommer förr eller senare att radera en rutt som den inte lade till. Det resulterande avbrottet läggs på VPN-klienten, eftersom klienten är den del användaren ser. Att bestämma vad en hjälpare äger innan du skriver den är billigare än att i efterhand förklara varför ett lokalt subnät slutade svara.
Kapplöpningen vid återanslutning
Tänk dig en snabb återanslutning. Session A faller, session B kommer upp och installerar sin rutt, och sedan körs A:s fördröjda städning äntligen. Om den städningen tar bort rutter efter prefix tar den med sig B:s giltiga tillstånd, och anslutningen som fungerade för en sekund sedan routar nu ut i ingenting.
Detta är en ägarkapplöpning, och att lägga till en sömn i skriptet ändrar bara vilken sida som vinner den. Lösningen är att göra städningen beroende av identitet: jämför gränssnittet och sessionen som hjälparen installerade med dem som fortfarande gäller, och ta bort endast vid träff.
Vad som ska testas, och vad en rutt inte kan göra
Acceptansen måste täcka fyra övergångar: den första anslutningen, en återanslutning till ett annat gränssnitt, ett anslutningsförsök som misslyckas, och den slutliga frånkopplingen. Efter var och en, läs rutten som systemet faktiskt valde för en adress på den avlägsna sidan, inte den du förväntade dig.
route -n get 10.77.0.5
netstat -rn -f inetTa med de besvärliga fallen i samma omgång: IPv6 där det krävs, ett lokalt prefix som överlappar det avlägsna, och rutten till själva den offentliga VPN-slutpunkten, som måste fortsätta att fungera medan tunneln är uppe. Skriv sedan ned vad en rutt inte är. Den väljer paket; den ger inte tillstånd på den avlägsna sidan och skapar inte en returväg, och det förblir separata krav med separata ägare.
Det resultat du vill ha är ett prefix som följer sin stödda anslutningsägare genom varje övergång, snarare än ett kommando som råkade lyckas en gång på maskinen där det skrevs.