Ekstra Mac VPN-ruter trenger en eier, ikke et innloggingsskript
En rute lagt til én gang ved innlogging er ikke en gjenoppkoblingspolicy. Gi fjerne prefikser en eier, og avgjør hvordan de vises, endres og forsvinner med den forbindelsen.
Å nå et privat prefiks gjennom en VPN er et krav med varighet: det gjelder så lenge den forbindelsen er brukbar, og det slutter når forbindelsen slutter. Et innloggingsskript kan ikke uttrykke det, fordi innlogging og tunnel-opp er forskjellige øyeblikk, og tunnelen som finnes ved innlogging er kanskje ikke den som bærer trafikk et minutt senere. Den første beslutningen er ikke hvilken kommando som skal kjøres. Det er hvilken komponent som eier prefikset.
Prefikset trenger en eier, ikke et øyeblikk
Begynn med å skrive kravet som en setning med et subjekt: nå 10.77.0.0/24 gjennom Office-VPN mens den forbindelsen er oppe. Den setningen navngir prefikset, forbindelsen og betingelsen, og den utelukker straks to populære erstatninger: en innloggingskrok og et grensesnittnavn som ppp0 eller utun2.
Grensesnittnavn tildeles ved kjøring og er ikke stabile mellom gjenoppkoblinger. En krok som matcher navnet den så forrige uke, vil enten ikke utløses eller utløses mot noen andres grensesnitt. Begge utfallene fremstår som en rutingfeil snarere enn den foreldede antakelsen de er. Den samme innvendingen gjelder for ethvert skript som er bundet til et navn som bare finnes mens én bestemt tunnel er oppe.
Bruk en støttet kilde til rutehensikt
Gatewayen, en administrert profil eller den eide klientens dokumenterte rutemekanisme er det rette stedet, når den mekanismen kan uttrykke kravet. Hvilken som gjelder avhenger av protokollen og leverandøren, og nøklene reiser ikke mellom dem, så en verdi som konfigurerer en profil OpenVPN forteller deg ingenting om den innebygde 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 |
For utviklere av pakketunneler eksponerer Apples IPv4-tunnelinnstillinger inkluderte og ekskluderte ruter eksplisitt, og IPv6 har sin motpart. Dette er API-er som leverandøren bruker, ikke bevis for at hvert innebygde VPN-panel tilbyr en administrator en vilkårlig ruteliste. Hvis den nåværende kombinasjonen ikke kan uttrykke prefiksene du trenger, er neste steg en støttet konfigurasjonsvei fra operatøren, ikke en annen app installert i håp om at den oppfører seg bedre.
Levetiden omfatter opprydding
Noen ganger er en ekstern hjelper virkelig nødvendig, og når den er det, er «legg til ruten» den minste delen av jobben. Den må vite hvilken forbindelse den tjener og hvilket grensesnitt den forbindelsen bruker, vente til den relevante nettverkstilstanden faller til ro, forbli idempotent når den kjøres to ganger på rad, og ikke rydde noe den ikke selv installerte.
Den siste klausulen er den som gjør vondt. En hjelper som sletter hver rute som matcher kontorprefikset, vil før eller siden slette en rute den ikke la til. Utfallet blir lagt på VPN-klienten, fordi klienten er den delen brukeren ser. Å bestemme hva en hjelper eier før du skriver den er billigere enn å forklare etterpå hvorfor et lokalt subnett sluttet å svare.
Gjenoppkoblingsløpet
Tenk deg en rask gjenoppkobling. Sesjon A faller, sesjon B kommer opp og installerer ruten sin, og så kjører A sin forsinkede opprydding endelig. Hvis den oppryddingen fjerner ruter etter prefiks, tar den B sin gyldige tilstand med seg, og forbindelsen som fungerte for et sekund siden ruter nå ut i ingenting.
Dette er et eierskapsløp, og å legge til en søvn i skriptet endrer bare hvilken side som vinner det. Løsningen er å gjøre opprydding avhengig av identitet: sammenlign grensesnittet og sesjonen hjelperen installerte med dem som fortsatt er gjeldende, og fjern bare ved treff.
Hva som skal testes, og hva en rute ikke kan gjøre
Aksept må dekke fire overganger: den første forbindelsen, en gjenoppkobling til et annet grensesnitt, et tilkoblingsforsøk som mislykkes, og den endelige frakoblingen. Etter hver av dem, les ruten systemet faktisk valgte for en adresse på den fjerne siden, ikke den du forventet.
route -n get 10.77.0.5
netstat -rn -f inetTa med de vanskelige tilfellene i samme runde: IPv6 der det kreves, et lokalt prefiks som overlapper det fjerne, og ruten til selve det offentlige VPN-endepunktet, som må fortsette å virke mens tunnelen er oppe. Skriv så ned hva en rute ikke er. Den velger pakker; den gir ikke tillatelse på den fjerne siden og lager ikke en returvei, og det forblir separate krav med separate eiere.
Resultatet du vil ha er et prefiks som følger sin støttede forbindelseseier gjennom hver overgang, snarere enn en kommando som tilfeldigvis lyktes én gang på maskinen der den ble skrevet.