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

Někde v nasazovacím skriptu je kontrola, zda je tunel aktivní, než začne kopírování. K dispozici jsou tři odpovědi a neznamenají totéž: stav služby, který hlásí scutil, trasa, kterou zvolilo jádro, a zda protistrana skutečně odpovídá. Jejich porovnání je rozdíl mezi kontrolou, která kopírování předpoví, a kontrolou, která jen zdobí log.

Tři odpovědi na otázku, zda VPN běží

Stav služby je fakt řídicí roviny. macOS ví, že konfigurace je připojená, protože to řekl její klientský proces. Trasa je fakt datové roviny: jádro pošle tento cíl přes ono rozhraní. Dostupnost je fakt od konce ke konci a může selhat z důvodů, které žádná z ostatních dvou nevidí.

Užitečná kontrola spojuje první dvě a třetí používá jako potvrzení, že obě ostatní nelhaly. Jakákoli jedna sama je odhad s časovým razítkem.

Čtěte identifikátor, ne zobrazované jméno

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

Výpis tiskne jeden řádek na službu a každý řádek nese stav v závorce, za nímž následuje identifikátor služby, typ a zobrazované jméno. Pište skript proti identifikátoru, protože zobrazované jméno je to, co někdo napsal do Nastavení systému, a může se změnit bez upozornění. Příkaz stavu tiskne jedno slovo a za ním u některých typů služeb statistiky; porovnávejte to první slovo, místo abyste jméno hledali v celém výstupu, kde se objevuje i jinde.

Spuštění služby může vyvolat výzvu k autorizaci, nebo být zcela odmítnuto, když je profil spravovaný. Takové odmítnutí není závada tunelu; je to prohlášení o politice, kdo ho smí zvednout.

Klient třetí strany se před výpisem skrývá

Prázdný seznam neznamená, že VPN není. Objevují se zde konfigurace vytvořené v síťovém nastavení samotného systému; klientský software dodavatele, profil správy nebo aplikace třetí strany mohou držet aktivní tunel, který tento příkaz nikdy neuvidí. Jeho vlastní nástroj je autoritou pro jeho vlastní službu. Zeptat se scutil na klienta, který se u něj nikdy nezaregistroval, nic nevrátí, a nic není stejná odpověď jako odpojeno.

Když je seznam prázdný, ale provoz je zjevně šifrovaný, hledejte místo toho rozhraní: zařízení utun nebo ppp s adresou v očekávaném rozsahu je důkaz, že něco tunel vytvořilo. Je to slabší signál než stav služby, takže ho spojte s kontrolou trasy, místo abyste rozhraní považovali za důkaz totožnosti. Několik klientů může vytvořit několik takových rozhraní a jen jedno z nich patří tunelu, který jste mysleli.

Stav není směrování

Připojená služba říká, že tunel existuje. Neříká, že váš cíl přes něj jde. Přečtěte adresy a pak se zeptejte jádra přímo:

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

Klient plného tunelu instaluje výchozí trasu přes tunel; klient rozděleného tunelu instaluje konkrétní privátní prefixy. Oba hlásí Connected a skript, který kontroluje jen stav, ochotně poběží po špatné cestě. Zastavení tunelu nutně neodstraní trasy, které nainstaloval jiný klient, a to je jeden ze způsobů, jak stroj skončí zároveň s připojenou službou a zastaralou trasou. Dívejte se na cíl, který je pro vás důležitý, ne na celou směrovací tabulku.

Názvy jsou samostatný problém

Ostatní stroje nedosáhnou Mac podle jména, zatímco jeho adresa funguje, a to se hlásí jako závada VPN. Lokální jméno hostitele, jméno hostitele a záznam DNS jsou tři různé věci. scutil --get LocalHostName ukazuje jméno Bonjour; sudo scutil --set HostName mac-office nastavuje jméno, které systém hlásí.

Ani jedno nastavení nevytváří záznam v zóně kanceláře. Pokud mají ostatní hostitelé jméno řešit přes DNS, musí ho vlastník zóny přidat, nebo má skript použít raději adresu. Nastavení stabilního jména sjednocuje oznámení; nezpůsobí, že resolver odpoví.

Zapište identifikátor služby a očekávaný tvar trasy společně do skriptu a před kopírováním zkontrolujte obojí. Tunel, který je aktivní a směrovaný špatně, selže stejně jako žádný tunel, a řádek logu s Connected pošle příštího člověka hledat na špatné místo.