Hálózati meghajtó VPN-en keresztül telephelyek között: DNS, SMB és az UNC-útvonal

Az Intéző Hálózat lapja azokat az eszközöket mutatja, amelyek bejelentkeztek a helyi szegmensbe, és egy irányított alagút egyetlen ilyen bejelentést sem továbbít. Ezért lehet egy kiszolgáló teljesen elérhető, miközben a felhasználó előtti ablak üres marad. Egy megnevezett UNC-útvonal egyáltalán nem függ a felderítéstől, és a megoldás az, hogy a név feloldódjon, a port pedig válaszoljon. Az üres ablak a rossz réteg tünete, nem a hibás megosztásé.

A felderítés nem ugyanaz, mint az elérhetőség

A Windows a közeli gépeket broadcast-tartományra tervezett protokollokkal deríti fel, majd a találtakat kényelmi listaként jeleníti meg. Ebből a listából semmi sem szükséges az SMB-fájleléréshez. Az a kliens, amely ismeri a kiszolgáló nevét és eléri a TCP 445-öt, megnyitja a megosztást, akár megjelenik valaha a gép a Hálózat alatt, akár nem.

A két réteg egymástól függetlenül hibázik, ezért a "nem látom" és a "nem tudom megnyitni" különböző teszteket érdemel. A lista nézegetése a felderítésről szól; az útvonal megnyitása a szolgáltatásról.

Nevezze meg a kiszolgálót, mielőtt csatlakoztatja a megosztást

Tegye közzé a fájlkiszolgálót a DNS-ben a túloldali címével, és irányítsa az ügyfél telephelyét olyan feloldóra, amely képes válaszolni arra a zónára. A teljesen minősített név elkerüli a helyi utótag-keresőlista függőségét, ami a szokásos oka annak, hogy egy rövid név az egyik telephelyen működik, a másikon pedig nem.

Ha a környezet Active Directoryt használ, a névfeloldás az autentikáció része is: a kliensnek el kell érnie egy tartományvezérlőt a Kerberoshoz, és a túlságosan eltérő óra miatt a jegycsere meghiúsul. Ez más probléma, mint az SMB elérhetősége, és hitelesítő adat hibájának látszik. Tesztelje a tartományvezérlőt, mielőtt újra beírja a jelszót.

Irányművelés és szűrés mindkét irányban

A telephelyek közötti alagútnak szüksége van a távoli előtagra a helyi útválasztási táblában és a helyi előtagra a távoliban, és mindkét oldalon a tűzfalnak engedélyeznie kell a beérkező forgalmat. Az egyirányú beállítás olyan kapcsolatot hoz létre, amely megnyílik és soha nem válaszol, amit a felhasználók lassú megosztásként írnak le. Először az alagút saját számlálóit ellenőrizze. Ha a csomagok elmennek és semmi sem jön vissza, keresse a visszirányú útvonalat vagy a távoli szűrőt.

WireGuard esetén a partner engedélyezett IP-címeinek és az operációs rendszer útvonalainak összhangban kell lenniük ezzel a tervvel. Az alagút csomagokat szállít; nem biztosít DNS-rekordokat vagy megosztási engedélyeket egyik oldalon sem.

A tűzfalszabályt a tényleges forráshálózatra alapozza, amely csatlakozni fog, és jegyezze fel a kivételt. Ha a terv valahol az útvonalon címeket fordít, a szabálynak a fordított forrást kell használnia, és az eredeti ügyfélcím már nem látható a naplókban.

Hitelesítsen, majd csatlakoztassa a meghajtót

Haladjon végig a rétegeken parancsokkal az Intéző ablaka helyett:

Resolve-DnsName -Name files.corp.example -Type A
Test-NetConnection -ComputerName files.corp.example -Port 445
net use Z: \\files.corp.example\Projects /persistent:no

A második parancs a TCP-útvonalat bizonyítja, nem az olvasás jogát. A harmadik az, ahol az autentikáció és az engedélyezés érvényesül, és az ottani hiba a megosztás és a fájlrendszer engedélyeihez küldje, ne vissza az útválasztóhoz.

Tartsa érintetlenül az SMB-aláírást és a meglévő hitelesítési házirendet. Az SMB1 újbóli engedélyezése vagy a felderítési broadcastok alagúton át történő továbbítása nem szükséges egy explicit útvonalhoz, és a TCP 445 maradjon a privát útvonalon, ne egy internet felé nyitott továbbításon. Adjon a felhasználóknak felügyelt parancsikont vagy a jóváhagyott névre mutató csatlakoztatott meghajtót, és az üres Hálózat lap többé nem számít.