Okänt nätverk på en Windows VPN-adapter: vad det betyder

Windows visar Okänt nätverk för alla gränssnitt det inte kan klassificera till en plats, och en VPN-adapter är en vanlig kandidat eftersom den ofta saknar egen standardgateway. Etiketten är en brandväggskategori, inte ett påstående om huruvida tunneln autentiserades eller om din applikation når något. Att behandla den som ett felmeddelande är hur folk hamnar i att återställa en adapter som fungerar och förlora sessionen som var i ordning. Två kommandon avgör om etiketten förtjänar någon uppmärksamhet alls.

Etiketten är en brandväggskategori, inte en statuslampa

Nätverksplatsigenkänning avgör om ett gränssnitt hör till en domän, ett privat eller ett offentligt nätverk, och brandväggen tillämpar sedan regeluppsättningen för den kategorin. Okänt är resultatet när klassificeringen misslyckas, vilket vanligtvis placerar gränssnittet i den offentliga profilen. Den offentliga profilen är den som som standard blockerar det mesta av inkommande trafik.

Offentlig är den restriktiva profilen, så den praktiska frågan är om din tjänst är tillåten där. En tunnel kan vara helt frisk och ändå visa etiketten, eftersom klassificeringen beror på gränssnittets form, inte på anslutningens tillstånd.

Den skillnaden förklarar de mest förvirrande rapporterna: en filshare som fungerade i går och inte i dag, på en adapter som ingen har ändrat, eftersom en regel var begränsad till den privata profilen och gränssnittet nu är i offentlig.

Läs tre saker innan du ändrar något

Kontrollera kategorin, adresskonfigurationen och rutten till målet, i den ordningen. Om resursen fungerar är etiketten kosmetisk för dina syften, och det ärliga svaret är att låta den vara.

De här kommandona skriver ut aktuell profil, gränssnittsöversikten och konfigurationen för en adapter:

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

Gränssnittsindexet spelar roll eftersom profil-cmdletarna adresserar gränssnitt via index, och en bärbar dator med en fysisk adapter, en Wi-Fi-adapter och en tunnel har tre. Att läsa fel ger en självsäker diagnos av ett nätverk som ingen använder.

Varför adaptern alls ser okänd ut

Klassificeringen letar efter bevis på att gränssnittet hör hemma någonstans: en domänkontrollant den kan nå, en gateway som beter sig som ett hemmanätverk eller en identitet som går att slå upp. Ett tunnelgränssnitt har ofta ingen gatewaypost och ingen broadcastdomän, så sonderna har inget att arbeta med.

Klienter med full tunnel undviker ibland etiketten genom att tilldela en gateway eller bära en rutt som en klassificeringssond kan följa. Klienter med delad tunnel visar den oftare, eftersom tunneln bara bär de prefix den konfigurerades för och resten av trafiken går ut någon annanstans.

Inget av detta är en defekt. Det är klassificeringsmotorn som beskriver ett gränssnitt som inte ser ut som ett LAN, och det är precis vad en tunnel är.

Där etiketten börjar spela roll är i policy. Ett administrationsverktyg, en slutpunktsagent eller en brandväggsregel som väljer efter profil kommer att behandla det okända gränssnittet som offentligt, och blockeringen som följer är verklig även om orsaken är en etikett.

Att ändra kategorin har konsekvenser

Att markera gränssnittet som privat är ett förtroendebeslut, och det tillämpar den privata regeluppsättningen på trafik som anländer på den adaptern. Om tunneln slutar hos en leverantör du inte kontrollerar, eller om enheten kan ansluta till ej betrodda nätverk, vidgar ändringen vad som är nåbart från det gränssnittet. Den gör också enheten upptäckbar i ett nätverkssegment som du kanske inte äger. Det är mycket konsekvens för en kosmetisk etikett.

Ett brett skript som sätter varje okänt gränssnitt till privat är värre, eftersom det tillämpar samma förtroende på adaptrar du aldrig har granskat. På en hanterad enhet kan ändringen också skrivas över av policy vid nästa uppdatering, och du står kvar med en lösning som fungerar tills den inte gör det.

Reparera flödet som felar, inte namnet

Börja med ett konkret fel: en share som inte öppnas, en sida som inte laddas, en skrivare som inte hittas. Dela sedan upp orsakerna — namnmatchning, ruttval, brandväggens omfattning och användarbehörighet felar på olika sätt och ger olika meddelanden.

Om felet är ett namn, testa uppslagningen specifikt från den adaptern i stället för från maskinen generellt. Om det är en rutt, skriv ut den valda rutten för den exakta destinationen. Om det är brandväggen, läs den gällande profilen och regeln som ska tillåta trafiken, och avgör sedan om en smal regel för programmet är bättre än en kategoriförändring.

Först efter att dessa tre uteslutits blir kategorin den sannolika orsaken, och även då bör reparationen vara den minsta som får det nödvändiga flödet att fungera. Ett mer bekant nätverksnamn är inte målet; en fungerande share under en godkänd regel är det.