A Windows nyilvános tűzfalprofilja blokkolja a VPN-klienseket

A tunnel áll, az átjáró válaszol a pingre, a fájlmegosztás mégis időtúllépéssel zárul. Ez a kombináció ritkán útvonalválasztási probléma: a Windows a VPN-adapter alhálózatát a Nyilvános profilba tette, és minden engedélyező szabály, amely Privát vagy Tartomány profilra készült, soha nem érvényesült. Találkoztam ezzel olyan laptopokon, amelyek gond nélkül elérik az irodát, és olyan RRAS-kiszolgálókon, amelyek minden más klienst kiszolgálnak, és a javítás rövid, amint megnevezi az érintett profilt. Íme a sorrend, amelyben dolgozom, azzal az ellenőrzéssel, amely megmondja, mikor álljon meg a következő lépés előtt.

Derítse ki, melyik profilon érkezik valójában a forgalom

A Windows tűzfalnak nincs egyetlen globális módja. Minden csatlakoztatott interfész kategóriát hordoz, és a bejövő csomagok annak az interfésznek a kategóriája szerint szűrődnek, amelyen érkeznek, tehát a VPN-adapter profilja dönti el, mit érhet el egy alagútban lévő kliens, nem a mellette lévő Wi-Fi- vagy Ethernet-adapter. Olvassa el mindkét tényt, mielőtt bármit módosít:

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

Szokásos OpenVPN- vagy WireGuard-telepítésnél a VPN-adapter azonosítatlan hálózatként jelenik meg, és a Nyilvános profilba kerül, ami az alapértelmezés minden olyan hálózatnál, amelyet a Windows nem tud besorolni: nem válaszolt rajta tartományvezérlő, és nem illett egyetlen átjáróprofil sem. Az interfész neve itt nem számít, tehát attól, hogy „VPN”-nek vagy „Corp”-nak nevezi az adaptert, semmi sem változik. A DomainAuthenticated tartományhoz csatlakoztatott gépet igényel , amely ezen az interfészen ténylegesen eléri a tartományvezérlőt; az egyetlen alhálózatot vivő osztott alagút ezt nem teljesíti.

Ha a szükséges szabály már a VPN-poolra van szűkítve, és már arra a kategóriára érvényes, amelyet most olvasott, álljon meg itt: a szűrés nem az Ön rétege, és a következő hely, ahol keresnie kell, a szolgáltatás konfigurációja. Ez az ellenőrzés tíz másodpercet vesz igénybe, és egy óra szabályszerkesztést takarít meg. A kategórianevek és az, hogy melyik mit fed le, a Get-NetConnectionProfile referenciadokumentációjában.

Erősítse meg a szűrést, nem az útvonalválasztást, mielőtt szabályokat szerkeszt

A ping gyenge teszt. Az ICMP átmehet, miközben a szolgáltatás portja eldobódik, és egy gazdagép válaszolhat a LAN-ból, miközben ugyanazt a kérést az alagúton megtagadja. Tesztelje azt a portot, amelyre a kliensnek szüksége van, a kliensről:

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

Ha a portteszt sikertelen, válassza szét a két réteget. Az alagút- vagy útvonalhiba általában abban mutatkozik meg, hogy az átjáró címéről egyáltalán nem jön válasz, míg a tűzfal általi eldobás olyan átjárót mutat, amely válaszol, és olyan szolgáltatásportot, amely nem. Egy Windows-kiszolgálón, amely a poolt RRAS-on keresztül teszi közzé, futtassa ugyanezt a tesztet egy kliensről, és olvassa el magának a kiszolgálónak a profilját: a RAS-interfész olyan kategóriában lehet, amelynek bejövő szabályai soha nem említik a kliens tartományát, és ezért szolgálja ki a gép a saját LAN-ját, és utasít el minden alagútban lévő klienst.

Ha az eredmény továbbra is kétértelmű, naplózza az érintett profil eldobásait, és olvassa el őket:

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

A DROP-pal megnevezett klienscímet és portot tartalmazó bejegyzések döntőek, és megmondják azt is, melyik szabály hiányzott. Egy üres napló, miközben a kliens SYN-je soha nem jelenik meg, a gazdagép előtti szakaszra utal, ezért térjen vissza az alagúthoz, a NAT-szabályhoz vagy a pool útvonalához, mielőtt másik tűzfalobjektumhoz nyúl.

Szűkítsen egy bejövő szabályt az ügyfélpoolra

A javítás egyetlen bejövő engedélyező szabály, amelynek távoli címe a pool, nem az egész világ. Emelt szintű munkamenetből:

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

Ha a szolgáltatás egyetlen bináris, a portlista helyett részesítse előnyben a -Program kapcsolóval megadott programszűkített szabályt; ez a kivételt a folyamatra és a forrás tartományára is korlátozza.

A profilválasztás az a pont, ahol ugyanaz a hiba ellenkező irányban történik meg. -Profile Public elegendő, ha az adapter Nyilvános, és az is marad. -Profile Any védhető, ha a szolgáltatásnak működnie kell, függetlenül attól, hogyan sorolja be a Windows az adaptert, de csak amíg a távoli hatókör megmarad. Ami soha nem védhető, az a -RemoteAddress Any a Nyilvános profilban: az a szabály követi a laptopot minden kávézó- és hotelszobahálózatba, amelyhez csatlakozik, és megnyitja a portot mindenkinek, aki osztja azt az alhálózatot.

Jegyezze fel a poolt a szabály mellé. -RemoteAddress 10.8.0.0/24 csendben megszűnik egyezni azon a napon, amikor a VPN-poolt újraszámozzák, és a hiba pontosan úgy néz ki, mint az eredeti hiba, ezért kerül egy második délutánba. Nevezze el a szabályokat a szolgáltatás és a forrás tartománya szerint, tartsa őket együtt a -Group, és olvassa újra őket, amikor a pool definíciója megváltozik. Egy szabályleltár, amelyet egyetlen képernyőn át tud nézni, többet ér, mint egy helyes szabály, amelyet senki nem talál meg.

Csak akkor módosítsa a kategóriát, ha a kategória a döntés

Az interfész Privátra állítása is működik, és ez a rossz alapértelmezés. A Privát profil hosszú listát hordoz beépített engedélyező szabályokból, amelyek lefedik a fájl- és nyomtatómegosztást, a hálózatfelderítést, a távoli asztalt és a bázistól függően még többet, így a VPN-adapter újrabesorolása mindegyiket egyszerre engedélyezi minden alagútban lévő kliens számára. Egy szűkített szabály egy szolgáltatást ad egy tartománynak. Egy olyan laptopon, amely nem megbízható hálózatokhoz is csatlakozik, ez a különbség nem kozmetikai.

Vannak esetek, amikor a besorolás valóban hibás: egy mindig bekapcsolt vagy telephelyek közötti alagút, amely irodai alhálózatot visz, megbízható infrastruktúra, és ezt az adaptert Privátnak jelölni legitim tervezési döntés, amelyet egyszer, szabályzat alapján hoznak meg, nem jegyenként. Amikor megteszi, tegye kifejezetten:

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

Kezelt eszközön először ellenőrizze, hogy csoportházirend vagy MDM-bázis birtokolja-e a beállítást. Ha igen, a helyi módosítás visszavonódik a következő frissítéskor, és a gpresult /h megnevezi a szabályzatot, amely birtokolja; ott javítsa, ne a végponton.

Ellenőrizze mindkét végpontról, és hagyjon nyomot

Ellenőrizze a felhasználó által jelentett folyamatot a kliensről, a módosítás után:

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

Utána zárja le a kört azokkal a dolgokkal, amelyek jövő héten elromlanak. Indítsa újra a gazdagépet, és teszteljen újra, mert a rossz profilra szűkített szabály addig működik, amíg az adapter vissza nem tér egy másik kategóriában. Teszteljen egy második kliensről, mert egy elavult lease-szel rendelkező kliens elrejtheti a pool eltérését. Számolja össze a hozzáadott szabályokat az eltávolítottakkal, mert az átfedő kivételek azok, amelyek révén egy két soros javításból olyan szűrési szabályzat lesz, amelyet senki nem tud átnézni.

Mielőtt késznek nyilvánítja:

• A szabályban megnevezett profil azon interfész profilja, amelyen a forgalom érkezik.
• A távoli hatókör a VPN-pool, és ez a pool megfelel annak, amit a kiszolgáló ténylegesen kioszt.
• A hozzáadott szabályok egyike sem használ -RemoteAddress Any a Nyilvános profilban.
• Semmit nem tiltott le, hogy a teszt átmenjen, és minden kategóriamódosítás rögzíti, ki hagyta jóvá.