RRAS ના VPN ક્લાયન્ટને પોતાનું IPv4 પૂલ અને પાછા જવાનો રસ્તો જોઈએ

VPN ક્લાયન્ટ જોડાય છે અને સરનામું મેળવે છે, પણ તેને જરૂરી LAN યજમાન હજી પણ તેને જવાબ આપી શકતું નથી. Windows Routing and Remote Access માં VPN ક્લાયન્ટ માટે આંતરિક સરનામું સર્વરના LAN એડેપ્ટરથી અલગ ગોઠવાયેલા પૂલમાંથી આવે છે, અને LAN બાજુને તે પૂલ તરફ પરત માર્ગની જરૂર છે. બે પરિવર્તન, એક નહીં, અને તે અલગ અલગ રીતે નિષ્ફળ જાય છે. તેમને ક્રમમાં કરો જેથી જૂની રેન્જ પાછી ખેંચતા પહેલાં સરનામાંની યોજના અને પરત માર્ગ સાબિત થાય.

કન્સોલ ખોલતા પહેલાં રેન્જ આરક્ષિત કરો

એવો પ્રિફિક્સ પસંદ કરો જે LAN, બીજી VPN રેન્જ કે સાઇટમાં રાઉટ થતી કોઈપણ વસ્તુ સાથે ઓવરલેપ ન થાય. પરીક્ષણ માટે /24 અનુકૂળ કદ છે, અને પહેલો વપરાયોગ્ય ભાગ ક્લાયન્ટને આપી શકાય જ્યારે બાકીનો વૃદ્ધિ માટે મુક્ત રહે. કન્સોલમાં લખતા પહેલાં તેને તેના હેતુ અને માલિક સાથે નોંધો. બ્લોકના બંને છેડે જગ્યા રાખો જેથી પછીની વિભાજન ફરીથી નંબર આપવાની ફરજ ન પાડે.

ફક્ત કન્સોલમાં જીવતી સરનામાંની યોજના એક પુનર્નિર્માણ અંતરે અથડામણથી હોય છે. તે વધવાની પ્રવૃત્તિ પણ ધરાવે છે: કોઈ પછી બીજી રેન્જ ઉમેરે છે અને કોઈ પહેલી ચકાસતું નથી. યોજના સર્વર દસ્તાવેજીકરણની બાજુમાં રાખો, ચેટ થ્રેડમાં નહીં.

સર્વરનું LAN એડેપ્ટર આ પૂલ નક્કી કરતું નથી. જાહેર શ્રોતા બદલવો કે LAN માં એડેપ્ટર ઉમેરવો સાવ બીજું કંઈક કરે છે. એટલે ક્લાયન્ટ જોડાઈ શકે અને તોપણ ખોટી જગ્યાએથી સરનામું મેળવે. પૂલ સર્વરના IPv4 ગુણધર્મોમાં રહે છે, એડેપ્ટર યાદીમાં નહીં.

પદ્ધતિ બદલવી એ રેન્જ ઉમેરવી નથી

RRAS માં એક સોંપણી પદ્ધતિ અને રેન્જનો સમૂહ છે. DHCP થી સ્થિર પૂલ તરફ જવું એ પદ્ધતિ પરિવર્તન છે. સ્થિર પૂલ પહેલેથી સક્રિય હોય ત્યારે બીજો બ્લોક ઉમેરવો એ રેન્જ પરિવર્તન છે.

કોઈપણ એક ચલાવતા પહેલાં બંને ક્રિયાઓનું પૂર્વદર્શન કરો, અને સર્વરની વર્તમાન સ્થિતિ સાથે કઈ મેળ ખાય તે વાંચો:

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

જો સર્વર હજી DHCP સોંપણી પર હોય તો બીજું cmdlet નિષ્ફળ જાય છે અથવા નકામું પૂલ બનાવે છે. પહેલું હાલના પૂલને વિસ્તારવાને બદલે પદ્ધતિ બદલે છે. કોઈ પણ પૂર્વદર્શન કંઈ લાગુ કરતું નથી, તેથી જે મેળ ખાય તે ચલાવો, પછી કન્સોલમાં પરિણામી પૂલની પુષ્ટિ કરો. સર્વર કઈ સ્થિતિમાં છે તેની ખાતરી ન હોય તો IPv4 ગુણધર્મ પૃષ્ઠ પર સોંપણી પદ્ધતિ વાંચો અને ગોઠવાયેલી રેન્જની યાદી કરો:

Get-VpnIPAddressRange

ખાલી રેન્જ યાદી સાથેની DHCP પદ્ધતિ એટલે પહેલું પૂર્વદર્શન લાગુ પડે. હાલની રેન્જ સાથેનું સ્થિર સરનામા પૂલ એટલે બીજું લાગુ પડે.

સેટિંગને જરૂરી હોઈ શકે તેવા સેવા પુનઃપ્રારંભનો હિસાબ રાખો, અને જોડાયેલા ક્લાયન્ટ તરત જ ફરી નંબર પામે તેવું ધારશો નહીં. જે ક્લાયન્ટ ફરી જોડાય ત્યાં સુધી જૂનું સરનામું રાખે છે તે સામાન્ય રીતે વર્તે છે. જ્યાં ફરી જોડાવું સ્વીકાર્ય હોય એવી વિન્ડો માટે પરિવર્તનનું આયોજન કરો.

LAN ને પરત માર્ગની જરૂર છે

ધારો કે LAN 10.60.0.0/24 છે અને RRAS સર્વર તેના પર 10.60.0.10 છે. તે LAN નું જે યજમાન 10.250.50.0/24 માંના ક્લાયન્ટને જવાબ આપે છે તેને RRAS સર્વર દ્વારા પૂલ સુધીનો રસ્તો જોઈએ. એ રસ્તા વિના વિનંતી પહોંચે છે અને જવાબ મરી જાય છે.

જો યજમાનનું મૂળભૂત ગેટવે બીજું રાઉટર હોય તો તે રાઉટરને VPN પ્રિફિક્સ માટે પરત માર્ગ જોઈએ. RRAS સર્વર પરનો સ્થિર માર્ગ અહીં મદદ કરતો નથી; પરત માર્ગ એ ઉપકરણ પર હોવો જોઈએ જે LAN ગેટવે ધરાવે છે, તેથી તેને રાઉટિંગ કોષ્ટકમાં કે ગતિશીલ રાઉટિંગ પ્રક્રિયામાં ઉમેરો, સાઇટ જે વાપરે તે મુજબ.

નવી સ્રોત રેન્જ સામે યજમાનનું ફાયરવોલ અને કોઈપણ નેટવર્ક ઍક્સેસ નિયમો પણ ચકાસો. જૂની ક્લાયન્ટ રેન્જ માટે લખાયેલા નિયમો નવીને નકારે છે, ભલે સોંપણી સફળ થઈ હોય. LAN તરફ ક્લાયન્ટના માર્ગ અને DNS ઉકેલ એ અલગ જરૂરિયાતો છે, અને ટનલ સ્વસ્થ દેખાય ત્યારે બંને નિષ્ફળ જઈ શકે. દરેકને અલગ ચકાસો.

જૂનું પાછું ખેંચતા પહેલાં એક ઉપકરણ પર નવું પૂલ સાબિત કરો

તમે નિયંત્રિત કરો છો એવું એક અધિકૃતિ લો, ફરી જોડાઓ અને ક્લાયન્ટને મળેલું પૂલ સરનામું વાંચો. એ એક જ સંખ્યા ફાળવણીને રાઉટિંગથી અલગ પાડે છે. પછી નામવાળી એપ્લિકેશન ચલાવો, પરત ટ્રાફિક જુઓ અને એવું લક્ષ્ય અજમાવો જે નકારાયેલું જ રહેવું જોઈએ. ત્રણ નિરીક્ષણ, ત્રણ અલગ નિષ્ફળતાની રીતો.

નામ ઉકેલ પોતાનું પરીક્ષણ લાયક છે: IP દ્વારા ઍક્સેસ કામ કરી શકે જ્યારે ક્લાયન્ટનું DNS હજી એવા રિઝોલ્વર તરફ ઇશારો કરે જ્યાં તે પહોંચી શકતું નથી. LAN પરનું DNS સર્વર ત્યારે જ પહોંચી શકાય જ્યારે ક્લાયન્ટનો ત્યાં માર્ગ હોય અને સર્વર નવી રેન્જમાંથી પ્રશ્નો સ્વીકારે. પૂલ ખસે ત્યારે બંને સામાન્ય ચૂક છે.

સક્રિય સત્રો અને જાળવણી પ્રક્રિયાનો હિસાબ કર્યા પછી જ જૂની રેન્જ અને તેના અપવાદો પાછા ખેંચો. નવા સરનામા સાથેનો જોડાયેલો ક્લાયન્ટ ફાળવણી સાબિત કરે છે, ઍક્સેસ નીતિ નહીં. જૂની રેન્જનો ઉપયોગ કરનારું છેલ્લું સત્ર પૂરું થાય ત્યાં સુધી તેને દસ્તાવેજીકૃત રાખો.

ત્રણ નિરીક્ષણથી પરિણામ ચકાસો

સ્વીકૃતિ માટે ત્રણ તથ્ય જરૂરી છે: ક્લાયન્ટ પાસે નવા પૂલનું સરનામું છે, LAN યજમાન તેને પહોંચીને જવાબ મેળવી શકે છે, અને નકારાયેલું લક્ષ્ય હજી નકારાયેલું છે. દરેકની પોતાની ચકાસણી છે, તેથી નિષ્ફળતા ફાળવણી, રાઉટિંગ કે નીતિ તરફ ઇશારો કરે છે. તેમને એ ક્રમમાં ચલાવો.

ક્લાયન્ટથી, સરનામું અને એક LAN યજમાન સુધીનો માર્ગ ખાતરી કરો:

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

LAN યજમાનથી, એક જ પાસમાં પરત માર્ગ અને નીતિની ખાતરી કરો. જો પિંગ નિષ્ફળ જાય પણ એપ્લિકેશન કામ કરે, તો ખૂટતો ટુકડો સંભવતઃ ICMP નિયમ છે, માર્ગ નહીં. જો બંને નિષ્ફળ જાય, તો VPN સંપાદિત કરતા પહેલાં યજમાન પરનો માર્ગ વાંચો. ત્રણેય પરિણામ પરિવર્તન ટિકિટમાં નોંધો જેથી આગલી વ્યક્તિ પુરાવાથી શરૂ કરે.