Mac VPN On Demand: hvad beviser en SSID-overensstemmelse egentlig?

At forbinde VPN overalt undtagen på kontorets Wi-Fi lyder som en politik på to linjer, og den svære del har aldrig været at genkende et netværksnavn. Den svære del er at afgøre, hvad et matchende navn må bevise. Et hvilket som helst adgangspunkt kan udsende en velkendt SSID, og en vellykket ping til én adresse beviser kun, at én enkelt forespørgsel fik et svar. Ingen af de to observationer fastslår, at Mac’en er på et godkendt internt netværk.

Et navn er ikke en identitet

En SSID er en etiket, som en radio udsender. Det er ikke en nøgle, et certifikat eller en erklæring om, hvem der ejer hardwaren, og et spillested eller et nabokontor kan udsende den samme streng uden nogen koordinering. At behandle etiketten som en instruks om at slå beskyttelsen fra overlader beslutningen til den, der har konfigureret det nærmeste adgangspunkt.

Ping-testen fejler af en mere subtil grund: den besvarer et spørgsmål om rækkevidde, ikke om medlemskab. Et mål, der svarer, kan være tilgængeligt fra hvor som helst, kan kun være tilgængeligt gennem den tunnel, du prøver at tage stilling til, eller kan være en captive portal, der returnerer noget, der ligner et svar. Rækkevidde er en nyttig kendsgerning og en dårlig tillidsgrænse.

Sådan vurderer On Demand et regelsæt

Apples On Demand-model parrer en handling med valgfrie netværksbetingelser, og reglerne vurderes i rækkefølge: den første regel, hvis betingelser alle matcher, leverer handlingen, og resten konsulteres ikke. Den rækkefølge er politikken, og derfor kan en regel, der tilføjes »for en sikkerheds skyld«, lydløst omskrive adfærd, der virkede.

SSID-betingelsen henviser til det aktuelt primære tilsluttede netværk, ikke til hvert navn, der er synligt i en scanning. Det giver tre forskellige tilstande, og at presse dem sammen til to er den sædvanlige konfigurationsfejl:

Konfigurer det, hvor politikken bor

En godkendt VPN-klient eller et administrationsworkflow er der, hvor denne regel hører til, og forskellige udbydere blotlægger forskellige delmængder af de tilgængelige kontroller. En manglende indstilling i det panel betyder derfor, at klienten ikke har vist den, ikke at platformen ikke kan udtrykke den.

Automatisk aktivering kræver også en godkendelsesordning, der kan gennemføres uden et menneske, for eksempel et certifikat eller en anden understøttet metode. En gemt engangskode er ikke den ordning, og en regel, der udløses, mens godkendelsen ikke kan gennemføres, giver et forbindelsesforsøg, der fejler stille i baggrunden.

To mønstre, der er værd at skrive i runbooken

Det første er det efterlignede navn. Et konferencecenter, et hotel eller en lejer i samme bygning udsender den streng, som din regel behandler som »indenfor«, og beskyttelsen slår fra præcis det sted, hvor du mindst ønsker det. Navnet løj ikke; reglen stillede det et spørgsmål, det ikke kan besvare.

Det andet er den selvmodsigende test. Et script pinger en privat adresse, ser et svar gennem tunnelen, konkluderer, at det allerede er på det interne netværk, og afbryder. Derefter fejler testen, så scriptet genopretter forbindelsen og gentager, og tunnelen svinger, mens hvert enkelt trin ser korrekt ud. En test, hvis resultat afhænger af tunnelen, kan ikke samtidig afgøre, om tunnelen bør findes.

Beslut standarden, og håndhæv den separat

Tilfældet med det ukendte netværk og tilfældet med kabel kræver udtrykkelige svar i stedet for en nedarvet standard. Hvis beskyttet trafik skal forblive blokeret, mens systemet stadig klassificerer netværket eller rejser tunnelen, kræver det sin egen understøttede håndhævelseskontrol; en On Demand-udløser giver forbindelsesadfærd, ikke en blokeringsgaranti.

Korrekt skrevet angiver administratorreglen den godkendte undtagelse, de beviser, der berettiger den, og det bevidste fald tilbage, når disse beviser mangler. At genkende et Wi-Fi-navn er et legitimt input til den beslutning. Det er ikke begrundelsen for beslutningen og bør aldrig være den eneste linje i reglen.