macOS VPN-status fra terminalen: scutil, ruter eller ping
Tjenestetilstand, kernens rute og en rigtig forespørgsel besvarer tre forskellige spørgsmål. Skriv scriptet mod tjenesteidentifikatoren, og kontroller også ruten.
Et sted i et deploy-script er der et tjek for, om tunnelen er oppe, før en kopiering starter. Der findes tre svar, og de betyder ikke det samme: den tjenestetilstand, scutil rapporterer, den rute kernen valgte, og om den anden ende faktisk svarer. At sammenligne dem er forskellen mellem et tjek, der forudsiger kopieringen, og et, der kun pynter på en log.
Tre svar på spørgsmålet om VPN er oppe
Tjenestetilstanden er et kontrolplansfaktum. macOS ved, at en konfiguration er forbundet, fordi dens klientproces har sagt det. Ruten er et dataplansfaktum: kernen sender denne destination gennem det interface. Rækkevidde er et end-to-end-faktum, og det kan fejle af årsager, som ingen af de to andre ser.
| Signal | Answers | Blind spot |
|---|---|---|
scutil --nc status | Is the service connected? | Third-party clients, wrong routes |
route -n get | Where would this go? | The peer may be down |
| A request to the far side | Does it work now? | Slow, and it changes state |
Et nyttigt tjek kombinerer de to første og bruger det tredje som bekræftelse på, at de to andre ikke løj. Hvert enkelt alene er et gæt med et tidsstempel.
Læs identifikatoren, ikke visningsnavnet
scutil --nc list
scutil --nc status "Office"Oplistningen udskriver én linje per tjeneste, og hver linje bærer en status i parentes efterfulgt af tjenesteidentifikatoren, typen og visningsnavnet. Skriv scriptet mod identifikatoren, fordi visningsnavnet er det, nogen har skrevet i Systemindstillinger, og det kan ændre sig uden varsel. Statuskommandoen udskriver et enkelt ord efterfulgt af statistik for nogle tjenestetyper; match det første ord i stedet for at søge efter navnet i hele outputtet, som også optræder andre steder.
Start af en tjeneste kan udløse en autorisationsanmodning eller blive afvist helt, når profilen administreres. Den afvisning er ikke en fejl i tunnelen; det er en politikudtalelse om, hvem der må rejse den.
En tredjepartsklient skjuler sig for listen
En tom liste betyder ikke, at der ikke er nogen VPN. Konfigurationer oprettet i systemets egne netværksindstillinger vises her; en leverandørklient, en administrationsprofil eller en tredjepartsapp kan holde en aktiv tunnel, som denne kommando aldrig ser. Dens eget værktøj er autoriteten for dens egen tjeneste. At spørge scutil om en klient, der aldrig har registreret sig hos den, giver intet, og intet er ikke det samme svar som afbrudt.
Når listen er tom, men trafikken tydeligt er krypteret, så se efter interfacet i stedet: en utun- eller ppp-enhed med en adresse i det forventede område er bevis på, at noget har oprettet en tunnel. Det er et svagere signal end en tjenestetilstand, så par det med et rutetjek i stedet for at behandle interfacet som bevis på identitet. Flere klienter kan oprette flere sådanne interfaces, og kun ét af dem hører til den tunnel, du mente.
Status er ikke routing
En forbundet tjeneste siger, at tunnelen findes. Den siger ikke, at din destination bruger den. Læs adresserne, og spørg så kernen direkte:
ifconfig | grep -A4 utun
netstat -rn -f inet
route -n get 10.40.0.20En full-tunnel-klient installerer en standardrute gennem tunnelen; en split-tunnel-klient installerer bestemte private præfikser. Begge rapporterer Connected, og et script, der kun tjekker status, kører glad ad den forkerte vej. At stoppe en tunnel fjerner ikke nødvendigvis ruter, som en anden klient har installeret, og det er en måde, hvorpå en maskine ender med en forbundet tjeneste og en forældet rute på samme tid. Se på den destination, du bekymrer dig om, ikke på hele rutetabellen.
Navngivning er et separat problem
Andre maskiner kan ikke nå Mac'en ved navn, mens dens adresse virker, og det rapporteres som en VPN-fejl. Det lokale værtsnavn, værtsnavnet og DNS-posten er tre forskellige ting. scutil --get LocalHostName viser Bonjour-navnet; sudo scutil --set HostName mac-office sætter det navn, systemet rapporterer.
Ingen af indstillingerne opretter en post i kontorzonen. Hvis andre værter skal slå navnet op via DNS, må zoneejeren tilføje det, eller scriptet bør bruge adressen i stedet. Et stabilt navn gør annonceringer konsistente; det får ikke resolveren til at svare.
Notér tjenesteidentifikatoren og den forventede ruteform sammen i scriptet, og kontroller begge før kopieringen. En tunnel, der er oppe og routet forkert, fejler præcis som ingen tunnel, og loglinjen, der siger Connected, sender den næste person til at lede det forkerte sted.