Ang mga kliyenteng VPN ng RRAS ay nangangailangan ng sariling pool ng IPv4 at daan pabalik

Kumokonekta ang kliyenteng VPN at tumatanggap ng address, ngunit ang host ng LAN na kailangan nito ay hindi pa rin ito masagot. Sa Windows Routing and Remote Access, ang panloob na address ng mga kliyenteng VPN ay nagmumula sa pool na naka-configure nang hiwalay sa LAN adapter ng server, at ang panig ng LAN ay nangangailangan ng ruta pabalik sa pool na iyon. Dalawang pagbabago, hindi isa, at nabigo ang mga ito sa magkaibang paraan. Gawin ang mga ito nang sunud-sunod upang mapatunayan ang plano ng address at ang daan pabalik bago alisin ang mga lumang saklaw.

Ireserba ang saklaw bago buksan ang console

Pumili ng prefix na hindi nagsasapawan sa LAN, sa iba pang saklaw ng VPN o sa anumang niruruta papunta sa site. Ang /24 ay maginhawang sukat para sa isang pagsubok, at ang unang bahaging magagamit ay maaaring ibigay sa mga kliyente habang ang natitira ay nananatiling malaya para sa paglago. Isulat ito kasama ang layunin at may-ari bago i-type sa console. Mag-iwan ng puwang sa magkabilang dulo ng bloke upang ang huling paghahati ay hindi magpilit ng muling pagbilang.

Ang planong address na nabubuhay lamang sa console ay isang muling pagtatayo ang layo mula sa banggaan. May tendensiya rin itong lumaki: may nagdaragdag ng pangalawang saklaw mamaya at walang sumusuri sa una. Itago ang plano sa tabi ng dokumentasyon ng server, hindi sa usapan.

Hindi tinutukoy ng LAN adapter ng server ang pool na ito. Ang pagbabago ng pampublikong tagapakinig o pagdaragdag ng adapter sa LAN ay gumagawa ng ibang bagay. Kaya nga ang mga kliyente ay makakakonekta at makakatanggap pa rin ng address mula sa maling lugar. Ang pool ay naninirahan sa mga katangian ng IPv4 ng server, hindi sa listahan ng adapter.

Ang pagbabago ng paraan ay hindi pagdaragdag ng saklaw

May paraan ng pagtatalaga ang RRAS at may hanay ng mga saklaw. Ang paglipat mula sa DHCP patungo sa static na pool ay pagbabago ng paraan. Ang pagdaragdag ng isa pang bloke habang aktibo na ang static na pool ay pagbabago ng saklaw.

Tingnan muna ang dalawang operasyon bago patakbuhin ang alinman, at basahin kung alin ang tumutugma sa kasalukuyang kalagayan ng server:

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

Nabigo ang pangalawang cmdlet o gumagawa ng hindi magagamit na pool kung ang server ay nasa pagtatalaga pa ng DHCP. Pinapalitan ng una ang paraan sa halip na palawigin ang umiiral na pool. Walang paunang pagtingin ang naglalapat ng anuman, kaya patakbuhin ang tumutugma, pagkatapos ay kumpirmahin ang nagresultang pool sa console. Kung hindi ka sigurado sa kalagayan ng server, basahin ang paraan ng pagtatalaga sa pahina ng mga katangian ng IPv4 at ilista ang mga naka-configure na saklaw:

Get-VpnIPAddressRange

Ang paraang DHCP na may walang laman na listahan ng saklaw ay nangangahulugang nalalapat ang unang paunang pagtingin. Ang static na pool ng address na may umiiral na saklaw ay nangangahulugang nalalapat ang pangalawa.

Isaalang-alang ang pag-restart ng serbisyo na maaaring kailanganin ng setting, at huwag ipalagay na ang mga nakakonektang kliyente ay agad na muling bibilangin. Ang kliyenteng nagpapanatili ng lumang address hanggang sa muling kumonekta ay kumikilos nang normal. Planuhin ang pagbabago para sa isang panahon kung kailan katanggap-tanggap ang muling pagkonekta.

Ang LAN ay nangangailangan ng daan pabalik

Ipagpalagay na ang LAN ay 10.60.0.0/24 at ang server ng RRAS ay 10.60.0.10 dito. Ang host sa LAN na iyon na sumasagot sa kliyente sa 10.250.50.0/24 ay nangangailangan ng daan patungo sa pool sa pamamagitan ng server ng RRAS. Kung wala ang daang iyon, dumarating ang kahilingan at namamatay ang tugon.

Kung ang default na gateway ng host ay ibang router, ang router na iyon ay nangangailangan ng rutang pabalik para sa prefix ng VPN. Ang static na ruta sa server ng RRAS ay hindi makakatulong dito; ang daan pabalik ay dapat umiral sa aparatong may-ari ng gateway ng LAN, kaya idagdag ito sa talahanayan ng ruta o sa proseso ng dynamic na rutang ginagamit ng site.

Suriin din ang firewall ng host at anumang tuntunin sa pag-access sa network laban sa bagong saklaw ng pinagmulan. Ang mga tuntuning isinulat para sa lumang saklaw ng kliyente ay tinatanggihan ang bago kahit nagtagumpay ang pagtatalaga. Ang mga ruta ng kliyente patungo sa LAN at ang resolusyon ng DNS ay magkahiwalay na pangangailangan, at parehong maaaring mabigo habang mukhang malusog ang tunel. Subukan ang bawat isa nang hiwalay.

Patunayan ang bagong pool sa isang aparato bago alisin ang luma

Kumuha ng isang awtorisasyong kontrolado mo, kumonekta muli at basahin ang address ng pool na natanggap ng kliyente. Ang nag-iisang bilang na iyon ang naghihiwalay ng pagtatalaga sa ruta. Pagkatapos ay subukan ang isang pinangalanang aplikasyon, panoorin ang trapikong pabalik at subukan ang destinasyong dapat manatiling tinanggihan. Tatlong obserbasyon, tatlong magkaibang paraan ng pagkasira.

Ang resolusyon ng pangalan ay karapat-dapat sa sariling pagsubok: maaaring gumana ang pag-access sa pamamagitan ng IP habang ang DNS ng kliyente ay tumuturo pa rin sa isang resolver na hindi nito maabot. Ang server ng DNS sa LAN ay maaabot lamang kung ang kliyente ay may ruta patungo rito at tinatanggap ng server ang mga tanong mula sa bagong saklaw. Pareho itong karaniwang napapalampas kapag lumilipat ang pool.

Alisin ang lumang saklaw at ang mga eksepsiyon nito pagkatapos lamang isaalang-alang ang mga aktibong sesyon at ang proseso ng pagpapanatili. Ang nakakonektang kliyente na may bagong address ay nagpapatunay ng pagtatalaga, hindi ng patakaran sa pag-access. Itago ang dokumentasyon ng lumang saklaw hanggang sa mag-expire ang huling sesyong gumamit nito.

Suriin ang resulta gamit ang tatlong obserbasyon

Ang pagtanggap ay nangangailangan ng tatlong katotohanan: may address ang kliyente mula sa bagong pool, maaabot ito ng host ng LAN at makakakuha ng tugon, at ang tinanggihang destinasyon ay nananatiling tinanggihan. Bawat isa ay may sariling pagsusuri, kaya ang kabiguan ay tumuturo sa pagtatalaga, ruta o patakaran. Patakbuhin ang mga ito sa ganoong pagkakasunod-sunod.

Mula sa kliyente, kumpirmahin ang address at ang ruta patungo sa isang host ng LAN:

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

Mula sa host ng LAN, kumpirmahin ang daan ng tugon at ang patakaran sa isang pagdaan. Kung nabigo ang ping ngunit gumagana ang aplikasyon, ang kulang na bahagi ay malamang na tuntunin ng ICMP at hindi ang ruta. Kung parehong nabigo, basahin ang ruta sa host bago i-edit ang VPN. Itala ang tatlong resulta sa tiket ng pagbabago upang magsimula ang susunod na tao sa ebidensiya.