Ukjent nettverk på en Windows VPN-adapter: hva det betyr

Windows viser Ukjent nettverk for alle grensesnitt det ikke kan klassifisere til en plassering, og en VPN-adapter er en vanlig kandidat fordi den ofte ikke har sin egen standardgateway. Etiketten er en brannmurkategori, ikke en uttalelse om hvorvidt tunnelen er autentisert eller om applikasjonen din når noe. Å behandle den som en feilmelding er hvordan folk ender med å tilbakestille en adapter som virker og miste økten som var i orden. To kommandoer forteller om etiketten fortjener noen oppmerksomhet i det hele tatt.

Etiketten er en brannmurkategori, ikke en statuslampe

Registrering av nettverksplassering avgjør om et grensesnitt hører til et domene, et privat eller et offentlig nettverk, og brannmuren bruker deretter regelsettet for den kategorien. Ukjent er resultatet når klassifiseringen mislykkes, noe som vanligvis plasserer grensesnittet i den offentlige profilen. Den offentlige profilen er den som som standard blokkerer mesteparten av innkommende trafikk.

Offentlig er den restriktive profilen, så det praktiske spørsmålet er om tjenesten din er tillatt der. En tunnel kan være helt sunn og likevel vise etiketten, fordi klassifiseringen avhenger av grensesnittets form, ikke av forbindelsens tilstand.

Den forskjellen forklarer de mest forvirrende rapportene: en fildeling som virket i går og ikke i dag, på en adapter ingen har endret, fordi en regel var begrenset til den private profilen og grensesnittet nå er i offentlig.

Les tre ting før du endrer noe

Kontroller kategorien, adressekonfigurasjonen og ruten til målet, i den rekkefølgen. Hvis ressursen virker, er etiketten kosmetisk for dine formål, og det ærlige svaret er å la den være.

Disse kommandoene skriver ut gjeldende profil, grensesnittoversikten og konfigurasjonen for én adapter:

Get-NetConnectionProfile
Get-NetAdapter | Format-Table Name,InterfaceIndex,Status
Get-NetIPConfiguration -InterfaceAlias "My VPN Adapter"

Grensesnittindeksen betyr noe fordi profil-cmdletene adresserer grensesnitt etter indeks, og en bærbar PC med en fysisk adapter, en Wi-Fi-adapter og en tunnel har tre. Å lese feil gir en selvsikker diagnose av et nettverk ingen bruker.

Hvorfor adapteren i det hele tatt ser ukjent ut

Klassifiseringen leter etter bevis for at grensesnittet hører til et sted: en domenekontroller den kan nå, en gateway som oppfører seg som et hjemmenettverk, eller en identitet som kan slås opp. Et tunnegrensesnitt har ofte ingen gatewayoppføring og ingen kringkastingsdomene, så probene har ingenting å arbeide med.

Fulltunnelklienter unngår noen ganger etiketten ved å tildele en gateway eller ved å bære en rute som en klassifiseringsprobe kan følge. Splittunnelklienter viser den oftere, fordi tunnelen bare bærer prefiksene den ble konfigurert for, og resten av trafikken går ut andre steder.

Ingenting av dette er en feil. Det er klassifiseringsmotoren som beskriver et grensesnitt som ikke ser ut som et LAN, og det er nettopp det en tunnel er.

Der etiketten begynner å bety noe, er i policy. Et administrasjonsverktøy, en endepunktagent eller en brannmurregel som velger etter profil, vil behandle det ukjente grensesnittet som offentlig, og blokkeringen som følger er reell selv om årsaken er en etikett.

Å endre kategorien har konsekvenser

Å merke grensesnittet som privat er en tillitsbeslutning, og den bruker det private regelsettet på trafikk som ankommer den adapteren. Hvis tunnelen ender hos en leverandør du ikke kontrollerer, eller hvis enheten kan bli med i utillatelige nettverk, utvider den endringen hva som er tilgjengelig fra det grensesnittet. Den gjør også enheten oppdagbar på et nettverkssegment du kanskje ikke eier. Det er mange konsekvenser for en kosmetisk etikett.

Et bredt skript som setter hvert ukjent grensesnitt til privat er verre, fordi det bruker samme tillit på adaptere du aldri har inspisert. På en administrert enhet kan endringen også bli overskrevet av policy ved neste oppdatering, og du sitter igjen med en løsning som virker til den ikke gjør det.

Reparer flyten som feiler, ikke navnet

Start med en konkret feil: en deling som ikke åpnes, et nettsted som ikke lastes, en skriver som ikke blir funnet. Del deretter årsakene — navneoppslag, rutevalg, brannmurdekning og brukertillatelse feiler på forskjellige måter og gir forskjellige meldinger.

Hvis feilen er et navn, test oppslaget spesifikt fra den adapteren i stedet for fra maskinen generelt. Hvis det er en rute, skriv ut den valgte ruten for den nøyaktige destinasjonen. Hvis det er brannmuren, les profilen som gjelder og regelen som skal tillate trafikken, og avgjør deretter om en smal regel for programmet er bedre enn en kategoripåendring.

Først etter at disse tre er utelukket, blir kategorien den sannsynlige årsaken, og selv da bør reparasjonen være den minste som får den nødvendige flyten til å virke. Et mer kjent nettverksnavn er ikke målet; en fungerende deling under en godkjent regel er det.