RRASeko VPN bezeroek beren IPv4 multzoa eta itzulbidea behar dituzte

VPN bezeroa konektatu eta helbide bat jasotzen du, baina behar duen LANeko ostalariak oraindik ezin dio erantzun. Windows Routing and Remote Access-en, VPN bezeroen barne-helbidea zerbitzariko LAN egokigailutik bereiz konfiguratutako multzo batetik dator, eta LAN aldeak itzulbidea behar du multzo horretara. Bi aldaketa, bat ez, eta modu desberdinetan huts egiten dute. Landu itzazu hurrenez hurren, helbide-plana eta itzulbidea egiaztatuta egon daitezen tarte zaharrak kendu aurretik.

Erreserbatu tartea kontsola ireki aurretik

Aukeratu LANarekin, beste VPN tarte batzuekin edo gunera bideratutako edozein gauzarekin gainjartzen ez den aurrizki bat. /24 tamaina egokia da proba bat egiteko, eta erabil daitekeen lehen zatia bezeroei eman dakieke, gainerakoa hazkunderako libre geratzen den bitartean. Idatzi helburuarekin eta jabearekin kontsolan idatzi aurretik. Utzi tokia blokearen bi muturretan, geroagoko zatiketa batek zenbakitze berria behartu ez dezan.

Kontsolan soilik bizi den helbide-plan bat berreraikuntza bakarrera dago talka batetik. Hazteko joera ere badu: norbaitek bigarren tarte bat gehitzen du geroago eta inork ez du lehena egiaztatzen. Gorde plana zerbitzariaren dokumentazioaren ondoan, ez txat-harizpidetan.

Zerbitzariaren LAN egokigailuak ez du multzo hau definitzen. Entzule publikoa aldatzeak edo LANari egokigailu bat gehitzeak guztiz beste zerbait egiten du. Horregatik konekta daitezke bezeroak eta oraindik leku okerreko helbidea jaso. Multzoa zerbitzariaren IPv4 propietateetan bizi da, ez egokigailuen zerrendan.

Metodoa aldatzea ez da tarte bat gehitzea

RRASek esleitzeko metodo bat eta tarte multzo bat ditu. DHCPtik multzo estatiko batera aldatzea metodo-aldaketa da. Multzo estatikoa jada aktibo dagoela beste bloke bat gehitzea tarte-aldaketa da.

Aurrebista egin bi eragiketei edozein exekutatu aurretik, eta irakurri zeinek bat egiten duen zerbitzariaren uneko egoerarekin:

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

Bigarren cmdlet-ak huts egiten du edo erabil ezineko multzo bat sortzen du zerbitzaria oraindik DHCP esleipenean badago. Lehenak metodoa ordezkatzen du, lehendik dagoen multzo bat handitu beharrean. Inongo aurrebistak ez du ezer aplikatzen, beraz exekutatu bat datorrena eta gero berretsi lortutako multzoa kontsolan. Ziur ez bazaude zerbitzaria zein egoeratan dagoen, irakurri esleitze-metodoa IPv4 propietateen orrian eta zerrendatu konfiguratutako tarteak:

Get-VpnIPAddressRange

DHCP metodoa tarte-zerrenda hutsarekin esan nahi du lehen aurrebista aplikatzen dela. Helbide-multzo estatiko bat lehendik dagoen tarte batekin esan nahi du bigarrena aplikatzen dela.

Kontuan hartu ezarpenak eska dezakeen zerbitzuaren berrabiaraztea, eta ez pentsatu konektatutako bezeroak berehala zenbakitzen direnik. Bere helbide zaharra mantentzen duen bezeroa berriro konektatu arte normal jokatzen ari da. Planifikatu aldaketa berriro konektatzea onargarria den leiho baterako.

LANak itzulbidea behar du

Demagun LAN 10.60.0.0/24 dela eta RRAS zerbitzaria 10.60.0.10 dela bertan. LAN horretako 10.250.50.0/24ko bezero bati erantzuten dion ostalariak multzorako bide bat behar du RRAS zerbitzariaren bidez. Bide hori gabe eskaera iristen da eta erantzuna hiltzen da.

Ostalariaren ate lehenetsia beste bideratzaile bat bada, bideratzaile horrek VPN aurrizkiaren itzulbidea behar du. RRAS zerbitzariko bide estatiko batek ez du hemen laguntzen; itzulbideak LANeko atea duen gailuan egon behar du, beraz gehitu bideratze-taulari edo bideratze dinamikoko prozesuari, gunekoak erabiltzen duenaren arabera.

Egiaztatu ostalariaren suebakia eta sareko sarbide-arauak iturburu-tarte berriaren aurka ere. Bezero-tarte zaharretarako idatzitako arauek berria baztertzen dute esleipenak arrakasta izan arren. Bezeroaren bideak LANera eta DNS ebazpena baldintza bereiziak dira, eta biak huts egin dezakete tunela osasuntsu dirudien bitartean. Probatu bakoitza bere aldetik.

Egiaztatu multzo berria gailu bakarrean zaharra kendu aurretik

Hartu kontrolatzen duzun baimen bat, konektatu berriro eta irakurri bezeroak jasotako multzo-helbidea. Zenbaki bakar horrek esleipena bideratzetik bereizten du. Gero praktikatu izendatutako aplikazio bat, begiratu itzulera-trafikoa eta probatu baztertuta egon behar duen helmuga bat. Hiru behaketa, hiru hutsegite modu desberdin.

Izen-ebazpenak bere proba propioa merezi du: IP bidezko sarbidea funtziona dezake bezeroaren DNSak iritsi ezin duen resolver batera seinalatzen duen bitartean. LANeko DNS zerbitzari bat irisgarria da bezeroak hara bidea badu eta zerbitzariak tarte berritik kontsultak onartzen baditu. Biak huts egite arruntak dira multzoa lekuz aldatzen denean.

Kendu tarte zaharrak eta haien salbuespenak saio aktiboak eta mantentze-prozesua kontuan hartu ondoren soilik. Helbide berria duen bezero konektatu batek esleipena frogatzen du, ez sarbide-politika. Euts iezaiozu tarte zaharrari dokumentatuta hura erabili zuen azken saioa iraungi arte.

Egiaztatu emaitza hiru behaketarekin

Onarpenak hiru gertaera behar ditu: bezeroak multzo berriko helbidea du, LANeko ostalari batek hura iritsi eta erantzuna jaso dezake, eta baztertutako helmuga baztertuta jarraitzen du. Bakoitzak bere egiaztapena du, beraz hutsegite batek esleipena, bideratzea edo politika adierazten du. Exekutatu ordena horretan.

Bezerotik, berretsi helbidea eta LANeko ostalari batera dagoen bidea:

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

LANeko ostalaritik, berretsi itzulera-bidea eta politika pasaldi bakarrean. Ping-ek huts egiten badu baina aplikazioak funtzionatzen badu, falta den pieza ICMP arau bat izateko aukera handia da, ez bidea. Biak huts egiten badute, irakurri bidea ostalarian VPNa editatu aurretik. Idatzi hiru emaitzak aldaketa-txartelean, hurrengo pertsonak frogaketatik has dadin.