Klientoj de VPN en RRAS bezonas propran IPv4-basenon kaj revenan vojon

La kliento de VPN konektiĝas kaj ricevas adreson, sed la gastiganto de LAN, kiun ĝi bezonas, ankoraŭ ne povas respondi al ĝi. En Windows Routing and Remote Access la interna adreso por klientoj de VPN venas el baseno agordita aparte de la LAN-adaptilo de la servilo, kaj la flanko de LAN bezonas itineron reen al tiu baseno. Du ŝanĝoj, ne unu, kaj ili malsukcesas laŭ malsamaj manieroj. Trairu ilin laŭvice, por ke la adresplano kaj la revena vojo estu pruvitaj antaŭ ol malnovaj gamoj estos retiritaj.

Rezervu la gamon antaŭ ol malfermi la konzolon

Elektu prefikson, kiu ne interkovriĝas kun la LAN, kun aliaj gamoj de VPN aŭ kun io ajn enrutigita al la ejo. /24 estas oportuna grando por testo, kaj la unua uzebla parto povas esti donita al klientoj dum la resto restas libera por kresko. Skribu ĝin kun ĝia celo kaj posedanto antaŭ ol enigi ĝin en konzolon. Lasu spacon ĉe ambaŭ finoj de la bloko, por ke posta divido ne devigu renumeradon.

Adresplano, kiu vivas nur en konzolo, estas unu rekonstruo for de kolizio. Ĝi ankaŭ emas kreski: iu aldonas duan gamon poste kaj neniu kontrolas la unuan. Tenu la planon apud la servila dokumentaro, ne en babileja fadeno.

La LAN-adaptilo de la servilo ne difinas ĉi tiun basenon. Ŝanĝi la publikan aŭskultanton aŭ aldoni adaptilon al la LAN faras ion tute alian. Tial klientoj povas konektiĝi kaj tamen ricevi adreson el la malĝusta loko. La baseno vivas en la IPv4-ecoj de la servilo, ne en la adaptila listo.

Ŝanĝi la metodon ne signifas aldoni gamon

RRAS havas asignan metodon kaj aron da gamoj. Transiri de DHCP al statika baseno estas ŝanĝo de metodo. Aldoni alian blokon dum la statika baseno jam estas aktiva estas ŝanĝo de gamo.

Antaŭrigardu ambaŭ operaciojn antaŭ ol ekzekuti iun ajn, kaj legu, kiu kongruas kun la nuna stato de la servilo:

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

La dua cmdlet malsukcesas aŭ kreas neuzeblan basenon se la servilo ankoraŭ uzas DHCP-asignon. La unua anstataŭigas la metodon anstataŭ etendi ekzistantan basenon. Neniu antaŭrigardo aplikas ion, do ekzekutu la kongruan kaj poste konfirmu la rezultan basenon en la konzolo. Se vi ne certas, en kiu stato la servilo estas, legu la asignan metodon sur la paĝo de IPv4-ecoj kaj listigu la agorditajn gamojn:

Get-VpnIPAddressRange

Metodo DHCP kun malplena listo de gamoj signifas, ke validas la unua antaŭrigardo. Statika adresbaseno kun ekzistanta gamo signifas, ke validas la dua.

Kalkulu la restartigon de la servo, kiun la agordo povas postuli, kaj ne supozu, ke konektitaj klientoj tuj renumeriĝos. Kliento, kiu tenas sian malnovan adreson ĝis ĝi rekonektiĝos, kondutas normale. Planu la ŝanĝon por fenestro, en kiu rekonekto estas akceptebla.

La LAN bezonas revenan itineron

Supozu, ke la LAN estas 10.60.0.0/24 kaj la servilo RRAS estas 10.60.0.10 en ĝi. Gastiganto en tiu LAN, kiu respondas al kliento en 10.250.50.0/24, bezonas vojon al la baseno tra la servilo RRAS. Sen tiu vojo la peto alvenas kaj la respondo mortas.

Se la defa enirejo de la gastiganto estas alia enkursigilo, tiu enkursigilo bezonas la revenan itineron por la prefikso de VPN. Statika itinero sur la servilo RRAS ne helpas ĉi tie; la revena vojo devas ekzisti sur la aparato, kiu posedas la enirejon de la LAN, do aldonu ĝin al la enkursiga tabelo aŭ al la dinamika enkursiga procezo, laŭ tio, kion la ejo uzas.

Kontrolu ankaŭ la fajroŝirmilon de la gastiganto kaj ĉiajn regulojn pri reta aliro kontraŭ la nova fonta gamo. Reguloj skribitaj por la malnova klienta gamo malakceptas la novan eĉ se la asigo sukcesis. Klientaj itineroj al la LAN kaj DNS-resolvo estas apartaj postuloj, kaj ambaŭ povas malsukcesi dum la tunelo aspektas sana. Testu ĉiun aparte.

Pruvu la novan basenon sur unu aparato antaŭ ol retiri la malnovan

Prenu unu rajtigon, kiun vi kontrolas, rekonektiĝu kaj legu la basenan adreson, kiun la kliento ricevis. Tiu unu nombro apartigas asignadon de enkursigado. Poste ekzercu nomitan aplikaĵon, observu la revenan trafikon kaj provu celon, kiu devas resti malpermesita. Tri observoj, tri malsamaj fiaskaj manieroj.

Nomresolvo meritas sian propran teston: aliro per IP povas funkcii dum la DNS de la kliento ankoraŭ montras al resolvilo, kiun ĝi ne povas atingi. DNS-servilo en la LAN estas atingebla nur se la kliento havas itineron al ĝi kaj la servilo akceptas demandojn el la nova gamo. Ambaŭ estas oftaj mankoj, kiam la baseno translokiĝas.

Retiru malnovajn gamojn kaj iliajn esceptojn nur post kalkuli aktivajn seancojn kaj la prizorgan procezon. Konektita kliento kun nova adreso pruvas asignadon, ne la alirpolitikon. Tenu la malnovan gamon dokumentita ĝis la lasta seanco, kiu uzis ĝin, eksvalidiĝos.

Kontrolu la rezulton per tri observoj

Akcepto postulas tri faktojn: la kliento havas adreson el la nova baseno, gastiganto de LAN povas atingi ĝin kaj ricevi respondon, kaj malpermesita celo restas malpermesita. Ĉiu havas sian propran kontrolon, do fiasko montras al asignado, enkursigado aŭ politiko. Ekzekutu ilin laŭ tiu ordo.

De la kliento, konfirmu la adreson kaj la itineron al unu gastiganto de LAN:

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

De la gastiganto de LAN, konfirmu la respondan vojon kaj la politikon en unu paso. Se ping malsukcesas sed la aplikaĵo funkcias, la mankanta peco verŝajne estas regulo pri ICMP, ne la itinero. Se ambaŭ malsukcesas, legu la itineron sur la gastiganto antaŭ ol redakti la VPN. Notu la tri rezultojn en la ŝanĝbileto, por ke la sekva persono komencu de pruvoj.