Az irodai asztali gépek elérik a megosztást, a VPN-felhasználók időtúllépést kapnak, ugyanaz a fiók pedig mobil hotspotról működik. Ritkán a megosztási engedélyek a különbség; általában a fájlkiszolgálóhoz érkező cím az. A LocalSubnet bejegyzésre szűkített szabály a kiszolgáló saját csatlakoztatott alhálózatait engedi át, és egy külön irányított VPN-készlet nem tartozik közéjük. Két kialakítás zárja be a rést, és nagyon eltérő nyomokat hagy maga után.

Két kialakítás, egy tünet

Az első kialakítás hozzáadja a VPN-készletet a szabály távoli cím feltételéhez. A kiszolgáló ekkor minden kliens alagút-címét látja, így naplói meg tudják különböztetni az egyik távoli felhasználót a másiktól. A második kialakítás VPN-forgalmat irányít egy átjárón keresztül, amely LAN-címmé fordítja, mielőtt a kiszolgáló látná. Ez helyreállítja a kapcsolatot, és ugyanabban a lépésben megszünteti a megkülönböztetést.

A táblázat szerepeket ír le, nem címeket, és a saját előtagjai döntik el, melyik sor érvényes. Nyomtassa ki a kiszolgáló valódi értékeit, ahelyett hogy egy blogbejegyzés példáját másolná:

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLength

A táblázat döntési segédeszköz, nem állítás minden telepítésről. Az extra interfészekkel, második telephelyi kapcsolattal vagy más maszkkal rendelkező gazdagép helyi halmaza más.

Path the packet takesAddress the server recordsFilter scope that admits itWhat the log can still tell you
Desktop on the server LANIts own LAN addressLocalSubnet or the LAN prefixWhich workstation connected
Client on the routed VPN poolIts tunnel addressThe VPN pool as a remote addressWhich VPN account connected, if the pool is logged
Client behind source NAT at the gatewayThe gateway's LAN addressThe gateway addressOnly that some VPN user connected
Site-to-site gatewayThe remote gateway's tunnel addressThe remote site's prefixWhich site connected, not which user

A Microsoft New-NetFirewallRule-referenciája dokumentálja a távoli cím feltételeit és a LocalSubnet kulcsszót. Olvassa el, mielőtt eldöntené, hogy a kulcsszó minden magáncímre vonatkozik, mert nem így van.

Hasonlítsa össze, mit kap valójában a kiszolgáló

A ténylegesen érvényes szabályt olvassa el, ne azt, amelyet valaki emlékezete szerint létrehozott. Ellenőrizze, hogy engedélyezve van, az aktív profilra vonatkozik, és távoli cím feltétele megfelel a kiszolgáló által látott forrásnak. A csak a Domain profilon engedélyezett szabály semmit nem tesz, amikor az adapter egy hálózatváltás után Public profilra került.

Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

Az első parancs kiírja a fájlmegosztási szabályokhoz kapcsolt cím-szűrőket, a második pedig megmutatja, mely profilok aktívak, és hogyan kezeli a rendszer a nem egyező bejövő forgalmat. Keressen blokkoló szabályt és központilag kezelt házirendet is. A blokkoló szabályok elsőbbséget élveznek az engedélyező szabályokkal szemben, és a helyi szabályok egyesítését letiltó házirend teheti hatástalanná az új helyi kivételt.

Ez az az eset, amikor a szabály a konzolon helyesnek látszik, és nincs hatása a forgalomra. Egyidejűleg ellenőrizze a profil hozzárendelését, mert egy másik hálózathoz csatlakozott laptop úgy válthat a Public profilra, hogy senki nem nyúl a tűzfalhoz.

A szállítást a bejelentkezés előtt tesztelje

Válassza külön az elérhetőséget a hitelesítéstől. A TCP 445 porton figyelő szolgáltatás bizonyítja, hogy egy szolgáltatás a porthoz kötődik; nem bizonyítja, hogy egy távoli csomag el tudja érni. A befejezett TCP-kapcsolat viszont még semmit nem mond az SMB-munkamenet létrehozásáról vagy a megosztási engedélyekről. A szabály szerkesztése előtt tesztelje a kézfogást mindkét oldalról.

Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel Detailed

Az első parancs jelenti, hogy a TCP-kézfogás sikeres-e arról a gépről, amelyen futtatja, a második pedig hozzáadja a feloldott címet és az interfész részleteit. Futtassa VPN-kliensről és irodai asztali gépről, majd hasonlítsa össze. A ping egyik kérdésre sem válaszol, mert az ICMP blokkolható, miközben az SMB nyitva van, vagy engedélyezett lehet, miközben a tűzfal eldobja a 445-öt.

Ha a kézfogás csak a VPN-ről hiúsul meg, a forrás hatóköre a fő gyanúsított. Ha sikerül, és a megosztás még mindig elutasítja, térjen át az SMB-munkamenet és az engedélyek diagnosztizálására, ne a tűzfalszabályok szerkesztésére.

Amikor a forrás-NAT megszünteti a megkülönböztetést

Ha a forgalom útjában címfordítás van, a kiszolgáló nem tudja cím alapján megkülönböztetni az egyes VPN-klienseket. Minden távoli felhasználó az átjáróként érkezik. Minden olyan jogosultságot, amely a megkülönböztetésüktől függ, ott kell érvényesíteni, ahol az identitásuk még látható, ami általában a VPN-koncentrátort vagy egy hitelesítő proxyt jelent. A tűzfalszabály átengedheti a forgalmat; nem állíthatja vissza azt a megkülönböztetést, amelyet a fordítás megszüntetett.

Amint ezt az átjárócímet engedélyezik, minden távoli felhasználó egyetlen cím alatt kerül rögzítésre, így a szabály a teljes készletet biztosítja bárkinek, aki eléri az átjárót. Ha a felhasználónkénti döntés számít, tartsa láthatóvá az eredeti címeket, vagy vigye a döntést olyan rétegbe, amely még ismeri a felhasználót. Ellenkező esetben minden távoli felhasználó örökli annak az egyetlen címnek az engedélyeit, amelyet a kiszolgáló lát, és az auditnapló utólag nem tudja megkülönböztetni őket. Ez tervezési döntés, nem tűzfalrészlet.

Tudatosan válasszon a két kialakítás között. Ha a kiszolgálónak látnia kell, ki csatlakozott, szűkítse a szabályt a valódi VPN-készletre, és csak akkor fogadja el a fordított útvonalat, ha a kiszolgálónak valóban nincs szüksége erre az információra. Jegyezze fel a választott forrástartományt a szabály mellé, mert a következő hibakereső először a címtáblázatot fogja nézni.

Kapcsolódó cikkek