VPN-klienter blockerade av Windows offentliga brandväggsprofil

Windows klassar VPN-adaptern som Offentlig, så dina LAN-regler gäller aldrig. Kontrollera profilen, begränsa en inkommande regel till poolen och verifiera sedan porten.

Din tunnel är uppe, gatewayen svarar på ping och filresursen får fortfarande timeout. Den kombinationen är sällan ett routingproblem: Windows har lagt VPN-adapterns subnät i profilen Offentlig, och varje tillåtelseregel som skrevs för Privat eller Domän tillämpades aldrig. Jag har stött på det på bärbara datorer som når kontoret utan problem och på RRAS-servrar som betjänar alla andra klienter, och reparationen är kort så snart du namnger profilen som är inblandad. Här är den ordning jag arbetar i, med kontrollen som säger till dig att stanna före nästa steg.

Ta reda på vilken profil trafiken faktiskt anländer på

Windows-brandväggen har inget enda globalt läge. Varje anslutet gränssnitt bär en kategori, och inkommande paket filtreras mot kategorin för det gränssnitt de anländer på, så det är VPN-adapterns profil som avgör vad en klient i tunneln kan nå, inte Wi-Fi- eller Ethernet-adaptern bredvid. Läs båda fakta innan du ändrar något:

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction

Vid en standardinstallation av OpenVPN eller WireGuard visas VPN-adaptern som ett oidentifierat nätverk och hamnar i Offentlig, vilket är standard för alla nätverk som Windows inte kan klassificera: ingen domänkontrollant svarade över det och ingen gatewayprofil matchade. Gränssnittets namn är irrelevant här, så att kalla adaptern ”VPN” eller ”Corp” ändrar ingenting. DomainAuthenticated kräver en dator som är ansluten till domänen , som faktiskt kan nå en domänkontrollant över det gränssnittet; en delad tunnel som bara bär ett subnät uppfyller inte kravet.

Om regeln du behöver redan är begränsad till VPN-poolen och redan gäller för kategorin du just läste, stanna här: filtrering är inte ditt lager, och nästa ställe att titta på är tjänstekonfigurationen. Den kontrollen tar tio sekunder och sparar en timme av regelredigering. Kategorinamnen och vad varje kategori täcker finns dokumenterade i referensen för Get-NetConnectionProfile.

Bekräfta filtrering, inte routing, innan du redigerar regler

Ping är ett svagt test. ICMP kan passera medan tjänstens port släpps, och en värd kan svara från LAN:et medan den avvisar samma begäran över tunneln. Testa porten som klienten behöver, från klienten:

Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed

Om porttestet misslyckas, separera de två lagren. Ett tunnel- eller rutefel visar sig vanligtvis som inget svar alls från gatewayadressen, medan ett brandväggsavslag visar en gateway som svarar och en tjänstport som inte gör det. På en Windows-server som publicerar poolen via RRAS, kör samma test från en klient och läs serverns egen profil: RAS-gränssnittet kan sitta i en kategori vars inkommande regler aldrig nämner klientintervallet, vilket är varför maskinen betjänar sitt LAN och nekar varje klient i tunneln.

När resultatet fortfarande är tvetydigt, logga avslagen för profilen som är inblandad och läs dem:

Set-NetFirewallProfile -Name Public -LogBlocked True `
  -LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"

Poster som namnger klientadressen och porten med DROP är avgörande, och de talar också om vilken regel som saknades. En logg utan något i, medan klientens SYN aldrig dyker upp, pekar uppströms från värden, så gå tillbaka till tunneln, NAT-regeln eller poolrutten innan du rör ett annat brandväggsobjekt.

Begränsa en inkommande regel till klientpoolen

Reparationen är en enda inkommande tillåtelseregel vars fjärradress är poolen, inte hela världen. Från en förhöjd session:

New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
  -RemoteAddress 10.8.0.0/24 -Profile Public

När tjänsten är en enda binärfil, föredra en programbegränsad regel med -Program framför en portlista; det begränsar undantaget både till processen och till källintervallet.

Profilvalet är där samma misstag görs i den andra riktningen. -Profile Public räcker när adaptern är Offentlig och förblir Offentlig. -Profile Any är försvarbart när tjänsten måste fungera oavsett hur Windows klassar adaptern, men bara så länge fjärromfånget finns kvar. Det som aldrig är försvarbart är -RemoteAddress Any på profilen Offentlig: den regeln följer den bärbara datorn in i varje kafé- och hotellnätverk den ansluter till och öppnar porten för vem som helst som delar det subnätet.

Anteckna poolen bredvid regeln. -RemoteAddress 10.8.0.0/24 slutar tyst matcha den dag VPN-poolen numreras om, och felet ser exakt ut som den ursprungliga buggen, vilket är varför det kostar en andra eftermiddag. Namnge regler efter tjänsten och källintervallet, håll dem tillsammans med -Group, och läs dem igen när poolens definition ändras. En regelinventering du kan granska på en enda skärm slår en korrekt regel som ingen kan hitta.

Ändra kategorin bara när kategorin är beslutet

Att växla gränssnittet till Privat fungerar också, och det är fel standard. Profilen Privat innehåller en lång lista inbyggda tillåtelseregler som täcker fil- och skrivardelning, nätverksidentifiering, fjärrskrivbord och mer beroende på baslinjen, så att omklassificera VPN-adaptern aktiverar dem alla för varje klient i tunneln på en gång. En begränsad regel ger en tjänst till ett intervall. På en bärbar dator som också ansluter till icke betrodda nätverk är den skillnaden inte kosmetisk.

Det finns fall där klassningen verkligen är fel: en alltid på eller site-to-site-tunnel som bär ett kontorssubnät är betrodd infrastruktur, och att markera den adaptern som Privat är ett legitimt designval, gjort en gång per policy och inte per ärende. När du gör det, gör det uttryckligen:

Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory Private

Kontrollera först på en hanterad enhet om en grupprincip eller en MDM-baslinje äger inställningen. Om den gör det ångras den lokala ändringen vid nästa uppdatering och gpresult /h namnger principen som äger den; rätta det där och inte på slutpunkten.

Verifiera från båda ändarna och lämna ett spår

Verifiera det flöde användaren rapporterade, från klienten, efter ändringen:

Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort

Slut sedan loopen kring det som går sönder nästa vecka. Starta om värden och testa igen, eftersom en regel som är begränsad till fel profil fortsätter att fungera tills adaptern kommer tillbaka i en annan kategori. Testa från en andra klient, eftersom en klient med ett gammalt lease kan dölja en poolavvikelse. Räkna de regler du lade till mot dem du tog bort, eftersom överlappande undantag är hur en rättelse på två rader blir en filtreringspolicy som ingen kan granska.

Innan du kallar det klart:

  • Profilen som namnges i regeln är profilen på det gränssnitt trafiken anländer på.
  • Fjärromfånget är VPN-poolen, och den poolen matchar det servern faktiskt delar ut.
  • Ingen regel du lade till använder -RemoteAddress Any på profilen Offentlig.
  • Ingenting inaktiverades för att testet skulle passera, och varje kategoriändring registrerar vem som godkände den.

Relaterade artiklar