Mac VPN On Demand: hva beviser egentlig et SSID-treff?

Å koble til VPN overalt unntatt på kontorets Wi-Fi høres ut som en policy på to linjer, og den vanskelige delen har aldri vært å kjenne igjen et nettverksnavn. Den vanskelige delen er å avgjøre hva et samsvarende navn har lov til å bevise. Ethvert tilgangspunkt kan kringkaste en kjent SSID, og en vellykket ping til én adresse beviser bare at én enkelt forespørsel fikk svar. Ingen av de to observasjonene fastslår at Macen er på et autentisert internt nettverk.

Et navn er ikke en identitet

En SSID er en etikett som en radio sender ut. Det er ikke en nøkkel, et sertifikat eller en erklæring om hvem som eier maskinvaren, og et arrangementsted eller et nabokontor kan kringkaste den samme strengen uten noen som helst koordinering. Å behandle etiketten som en instruks om å slå av beskyttelsen overlater avgjørelsen til den som konfigurerte det nærmeste tilgangspunktet.

Ping-testen feiler av en mer subtil grunn: den svarer på et spørsmål om tilgjengelighet, ikke om medlemskap. Et mål som svarer kan være tilgjengelig fra hvor som helst, kan bare være tilgjengelig gjennom tunnelen du prøver å ta stilling til, eller kan være en captive portal som returnerer noe som ligner et svar. Tilgjengelighet er et nyttig faktum og en dårlig tillitsgrense.

Hvordan On Demand vurderer et regelsett

Apples On Demand-modell kobler en handling til valgfrie nettverksbetingelser, og reglene vurderes i rekkefølge: den første regelen der alle betingelsene stemmer gir handlingen, og resten blir ikke undersøkt. Den rekkefølgen er policyen, og derfor kan en regel som legges til «for sikkerhets skyld» stille skrive om atferd som fungerte.

SSID-betingelsen viser til det gjeldende primære tilkoblede nettverket, ikke til hvert navn som er synlig i en skanning. Det gir tre ulike tilstander, og å slå dem sammen til to er den vanlige konfigurasjonsfeilen:

Konfigurer det der policyen bor

En godkjent VPN-klient eller en administrasjonsarbeidsflyt er stedet denne regelen hører hjemme, og ulike leverandører eksponerer ulike delmengder av de tilgjengelige kontrollene. Et manglende alternativ i det panelet betyr derfor at klienten ikke eksponerte det, ikke at plattformen ikke kan uttrykke det.

Automatisk aktivering trenger også en autentiseringsordning som kan fullføres uten et menneske, for eksempel et sertifikat eller en annen støttet metode. En lagret engangskode er ikke den ordningen, og en regel som utløses mens autentiseringen ikke kan fullføres, gir et tilkoblingsforsøk som feiler stille i bakgrunnen.

To mønstre som er verdt å skrive i runbooken

Det første er det etterlignede navnet. Et konferansesenter, et hotell eller en leietaker i samme bygning kringkaster strengen regelen din behandler som «innenfor», og beskyttelsen slås av nøyaktig der du minst ville at den skulle det. Navnet løy ikke; regelen stilte det et spørsmål det ikke kan svare på.

Det andre er den selvbeseirende testen. Et skript pinger en privat adresse, ser et svar gjennom tunnelen, konkluderer med at det allerede er på det interne nettverket og kobler fra. Deretter feiler testen, så skriptet kobler til på nytt og gjentar, og tunnelen svinger mens hvert enkelt trinn ser riktig ut. En test der resultatet avhenger av tunnelen kan ikke samtidig avgjøre om tunnelen bør finnes.

Bestem standarden, og håndhev den separat

Tilfellet med ukjent nettverk og tilfellet med kabel trenger eksplisitte svar i stedet for en arvet standard. Hvis beskyttet trafikk må forbli blokkert mens systemet fortsatt klassifiserer nettverket eller reiser tunnelen, krever det sin egen støttede håndhevingskontroll; en On Demand-utløser gir tilkoblingsatferd, ikke en blokkeringsgaranti.

Riktig skrevet angir administratorregelen det godkjente unntaket, bevisene som rettferdiggjør det og den bevisste tilbakefallsløsningen når bevisene mangler. Å gjenkjenne et Wi-Fi-navn er en legitim inngang til den avgjørelsen. Det er ikke begrunnelsen for avgjørelsen, og det bør aldri være den eneste linjen i regelen.