RRAS-i VPN-kliendid vajavad omaette IPv4-kokku ja teed tagasi
Eraldi staatiline kogum RRAS-is on ainult pool muudatusest. Valige õige cmdlet ja andke seejärel LAN-i hostidele tagasitee uude kliendivahemikku.
VPN-klient ühendub ja saab aadressi, kuid LAN-i host, mida ta vajab, ei saa talle endiselt vastata. Windows Routing and Remote Accessis pärineb VPN-klientide sisemine aadress kogumist, mis on seadistatud serveri LAN-adapterist eraldi, ja LAN-i pool vajab tagasiteed sellesse kogumisse. Kaks muudatust, mitte üks, ja need nurjuvad erineval moel. Käige need järjekorras läbi, et aadressiplaan ja tagasitee oleksid tõestatud enne vanade vahemike kasutusest kõrvaldamist.
Broneerige vahemik enne konsooli avamist
Valige eesliide, mis ei kattu LAN-i, teiste VPN-vahemike ega millegagi, mis on saidile suunatud. /24 on testi jaoks mugav suurus ja esimese kasutatava osa saab anda klientidele, samal ajal kui ülejäänu jääb kasvuks vabaks. Kirjutage see koos otstarbe ja omanikuga üles enne, kui selle konsooli trükite. Jätke ploki mõlemasse otsa ruumi, et hilisem jaotus ei sunniks uuesti numbreid panema.
Aadressiplaan, mis elab ainult konsoolis, on ühe ülesehituse kaugusel kokkupõrkest. See kipub ka kasvama: keegi lisab hiljem teise vahemiku ja keegi ei kontrolli esimest. Hoidke plaani serveri dokumentatsiooni kõrval, mitte vestluslõimes.
Serveri LAN-adapter ei määra seda kogumit. Avaliku kuulaja muutmine või adapteri lisamine LAN-i teeb hoopis midagi muud. Seetõttu saavad kliendid ühenduda ja saada siiski aadressi valest kohast. Kogum elab serveri IPv4-omadustes, mitte adapterite loendis.
Meetodi vahetamine ei ole vahemiku lisamine
RRAS-il on määramismeetod ja vahemike kogum. Üleminek DHCP-lt staatilisele kogumile on meetodi muudatus. Teise ploki lisamine, kui staatiline kogum on juba aktiivne, on vahemiku muudatus.
Eelvaadake mõlemat toimingut enne kummagi käivitamist ja lugege, milline vastab serveri praegusele olekule:
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
Teine cmdlet nurjub või loob kasutuskõlbmatu kogumi, kui server on veel DHCP-määramisel. Esimene asendab meetodi, selle asemel et olemasolevat kogumit laiendada. Kumbki eelvaade ei rakenda midagi, seega käivitage sobiv ja kinnitage seejärel saadud kogum konsoolis. Kui te pole kindel, mis olekus server on, lugege määramismeetodit IPv4-omaduste lehel ja loetlege seadistatud vahemikud:
Get-VpnIPAddressRange
Meetod DHCP tühja vahemikuloendiga tähendab, et kehtib esimene eelvaade. Staatiline aadressikogum olemasoleva vahemikuga tähendab, et kehtib teine.
Arvestage teenuse taaskäivitamisega, mida seade võib nõuda, ja ärge eeldage, et ühendatud kliendid nummerdatakse kohe ümber. Klient, kes hoiab oma vana aadressi, kuni uuesti ühendub, käitub normaalselt. Planeerige muudatus aknale, kus uuesti ühendamine on vastuvõetav.
LAN vajab tagasiteed
Oletame, et LAN on 10.60.0.0/24 ja RRAS-server on selles 10.60.0.10. Selle LAN-i host, mis vastab kliendile aadressil 10.250.50.0/24, vajab teed kogumisse läbi RRAS-serveri. Ilma selle teeta jõuab päring kohale ja vastus sureb.
Kui hosti vaikelüüs on teine ruuter, vajab see ruuter VPN-i eesliite jaoks tagasiteed. Staatiline marsruut RRAS-serveris ei aita siin; tagasitee peab olema seadmes, millele kuulub LAN-i lüüs, seega lisage see marsruutimistabelisse või dünaamilise marsruutimise protsessi, olenevalt sellest, mida sait kasutab.
Kontrollige ka hosti tulemüüri ja kõiki võrgu juurdepääsu reegleid uue lähtevahemiku suhtes. Vanale kliendivahemikule kirjutatud reeglid lükkavad uue tagasi ka siis, kui määramine õnnestus. Kliendi marsruudid LAN-i suunas ja DNS-i lahendamine on eraldi nõuded ning mõlemad võivad nurjuda, samal ajal kui tunnel tundub terve. Testige kumbagi eraldi.
Tõestage uus kogum ühes seadmes enne vana kasutusest kõrvaldamist
Võtke üks volitus, mida kontrollite, ühenduge uuesti ja lugege kogumi aadress, mille klient sai. See üks number eraldab määramise marsruutimisest. Seejärel käivitage nimetatud rakendus, jälgige tagasiliiklust ja proovige sihtkohta, mis peaks jääma keelatuks. Kolm vaatlust, kolm erinevat tõrkerežiimi.
Nimede lahendamine väärib omaette testi: IP-ga juurdepääs võib töötada, samal ajal kui kliendi DNS osutab endiselt resolverile, kuhu ta ei pääse. LAN-is asuv DNS-server on kättesaadav ainult siis, kui kliendil on sinna marsruut ja server võtab vastu päringuid uuest vahemikust. Mõlemad on sagedased puudujäägid, kui kogum liigub.
Kõrvaldage vanad vahemikud ja nende erandid alles pärast aktiivsete sessioonide ja hooldusprotsessi arvestamist. Ühendatud klient uue aadressiga tõestab määramist, mitte juurdepääsupoliitikat. Hoidke vana vahemik dokumenteerituna, kuni viimane seda kasutanud sessioon on aegunud.
Kontrollige tulemust kolme vaatlusega
Vastuvõtt nõuab kolme fakti: kliendil on aadress uuest kogumist, LAN-i host pääseb temani ja saab vastuse ning keelatud sihtkoht jääb keelatuks. Igal on oma kontroll, seega tõrge osutab määramisele, marsruutimisele või poliitikale. Käivitage need selles järjekorras.
Kliendi poolelt kinnitage aadress ja marsruut ühe LAN-i hostini:
ipconfig | findstr /i "IPv4"
route print -4
LAN-i hosti poolelt kinnitage tagasitee ja poliitika ühe läbimisega. Kui ping nurjub, aga rakendus töötab, on puuduv tükk tõenäoliselt ICMP-reegel, mitte marsruut. Kui mõlemad nurjuvad, lugege marsruut hostis enne VPN-i muutmist. Kirjutage kolm tulemust muudatuse piletisse, et järgmine inimene alustaks tõenditest.