A VPN-kliens csatlakozik és kap egy címet, a szükséges LAN-gazdagép mégsem tud válaszolni neki. A Windows Routing and Remote Accessben a VPN-kliensek belső címe a szerver LAN-adapterétől külön beállított készletből származik, és a LAN oldalának visszaútvonalra van szüksége ehhez a készlethez. Két változás, nem egy, és különböző módon hibáznak. Haladjon végig rajtuk sorrendben, hogy a címterv és a visszaút bizonyítást nyerjen, mielőtt a régi tartományok kikerülnek.

Foglalja le a tartományt, mielőtt megnyitja a konzolt

Válasszon olyan előtagot, amely nem fedi át a LAN-t, más VPN-tartományokat vagy bármit, ami az oldalra van irányítva. A /24 kényelmes méret egy teszthez, és az első használható rész a klienseknek adható, míg a többi szabadon marad a növekedéshez. Írja le a céljával és tulajdonosával együtt, mielőtt beírja egy konzolba. Hagyjon helyet a blokk mindkét végén, hogy egy későbbi felosztás ne kényszerítsen újraszámozásra.

Az a címterv, amely csak egy konzolban él, egy újjáépítésnyire van az ütközéstől. Hajlamos növekedni is: valaki később hozzáad egy második tartományt, és senki nem ellenőrzi az elsőt. Tartsa a tervet a szerver dokumentációja mellett, ne egy csevegőszálban.

A szerver LAN-adaptere nem határozza meg ezt a készletet. A nyilvános figyelő módosítása vagy egy adapter hozzáadása a LAN-hoz egészen mást tesz. Ezért tudnak a kliensek csatlakozni, és mégis rossz helyről címet kapni. A készlet a szerver IPv4-tulajdonságaiban él, nem az adapterlistában.

A módszer váltása nem tartomány hozzáadása

Az RRAS-nak van hozzárendelési módszere és tartománykészlete. DHCP-ről statikus készletre váltás módszerváltás. Egy másik blokk hozzáadása, miközben a statikus készlet már aktív, tartományváltozás.

Nézze át mindkét műveletet, mielőtt bármelyiket futtatja, és olvassa el, melyik illik a szerver jelenlegi állapotához:

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

A második cmdlet meghiúsul vagy használhatatlan készletet hoz létre, ha a szerver még DHCP-hozzárendelésen van. Az első lecseréli a módszert, ahelyett hogy egy meglévő készletet bővítene. Egyik előnézet sem alkalmaz semmit, ezért futtassa a megfelelőt, majd erősítse meg az eredményül kapott készletet a konzolon. Ha nem biztos benne, milyen állapotban van a szerver, olvassa el a hozzárendelési módszert az IPv4-tulajdonságok oldalon, és listázza a beállított tartományokat:

Get-VpnIPAddressRange

A DHCP módszer üres tartománylistával azt jelenti, hogy az első előnézet érvényes. A statikus címkészlet meglévő tartománnyal azt jelenti, hogy a második érvényes.

Számoljon a szolgáltatás újraindításával, amelyet a beállítás igényelhet, és ne feltételezze, hogy a csatlakozott kliensek azonnal újraszámozódnak. Az a kliens, amely a régi címét az újracsatlakozásig megtartja, normálisan viselkedik. Tervezze a változást olyan ablakra, ahol az újracsatlakozás elfogadható.

A LAN-nak visszaútvonalra van szüksége

Tegyük fel, hogy a LAN 10.60.0.0/24, és az RRAS-kiszolgáló 10.60.0.10 ezen. Az ezen a LAN-on lévő gazdagépnek, amely egy 10.250.50.0/24-es kliensnek válaszol, útra van szüksége a készlethez az RRAS-kiszolgálón keresztül. E nélkül az út nélkül a kérés megérkezik, és a válasz meghal.

Ha a gazdagép alapértelmezett átjárója másik útválasztó, annak az útválasztónak szüksége van a VPN-előtag visszaútvonalára. Az RRAS-kiszolgálón lévő statikus útvonal itt nem segít; a visszaútnak azon az eszközön kell léteznie, amely a LAN-átjárót birtokolja, ezért adja hozzá az útválasztási táblához vagy a dinamikus útválasztási folyamathoz, attól függően, mit használ az oldal.

Ellenőrizze a gazdagép tűzfalát és a hálózati hozzáférési szabályokat is az új forrástartomány ellenében. A régi klientartományhoz írt szabályok elutasítják az újat, még ha a hozzárendelés sikerült is. A kliens LAN felé vezető útvonalai és a DNS-feloldás külön követelmények, és mindkettő meghiúsulhat, miközben az alagút egészségesnek látszik. Tesztelje mindegyiket külön.

Bizonyítsa az új készletet egy eszközön, mielőtt a régit kivonja

Vegyen egy Ön által irányított engedélyt, csatlakozzon újra, és olvassa le a készlet címét, amelyet a kliens kapott. Az az egyetlen szám választja el a hozzárendelést az útválasztástól. Utána gyakoroljon egy megnevezett alkalmazást, figyelje a visszaforgalmat, és próbáljon ki egy célt, amelynek elutasítva kell maradnia. Három megfigyelés, három különböző hibaút.

A névfeloldás saját tesztet érdemel: az IP szerinti hozzáférés működhet, miközben a kliens DNS-e még mindig egy olyan feloldóra mutat, amelyet nem ér el. A LAN-on lévő DNS-kiszolgáló csak akkor érhető el, ha a kliensnek útvonala van hozzá, és a kiszolgáló elfogadja az új tartományból érkező lekérdezéseket. Mindkettő gyakori mulasztás, amikor a készlet elmozdul.

A régi tartományokat és kivételeiket csak az aktív munkamenetek és a karbantartási folyamat figyelembevétele után vonja ki. Az új címmel csatlakozó kliens a hozzárendelést bizonyítja, nem a hozzáférési szabályzatot. Tartsa dokumentálva a régi tartományt, amíg az utolsó, azt használó munkamenet le nem jár.

Ellenőrizze az eredményt három megfigyeléssel

Az elfogadáshoz három tény kell: a kliensnek van címe az új készletből, egy LAN-gazdagép eléri és választ kap tőle, és az elutasított cél továbbra is elutasított. Mindegyiknek megvan a maga ellenőrzése, ezért a hiba a hozzárendelésre, az útválasztásra vagy a szabályzatra mutat. Ebben a sorrendben futtassa őket.

A kliens oldaláról erősítse meg a címet és az útvonalat egy LAN-gazdagéphez:

ipconfig | findstr /i "IPv4"
route print -4

A LAN-gazdagép oldaláról egy menetben erősítse meg a visszaút és a szabályzat meglétét. Ha a ping meghiúsul, de az alkalmazás működik, a hiányzó darab valószínűleg egy ICMP-szabály, nem az útvonal. Ha mindkettő meghiúsul, olvassa el az útvonalat a gazdagépen, mielőtt szerkesztené a VPN-t. Jegyezze fel a három eredményt a változási jegyben, hogy a következő ember bizonyítékokból induljon ki.

Kapcsolódó cikkek