VPN-status på macOS från terminalen: scutil, rutter eller ping
Tjänstens tillstånd, kerneln rutt och en verklig förfrågan svarar på tre olika frågor. Skriv skriptet mot tjänstens identifierare och kontrollera rutten också.
Någonstans i ett distributionsskript finns en kontroll om tunneln är uppe innan en kopiering börjar. Tre svar finns tillgängliga och de betyder inte samma sak: tjänstens tillstånd som scutil rapporterar, rutten som kerneln valde och om den andra änden faktiskt svarar. Att jämföra dem är skillnaden mellan en kontroll som förutsäger kopieringen och en som bara dekorerar loggen.
Tre svar på frågan om VPN är uppe
Tjänstens tillstånd är ett faktum i kontrollplanet. macOS vet att en konfiguration är ansluten eftersom dess klientprocess sade det. Rutten är ett faktum i dataplanet: kerneln skickar denna destination genom det gränssnittet. Nåbarhet är ett faktum från ände till ände, och det kan misslyckas av skäl som ingen av de andra två 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 |
En användbar kontroll kombinerar de två första och använder den tredje som bekräftelse på att de två andra inte ljög. Var och en för sig är en gissning med tidsstämpel.
Läs identifieraren, inte visningsnamnet
scutil --nc list
scutil --nc status "Office"Listningen skriver ut en rad per tjänst, och varje rad har en status inom parentes, följt av tjänstens identifierare, typen och visningsnamnet. Skriv skriptet mot identifieraren, eftersom visningsnamnet är det någon skrev i Systeminställningar och kan ändras utan varsel. Statuskommandot skriver ut ett enda ord, och för vissa tjänstetyper statistik efter det; jämför det första ordet i stället för att söka efter namnet i hela utdata, som också förekommer på andra ställen.
Att starta en tjänst kan utlösa en behörighetsförfrågan eller avvisas direkt när profilen är hanterad. Det avslaget är inte ett fel i tunneln; det är ett policyuttalande om vem som får lyfta den.
En tredjepartsklient gömmer sig från listan
En tom lista betyder inte att det inte finns någon VPN. Konfigurationer som skapats i systemets egna nätverksinställningar visas här; en leverantörsklient, en hanteringsprofil eller en tredjepartsapp kan hålla en aktiv tunnel som kommandot aldrig ser. Det egna verktyget är auktoriteten för den egna tjänsten. Att fråga scutil om en klient som aldrig registrerade sig hos den ger ingenting, och ingenting är inte samma svar som frånkopplad.
När listan är tom men trafiken uppenbart är krypterad, leta efter gränssnittet: en utun- eller ppp-enhet med adress i det förväntade intervallet är bevis på att något har etablerat en tunnel. Det är en svagare signal än tjänstens tillstånd, så kombinera den med en ruttkontroll i stället för att behandla gränssnittet som identitetsbevis. Flera klienter kan skapa flera sådana gränssnitt, och bara ett av dem tillhör tunneln du menade.
Status är inte routing
En ansluten tjänst säger att tunneln finns. Den säger inte att din destination använder den. Läs adresserna och fråga sedan kerneln direkt:
ifconfig | grep -A4 utun
netstat -rn -f inet
route -n get 10.40.0.20En klient med full tunnel installerar en standardrutt genom tunneln; en klient med delad tunnel installerar specifika privata prefix. Båda rapporterar Connected, och ett skript som bara kontrollerar status kommer glatt att köra över fel väg. Att stoppa en tunnel tar inte nödvändigtvis bort rutter som en annan klient installerade, och det är ett sätt för en maskin att samtidigt ha en ansluten tjänst och en inaktuell rutt. Titta på destinationen du bryr dig om, inte på hela rutttabellen.
Namngivning är ett separat problem
Andra maskiner når inte Macen vid namn medan adressen fungerar, och det rapporteras som ett VPN-fel. Det lokala värdnamnet, värdnamnet och DNS-posten är tre olika saker. scutil --get LocalHostName visar Bonjour-namnet; sudo scutil --set HostName mac-office ställer in namnet som systemet rapporterar.
Ingen av inställningarna skapar en post i kontorszonen. Om andra värdar måste slå upp namnet via DNS måste zonägaren lägga till det, eller så bör skriptet använda adressen i stället. Ett stabilt namn gör annonseringarna konsekventa; det får inte resolvern att svara.
Anteckna tjänstens identifierare och ruttens förväntade form tillsammans i skriptet, och kontrollera båda före kopieringen. En tunnel som är uppe men routad fel väg misslyckas precis som ingen tunnel, och loggrader som säger Connected skickar nästa person att leta på fel ställe.