Stav VPN v macOS z terminálu: scutil, trasy alebo ping

Niekde v nasadzovacom skripte je kontrola, či je tunel aktívny, skôr než sa začne kopírovanie. K dispozícii sú tri odpovede a neznamenajú to isté: stav služby, ktorý hlási scutil, trasa, ktorú vybralo jadro, a to, či druhý koniec naozaj odpovedá. Ich porovnanie je rozdiel medzi kontrolou, ktorá kopírovanie predpovedá, a kontrolou, ktorá iba zdobí log.

Tri odpovede na otázku, či je VPN aktívna

Stav služby je fakt riadiacej roviny. macOS vie, že konfigurácia je pripojená, pretože to povedal jej klientsky proces. Trasa je fakt dátovej roviny: jadro pošle tento cieľ cez to rozhranie. Dostupnosť je fakt od konca ku koncu a môže zlyhať z dôvodov, ktoré ani jedna z ostatných dvoch nevidí.

Užitočná kontrola spája prvé dve a tretiu používa ako potvrdenie, že prvé dve neklamali. Každá sama o sebe je odhad s časovou pečiatkou.

Čítajte identifikátor, nie zobrazovaný názov

scutil --nc list
scutil --nc status "Office"

Zoznam vypíše jeden riadok na službu a každý riadok nesie stav v zátvorke, potom identifikátor služby, typ a zobrazovaný názov. Skript píšte podľa identifikátora, pretože zobrazovaný názov je to, čo niekto napísal do Nastavení systému, a môže sa zmeniť bez upozornenia. Príkaz stavu vypíše jedno slovo a pri niektorých typoch služieb za ním štatistiky; porovnávajte to prvé slovo namiesto hľadania názvu v celom výstupe, ktorý sa objavuje aj inde.

Spustenie služby môže vyvolať žiadosť o autorizáciu alebo byť priamo odmietnuté, keď je profil spravovaný. To odmietnutie nie je porucha tunela; je to vyhlásenie politiky o tom, kto ho smie zdvihnúť.

Klient tretej strany sa skrýva pred zoznamom

Prázdny zoznam neznamená, že VPN neexistuje. Konfigurácie vytvorené vo vlastných sieťových nastaveniach systému sa tu zobrazujú; klientske riešenie dodávateľa, profil správy alebo aplikácia tretej strany môžu držať aktívny tunel, ktorý tento príkaz nikdy nevidí. Vlastný nástroj je autoritou pre vlastnú službu. Pýtať sa scutil na klienta, ktorý sa v ňom nikdy nezaregistroval, vráti nič a nič nie je rovnaká odpoveď ako odpojené.

Keď je zoznam prázdny, ale prevádzka je zjavne šifrovaná, hľadajte rozhranie: zariadenie utun alebo ppp s adresou v očakávanom rozsahu je dôkaz, že niečo vytvorilo tunel. Je to slabší signál než stav služby, preto ho spárujte s kontrolou trasy namiesto toho, aby ste rozhranie považovali za dôkaz identity. Viac klientov môže vytvoriť viac takých rozhraní a len jedno z nich patrí tunelu, ktorý ste mysleli.

Stav nie je smerovanie

Pripojená služba hovorí, že tunel existuje. Nehovorí, že ho vaša destinácia používa. Prečítajte adresy a potom sa spýtajte jadra priamo:

ifconfig | grep -A4 utun
netstat -rn -f inet
route -n get 10.40.0.20

Klient plného tunela inštaluje predvolenú trasu cez tunel; klient rozdeleného tunela inštaluje konkrétne privátne prefixy. Obaja hlásia Connected a skript, ktorý kontroluje iba stav, veselo pôjde nesprávnou cestou. Zastavenie tunela nemusí odstrániť trasy, ktoré nainštaloval iný klient, a to je jeden zo spôsobov, ako má stroj súčasne pripojenú službu a zastaranú trasu. Pozerajte na destináciu, ktorá vás zaujíma, nie na celú tabuľku trás.

Pomenovanie je samostatný problém

Iné stroje sa k Macu nedostanú podľa mena, hoci jeho adresa funguje, a hlási sa to ako porucha VPN. Lokálne meno hostiteľa, meno hostiteľa a záznam DNS sú tri rôzne veci. scutil --get LocalHostName zobrazuje meno Bonjour; sudo scutil --set HostName mac-office nastavuje meno, ktoré hlási systém.

Žiadne z týchto nastavení nevytvára záznam v kancelárskej zóne. Ak iní hostitelia musia rozlíšiť meno cez DNS, vlastník zóny ho musí pridať, alebo má skript použiť adresu. Nastavenie stabilného mena robí oznámenia konzistentnými; neprinúti resolver odpovedať.

Zapíšte v skripte spolu identifikátor služby a očakávaný tvar trasy a pred kopírovaním skontrolujte oboje. Tunel, ktorý je aktívny, ale smerovaný nesprávnym smerom, zlyhá presne ako žiadny tunel, a riadok logu s Connected pošle ďalšieho človeka hľadať na nesprávnom mieste.