Windows VPN પર ઇન્ટરનેટ નથી? સરનામાં પૂલ શંકાસ્પદ છે

Windows ટનલને કનેક્ટેડ બતાવે છે અને તેને ઇન્ટરનેટ એક્સેસ નથી એવું લેબલ આપે છે, જેને લોકો Windows ની વિચિત્રતા તરીકે વાંચે છે. તે ક્લાયન્ટને શું મળ્યું તેનું નિવેદન છે: કોઈ વપરાયોગ્ય ડિફોલ્ટ ગેટવે નહીં, કોઈ કાર્યરત રિઝોલ્વર નહીં, અથવા ટનલની અંદરના સરનામાંઓ માટે પાછા જવાનો કોઈ રસ્તો નહીં. જ્યારે સર્વર Windows Incoming Connection હોય, ત્યારે એક જ સેટિંગ આવા મોટાભાગના રિપોર્ટ સમજાવે છે. લેબલ નિદાન નથી, પરંતુ તે શોધને ત્રણ જગ્યાઓ સુધી મર્યાદિત કરે છે.

બદલતા પહેલા લીઝ વાંચો

ક્લાયન્ટ પર ipconfig /all ચલાવો અને એન્ટ્રીઓમાંથી VPN એડેપ્ટર શોધો. તે જે સરનામું, ડિફોલ્ટ ગેટવે અને DNS સર્વર સૂચિબદ્ધ કરે છે તે તમને જોઈતી હકીકતો છે, અને તે ઘણી વાર એડમિનિસ્ટ્રેટર ધારે છે તેના કરતાં અલગ હોય છે.

ત્રણ પેટર્ન ત્રણ ખામીને અનુરૂપ છે. 169.254.0.0/16 માં સરનામું એટલે ક્લાયન્ટને કંઈ જ મળ્યું નહીં અને તેણે પોતાને લિંક-લોકલ સરનામું આપ્યું. ગેટવે વગરનું વિશ્વસનીય સરનામું એટલે પૂલ એ વિકલ્પ વગર પરોવાયો જે ક્લાયન્ટને ડિફોલ્ટ રૂટ આપે છે. પૂર્ણ લીઝ જે હજી કંઈ સુધી પહોંચતી નથી તે સર્વર તરફના ફોર્વર્ડિંગ અથવા ટ્રાન્સલેશન તરફ ઇશારો કરે છે.

સર્વરને સ્પર્શ કરતા પહેલા મૂલ્યો લખી લો. આગળનું પગલું તેમને સર્વર માને છે તે શ્રેણી સાથે સરખાવે છે, અને સ્મૃતિ લીઝનો નબળો વિકલ્પ છે.

આપમેળે સોંપણી કેમ ગેટવે વગર છોડી શકે છે

Incoming Connections એન્ટ્રીના પોતાના IPv4 ગુણધર્મો હોય છે, જે ભૌતિક એડેપ્ટરથી અલગ હોય છે. ત્યાંનું ડિફોલ્ટ આપમેળે સરનામાં સોંપવાનું ઓફર કરે છે, જે સરનામું, માસ્ક, ગેટવે અને DNS પૂરા પાડવા માટે કનેક્શનના અંતર્ગત ફાળવણીકર્તા પર આધાર રાખે છે.

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

તેથી જ નિર્દિષ્ટ શ્રેણીમાં સ્વિચ કરવાથી આમાંથી ઘણા રિપોર્ટ ઠીક થાય છે. તમે એવી સેવાને લીઝ શોધવાનું કહેવાનું બંધ કરો છો જે કદાચ ચાલતી ન હોય, અને જાતે લીઝ જણાવવાનું શરૂ કરો છો.

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

સ્પષ્ટ શ્રેણી સેટ કરો જે સર્વર રૂટ કરી શકે

સર્વર પહોંચી શકે તેવા સબનેટની અંદર નાનું બ્લોક પસંદ કરો, LAN રાઉટર આપે છે તે શ્રેણીની બહાર અને નેટવર્ક પરના અન્ય કોઈપણ પૂલની બહાર. જો સર્વર 172.20.10.0/24 પર હોય અને રાઉટર પાસે 172.20.10.1 હોય, તો તે સબનેટની ટોચ પાસેનું ટૂંકું બ્લોક, કહો 172.20.10.201 થી 172.20.10.209, ટનલ લીઝને રાઉટર પહેલેથી સંભાળે છે તે વિતરણથી દૂર રાખે છે.

તેને Incoming Connection ના IPv4 ગુણધર્મોમાં દાખલ કરો, ક્લાયન્ટ ફરી કનેક્ટ કરો, અને બીજું કંઈ બદલતા પહેલા એડેપ્ટર ફરી વાંચો. બીજું વાંચન એ છે જે તમને કહે છે કે પૂલ ખામી હતી કે ફક્ત ઘણીમાંની એક ખામી.

આ આદેશો પરિણામી રૂપરેખાંકન અને ક્લાયન્ટ પાસે હવે જે રૂટ છે તે છાપે છે:

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

લીઝમાંનું ગેટવે એ સરનામું હોવું જોઈએ જે સર્વર ધરાવે છે, અને ક્લાયન્ટનો ડિફોલ્ટ રૂટ તે તરફ ઇશારો કરવો જોઈએ. જો લીઝ પૂર્ણ છે પણ કોઈ રૂટ અસ્તિત્વમાં નથી, તો સર્વરે ગેટવે દબાણ કર્યા વિના સોંપ્યું છે, અને પૂલ સેટિંગ્સ હજી પણ જોવાની જગ્યા છે.

સરનામું ઇન્ટરનેટનો રસ્તો નથી

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

Internet Connection Sharing એ શોર્ટકટ છે. તે ઇન્ટરનેટ તરફના એડેપ્ટરને શેર કરેલા ગેટવેમાં ફેરવે છે અને પોતાનું સરનામાંકન ચલાવે છે, જે તે એડેપ્ટરનું સરનામું ફરીથી લખી શકે છે અને હાલના NAT નિયમને એવા મૂલ્ય તરફ ઇશારો કરતો મૂકી શકે છે જે હવે અસ્તિત્વમાં નથી. સક્ષમ કરતા પહેલા મૂળ સેટિંગ્સ નોંધો.

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

પહેલા બહારનો રસ્તો બાકાત કરો

જો ટનલ ક્યારેય ન બને તો કોઈ પૂલ મદદ કરી શકતું નથી. પ્રોટોકોલ નક્કી કરે છે કે રસ્તાએ શું વહન કરવું જોઈએ: PPTP ને TCP 1723 અને GRE જોઈએ છે, જે પોર્ટ નહીં પરંતુ IP પ્રોટોકોલ 47 છે; L2TP/IPsec ને UDP 1701 ઉપરાંત 500 અને 4500 જોઈએ છે; SSTP ને TCP 443 જોઈએ છે.

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

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