Ukjent nettverk på ein Windows VPN-adapter: kva det tyder

Windows viser Ukjent nettverk for alle grensesnitt det ikkje kan klassifisere til ein plassering, og ein VPN-adapter er ein vanleg kandidat fordi han ofte ikkje har sin eigen standardgateway. Etiketten er ein brannmurkategori, ikkje ei utsegn om tunnelen er autentisert eller om programmet ditt når noko. Å handsame han som ei feilmelding er korleis folk endar med å tilbakestille ein adapter som fungerer og miste økta som var i orden. To kommandoar fortel om etiketten fortener noko merksemd i det heile.

Etiketten er ein brannmurkategori, ikkje ei statuslampe

Registrering av nettverksplassering avgjer om eit grensesnitt høyrer til eit domene, eit privat eller eit offentleg nettverk, og brannmuren brukar deretter regelsettet for den kategorien. Ukjent er resultatet når klassifiseringa mislukkast, noko som vanlegvis plasserer grensesnittet i den offentlege profilen. Den offentlege profilen er den som som standard blokkerer mesteparten av innkommande trafikk.

Offentleg er den restriktive profilen, så det praktiske spørsmålet er om tenesta di er tillaten der. Ein tunnel kan vere heilt sunn og likevel vise etiketten, fordi klassifiseringa avheng av forma på grensesnittet, ikkje av tilstanden til sambandet.

Den skilnaden forklarer dei mest forvirrande rapportane: ei fildeling som virka i går og ikkje i dag, på ein adapter ingen har endra, fordi ei regel var avgrensa til den private profilen og grensesnittet no er i offentleg.

Les tre ting før du endrar noko

Kontroller kategorien, adressekonfigurasjonen og ruta til målet, i den rekkjefølgja. Viss ressursen virkar, er etiketten kosmetisk for føremåla dine, og det ærlege svaret er å la han vere.

Desse kommandoane skriv ut gjeldande profil, grensesnittoversikta og konfigurasjonen for éin adapter:

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

Grensesnittindeksen har noko å seie fordi profil-cmdletane adresserer grensesnitt etter indeks, og ein berbar PC med ein fysisk adapter, ein Wi-Fi-adapter og ein tunnel har tre. Å lese feil gir ein sjølvsikker diagnose av eit nettverk ingen brukar.

Kvifor adapteren i det heile ser ukjend ut

Klassifiseringa leitar etter prov på at grensesnittet høyrer til ein stad: ein domenekontrollar han kan nå, ein gateway som oppfører seg som eit heimenettverk, eller ein identitet som kan slåast opp. Eit tunnegrensesnitt har ofte ingen gatewayoppføring og ingen kringkastingsdomene, så probane har ingenting å arbeide med.

Fulltunnelklientar unngår stundom etiketten ved å tildele ein gateway eller ved å bere ei rute som ein klassifiseringsprobe kan følgje. Splittunnelklientar viser han oftare, fordi tunnelen berre ber prefiksa han vart konfigurert for, og resten av trafikken går ut andre stader.

Ingenting av dette er ein feil. Det er klassifiseringsmotoren som skildrar eit grensesnitt som ikkje ser ut som eit LAN, og det er nettopp det ein tunnel er.

Der etiketten byrjar å bety noko, er i policy. Eit administrasjonsverktøy, ein endepunktagent eller ei brannmurregel som vel etter profil, vil handsame det ukjende grensesnittet som offentleg, og blokkeringa som følgjer er reell sjølv om årsaka er ein etikett.

Å endre kategorien har konsekvensar

Å merke grensesnittet som privat er ei tillitsavgjerd, og ho brukar det private regelsettet på trafikk som kjem inn på den adapteren. Viss tunnelen endar hos ein leverandør du ikkje kontrollerer, eller viss eininga kan bli med i utillatelege nettverk, utvidar den endringa kva som er tilgjengeleg frå det grensesnittet. Ho gjer også eininga oppdagbar på eit nettverkssegment du kanskje ikkje eig. Det er mange konsekvensar for ein kosmetisk etikett.

Eit breitt skript som set kvart ukjent grensesnitt til privat er verre, fordi det brukar same tillit på adapterar du aldri har inspisert. På ei administrert eining kan endringa også bli overstyrt av policy ved neste oppdatering, og du sit att med ei løysing som virkar til ho ikkje gjer det.

Reparer flyten som feilar, ikkje namnet

Start med ein konkret feil: ei deling som ikkje opnar, ein nettstad som ikkje lastar, ein skrivar som ikkje blir funnen. Del deretter årsakene — namneoppslag, ruteval, brannmurdekning og brukartillating feilar på ulike måtar og gir ulike meldingar.

Viss feilen er eit namn, test oppslaget spesifikt frå den adapteren i staden for frå maskinen generelt. Viss det er ei rute, skriv ut den valde ruta for den nøyaktige destinasjonen. Viss det er brannmuren, les profilen som gjeld og regelen som skal tillate trafikken, og avgjer deretter om ei smal regel for programmet er betre enn ei kategorirangering.

Først etter at desse tre er utelukka, blir kategorien den sannsynlege årsaka, og sjølv då bør reparasjonen vere den minste som får den nødvendige flyten til å virke. Eit meir kjent nettverksnamn er ikkje målet; ei fungerande deling under ein godkjend regel er det.