Klienti VPN v RRAS potřebují vlastní fond IPv4 a cestu zpět

Samostatný statický fond v RRAS je jen polovina změny. Vyberte správný cmdlet a potom dejte hostitelům v LAN zpětnou trasu k novému rozsahu klientů.

Klient VPN se připojí a dostane adresu, ale hostitel v LAN, kterého potřebuje, mu stále nemůže odpovědět. V Windows Routing and Remote Access pochází vnitřní adresa klientů VPN z fondu nakonfigurovaného odděleně od síťového adaptéru serveru a strana LAN potřebuje trasu zpět do tohoto fondu. Dvě změny, ne jedna, a selhávají různými způsoby. Projděte je popořadě, aby byl plán adres a zpětná cesta prokázány dřív, než se staré rozsahy vyřadí.

Rezervujte rozsah, než otevřete konzolu

Zvolte prefix, který se nepřekrývá s LAN, jinými rozsahy VPN ani s ničím, co se směruje do lokality. /24 je pro test vhodná velikost a první použitelnou část lze předat klientům, zatímco zbytek zůstane volný pro růst. Zapište ho s účelem a vlastníkem, než ho zadáte do konzoly. Ponechte místo na obou koncích bloku, aby pozdější rozdělení nevynutilo přečíslování.

Plán adres, který žije jen v konzoli, je jednu přestavbu od kolize. Také má tendenci růst: někdo později přidá druhý rozsah a nikdo nezkontroluje první. Uchovávejte plán vedle dokumentace serveru, ne ve vlákně chatu.

Síťový adaptér serveru tento fond nedefinuje. Změna veřejného listeneru nebo přidání adaptéru do LAN dělá něco úplně jiného. Proto se klienti mohou připojit a přesto dostat adresu ze špatného místa. Fond žije ve vlastnostech IPv4 serveru, ne v seznamu adaptérů.

Změna metody není přidání rozsahu

RRAS má metodu přiřazení a sadu rozsahů. Přechod z DHCP na statický fond je změna metody. Přidání dalšího bloku, když je statický fond už aktivní, je změna rozsahu.

Prohlédněte si obě operace, než některou spustíte, a přečtěte si, která odpovídá aktuálnímu stavu serveru:

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

Druhý cmdlet selže nebo vytvoří nepoužitelný fond, pokud server stále používá přiřazení DHCP. První nahrazuje metodu, místo aby rozšiřoval existující fond. Žádný náhled nic neaplikuje, takže spusťte ten, který odpovídá, a potom výsledný fond potvrďte v konzoli. Pokud si nejste jisti, v jakém stavu server je, přečtěte si metodu přiřazení na stránce vlastností IPv4 a vypište nakonfigurované rozsahy:

Get-VpnIPAddressRange

Metoda DHCP s prázdným seznamem rozsahů znamená, že platí první náhled. Statický fond adres s existujícím rozsahem znamená, že platí druhý.

Počítejte s restartem služby, který nastavení může vyžadovat, a nepředpokládejte, že připojení klienti budou hned přečíslováni. Klient, který si drží starou adresu, dokud se znovu nepřipojí, se chová normálně. Naplánujte změnu na okno, kdy je opětovné připojení přijatelné.

LAN potřebuje cestu zpět

Předpokládejme, že LAN je 10.60.0.0/24 a server RRAS je v ní 10.60.0.10. Hostitel v této LAN, který odpovídá klientovi v 10.250.50.0/24, potřebuje cestu do fondu přes server RRAS. Bez této cesty požadavek dorazí a odpověď umře.

Pokud je výchozí brána hostitele jiný router, tento router potřebuje zpětnou trasu pro prefix VPN. Statická trasa na serveru RRAS zde nepomůže; zpětná cesta musí existovat na zařízení, které vlastní bránu LAN, takže ji přidejte do směrovací tabulky nebo do procesu dynamického směrování, podle toho, co lokalita používá.

Zkontrolujte také firewall hostitele a všechna pravidla síťového přístupu proti novému zdrojovému rozsahu. Pravidla napsaná pro starý rozsah klientů odmítají nový, i když přiřazení uspělo. Trasy klienta k LAN a překlad DNS jsou samostatné požadavky a obojí může selhat, zatímco tunel vypadá zdravě. Otestujte každý zvlášť.

Prokažte nový fond na jednom zařízení, než vyřadíte starý

Vezměte jedno oprávnění, které ovládáte, znovu se připojte a přečtěte adresu fondu, kterou klient dostal. To jediné číslo odděluje přiřazení od směrování. Potom spusťte pojmenovanou aplikaci, sledujte zpětný provoz a zkuste cíl, který má zůstat zakázaný. Tři pozorování, tři různé režimy selhání.

Překlad názvů si zaslouží vlastní test: přístup přes IP může fungovat, zatímco DNS klienta stále ukazuje na resolver, ke kterému se nedostane. Server DNS v LAN je dostupný jen tehdy, má-li k němu klient trasu a server přijímá dotazy z nového rozsahu. Obě jsou častá opomenutí, když se fond přesouvá.

Staré rozsahy a jejich výjimky vyřaďte až po zohlednění aktivních relací a procesu údržby. Připojený klient s novou adresou dokazuje přiřazení, ne zásady přístupu. Uchovávejte starý rozsah zdokumentovaný, dokud nevyprší poslední relace, která ho použila.

Ověřte výsledek třemi pozorováními

Přijetí vyžaduje tři skutečnosti: klient má adresu z nového fondu, hostitel v LAN se k němu dostane a dostane odpověď a zakázaný cíl zůstává zakázaný. Každá má vlastní kontrolu, takže selhání ukazuje na přiřazení, směrování nebo zásady. Spusťte je v tomto pořadí.

Z klienta potvrďte adresu a trasu k jednomu hostiteli v LAN:

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

Z hostitele v LAN potvrďte zpětnou cestu a zásady v jednom průchodu. Pokud ping selže, ale aplikace funguje, chybějící částí je pravděpodobně pravidlo ICMP, ne trasa. Pokud selže obojí, přečtěte si trasu na hostiteli, než začnete upravovat VPN. Zapište tři výsledky do tiketu změny, aby další člověk začal od důkazů.

Související články