Állandó útvonalak Mac VPN-hez: networksetup vagy csatlakozási hook?

Az egyes kapcsolatok után begépelt útvonal a pillanatot oldja meg, nem a hetet. macOS-en a tartós választás általában a VPN-szolgáltatással együtt tárolt előtag, mert a szolgáltatás minden kapcsolatnál újratelepíti, és eltávolítja, amikor a szolgáltatás leállt. Az alternatívák egy ideiglenes route add teszteléshez és egy csatlakozási hook a csak a tárgyalás után ismert címekhez.

Döntse el, az útvonal a szolgáltatáshoz vagy a munkamenethez tartozik

Kérdezze meg, mitől függ az előtag. Ha egy natív VPN-szolgáltatás mögötti rögzített magánhálózat, az útvonal ahhoz a szolgáltatáshoz tartozik. Ha egy minden kapcsolatnál változó partner-címtől függ, egy hook vagy egy állapotvezérelt feladat lehet a jobb tulajdonos. Ha csak a következő öt percre ellenőriz egy útvonalat, egy ideiglenes útvonal elegendő.

A szolgáltatáshoz kötött útvonalnak a legtisztább az életciklusa. A szolgáltatással együtt jelenik meg, és eltűnik, amikor a szolgáltatás nincs csatlakozva, így nem élhet tovább annál az alagúnál, amelyre mutat. Ez a tulajdonság többet ér az egysoros parancs kényelménél.

A munkamenethez kötött útvonal az interfészhez tartozik, és az a szám figyelmeztetés nélkül változik. Egy újracsatlakozás más utun-nevet adhat az alagúnak, mint amit az előző munkamenet használt, ami a keményen kódolt parancsot olyan útvonallá teszi, amely semmire vagy, ami rosszabb, egy másik alagútra mutat.

Olvassa ki az aktuális útvonal- és szolgáltatásállapotot

Kezdje azokkal a nevekkel, amelyeket a rendszer valóban használ. A Hálózati beállításokban szereplő szolgáltatásnév az alábbi parancsok azonosítója, az aktuális útvonaltábla pedig megmutatja, mit telepített a csatlakozott kliens. Olvassa ki mindkettőt, amíg az alagút fel van.

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

Ez a keresés megmutatja, melyik átjárót és interfészt választaná a kernel ehhez a címhez ebben a pillanatban. Ha már az alagutat választja, az előtag le van fedve, és egy új útvonal felesleges lenne. Ha a helyi routert választja, az alagútból hiányzik ez az előtag.

Jegyezze fel a partner címét, amíg csatlakozva van. Ez lesz az átjáró értéke a szolgáltatáshoz kötött útvonalban, és általában ez a cél, amelyet az alagút alapértelmezett útvonalához mutatnak a netstat -rn kimenetében.

Tárolja az előtagot a networksetup segítségével

A networksetup eszköz további útvonalakat csatol egy hálózati szolgáltatáshoz. Az OfficeVPN nevű szolgáltatás és az alagút partnere felé elérhető magán előtag esetében a forma:

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

A szolgáltatásnév utáni minden hármas megad egy célt, annak hálózati maszkját és az alagút partnerét átjáróként. Egy hívás több előtagot is hordozhat, és egy üres hívás törli a tárolt listát. Az olvasó az ellenőrzési lépés; ha a lista üres, a beállítás nem arra a szolgáltatásra vonatkozott, amelyre gondol.

Az átjárónak az alagút partnerének kell lennie, nem a fizikai routernek. Az az útvonal, amely a helyi átjárót nevezi meg, a fizikai interfészen keresztül küldi ki a magán előtagot, ami az eredeti hiba extra lépésekkel. Az elavult partner a leggyakoribb oka annak, hogy egy helyesnek látszó útvonal soha nem szállít forgalmat. Olvassa újra a partnert a csatlakozott állapotból, ahelyett hogy egy régi jegyzetből másolna címet.

A route add parancsot csak teszthez használja

A közvetlen útvonal hasznos annak bizonyítására, hogy egy előtag működik, mielőtt állandóvá teszi. Az interfészforma elkerüli az átjáró keresését:

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

Az útvonal eltűnik a következő újracsatlakozáskor, és a ma létező interfészszámtól függ. Ez diagnosztikává teszi, nem telepítéssé. Ha a teszt működik, és a szolgáltatáshoz kötött útvonal nem, először az átjáró értékét hasonlítsa össze; ez a mező leggyakrabban hibás.

Legyen óvatos azokkal a tanácsokkal, amelyek a VPN alapértelmezett útvonalát helyettesítik a felosztás kikényszerítéséhez. Egy teljes alagutat kikényszerítő kliens újratelepítheti az útvonalait egy újracsatlakozás vagy házirend-frissítés után, így a kézi módosítás csendben visszavonódik. Néhány magán előtag útválasztási probléma; az összes internetes forgalmat helyben tartani egy teljes alagút házirenddel szemben szerveroldali döntés.

Csak akkor válasszon hookot, ha a cím tárgyalás alatt áll

A PPP-alapú kapcsolatokhoz, például a L2TP esetében a macOS a kapcsolat létrejötte után futtatja a /etc/ppp/ip-up parancsot. A szkript megkapja az interfész nevét és a tárgyalt helyi és távoli címeket, így hozzáadhat egy útvonalat, amely a szerver által kiosztott partnertől függ. Pontosan ez az az eset, amelyet egy rögzített szolgáltatásútvonal nem tud kifejezni.

Lehet, hogy az IKEv2 és a gyártói kliensek egyáltalán nem használják ezt a PPP-útvonalat, ami azt jelenti, hogy a szkript az egész munkamenet alatt csendben maradhat. Amikor ez történik, egy launchd-feladat, amely a scutil --nc status állapotát kérdezi, és állapotváltozásra cselekszik, az egyenértékű mechanizmus, kis késleltetéssel.

Bármelyik hookot használja, tegye idempotenssé, és csak az általa létrehozott útvonalakat távolítsa el. Egy szkript, amely minden, az alagutat említő útvonalat töröl, végül törölni fogja azt az útvonalat is, amely elérhetővé teszi a VPN-kiszolgálót, és a kapcsolat azonnal megszakad, amint sikerül.

Fejezze be a magáncél, a szokásos böngészés és egy újracsatlakozási vagy alvási ciklus ellenőrzésével. Ezután vizsgálja meg a scutil --dns kimenetét, mert a névfeloldás külön házirend, és egy működő útvonal nem bizonyítja, hogy a magánnevek feloldódnak.