Windows VPN ના સરનામા ક્ષેત્રમાં પોર્ટ ફક્ત SSTP સાથે કામ કરે છે

સર્વર નામ ક્ષેત્ર host:port નથી. PPTP, L2TP અને IKEv2 પાસે સ્થિર પોર્ટ છે; SSTP પોર્ટને ફક્ત સંપૂર્ણ https:// URL તરીકે સ્વીકારે છે, અને 443 આગળ મોકલવું વધુ સ્વચ્છ છે.

એક VPN સર્વર TCP 10443 પર જવાબ આપે છે, Windows ના અંતર્ગત ક્લાયન્ટ પાસે યોગ્ય ઓળખપત્રો છે, અને તેમ છતાં કનેક્શન DNS ટાઇમઆઉટ જેવા વિરામ પછી તૂટી જાય છે. કારણ સામાન્ય રીતે સરનામા ક્ષેત્ર છે: સર્વર નામ અથવા સરનામામાં vpn.example.com:10443 લખવાથી Windows આખી શબ્દમાળાને હોસ્ટનામ તરીકે વાંચે છે, કારણ કે તે બોક્સ સામાન્ય host:port ઇનપુટ નથી. પોર્ટ ત્યાં વ્યક્ત થઈ શકે છે કે નહીં તે પ્રોફાઇલ વાપરતા ટનલ પ્રકાર પર આધાર રાખે છે, અને ચારમાંથી ફક્ત એક જ પ્રકાર મૂલ્યને એવી વસ્તુ તરીકે ગણે છે જે તે પાર્સ કરી શકે.

સરનામા ક્ષેત્ર host:port બોક્સ કેમ નથી

તે ક્ષેત્ર પાછળની પ્રોફાઇલ પ્રોપર્ટી ServerAddress છે, અને દરેક ટનલ પ્રકાર શબ્દમાળા સાથે શું કરવું તે જાતે નક્કી કરે છે. તેમાંથી ત્રણ પાસે ભરવા માટે પોર્ટ પેરામીટર નથી, તેથી કોલન અને સંખ્યા ફક્ત એવા નામના અક્ષરો છે જે કદી ઉકેલાશે નહીં. ચોથો HTTPS પર ચાલે છે, જ્યાં પોર્ટ URL નો ભાગ છે, તેથી મૂલ્ય URL તરીકે પાર્સ થતા સ્વરૂપમાં લખવું પડે.

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

સ્થિર પોર્ટવાળા ત્રણ પ્રકાર

PPTP TCP 1723 સાથે જોડાય છે અને પછી ટનલને GRE, IP પ્રોટોકોલ 47 માં લઈ જાય છે. L2TP/IPsec ટનલ માટે UDP 1701 અને IPsec માટે UDP 500 તેમજ 4500 વાપરે છે, જેમાં 4500 NAT પસાર કરવાનો પોર્ટ છે. IKEv2 પણ UDP 500 અને 4500 વાપરે છે. આમાંથી કોઈ પણ પ્રોફાઇલ ઇન્ટરફેસમાં ક્યાંય પોર્ટ ક્ષેત્ર દર્શાવતું નથી, અને કોઈ પણ બિન-માનક પોર્ટ પર વાટાઘાટ કરશે નહીં.

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

SSTP ને URL જોઈએ, નામ નહીં

SSTP અપવાદ છે કારણ કે તે TLS સત્રની અંદર ચાલે છે. ક્ષેત્ર URL તરીકે પાર્સ થવું જોઈએ: પહેલા https:// સ્કીમ, પછી હોસ્ટ, પછી કોલન અને પોર્ટ. સ્કીમ વગર Windows મૂલ્યને સાદા નામ તરીકે જ ગણે છે અને કોઈ પણ TLS આદાનપ્રદાન પહેલાં કનેક્શન નિષ્ફળ જાય છે.

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

Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType

ServerAddress ચોક્કસ શું સાચવવામાં આવ્યું તે બતાવે છે. જો તે કોલનવાળું નગ્ન હોસ્ટનામ તરીકે વંચાય, તો પ્રોફાઇલને કદી URL મળ્યું નથી અને ગમે તેટલી વાર ફરી પ્રયાસ કરવાથી આ સુધરશે નહીં.

તે જ બોક્સમાં ચોંટાડાતું વેન્ડર સિન્ટેક્સ

કેટલાક ગેટવે તે ક્ષેત્ર માટે વધારાની પરંપરાઓનું દસ્તાવેજીકરણ કરે છે, જેમ કે પોર્ટ પછી ઉમેરાતું realm અથવા પ્રમાણપત્રોનું વર્તન બદલતા ક્વેરી પેરામીટર. તેમને તે વેન્ડરનું સર્વર સમજે છે અને કેટલાક બિલ્ડમાં તેનું પોતાનું ક્લાયન્ટ પણ. તે Windows પ્રોફાઇલ ફોર્મેટનો ભાગ નથી, અને તેમને અંતર્ગત પ્રોફાઇલમાં ચોંટાડવાથી સામાન્ય રીતે એ જ મૌન નામ-નિષ્ફળતા થાય છે.

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

પોર્ટ સાબિત કરો, પછી નિષ્ફળ તબક્કો વાંચો

પ્રોફાઇલને દોષ આપતા પહેલાં ખાતરી કરો કે ક્લાયન્ટના નેટવર્કથી કંઈક તે પોર્ટ પર TCP સ્વીકારે છે:

Test-NetConnection vpn.example.com -Port 10443

સફળતા શ્રોતાને સાબિત કરે છે, SSTP ને નહીં. વેબ સર્વર, રિવર્સ પ્રોક્સી અથવા લોડ બેલેન્સર TCP હેન્ડશેક પૂરો કરી શકે છે અને તો પણ SSTP બોલી શકતા નથી, તેથી લીલી કસોટી અને લાલ VPN વાસ્તવિક સંયોજન છે. પ્રમાણપત્રનો વિષય પ્રોફાઇલના નામ સાથે સરખાવો, અને જે બિલ્ડમાં તે સમાવિષ્ટ છે તેમાં RasClient લોગ તપાસો, કારણ કે તે સામાન્ય ટાઇમઆઉટને બદલે નિષ્ફળ થયેલો તબક્કો નોંધે છે.

પછી તે વિકલ્પ ધ્યાનમાં લો જે સમસ્યાને દસ્તાવેજ કરવાને બદલે દૂર કરે છે: બહારથી TCP 443 ને VPN સર્વર પર 10443 તરફ મોકલો. પછી ક્લાયન્ટ કોઈ પણ પોર્ટ વગરનું ડિફોલ્ટ પ્રોફાઇલ વાપરે છે, જે સામાન્ય રીતે સંચાલિત કાફલા માટે સૌથી સ્વચ્છ ગોઠવણી છે અને કસ્ટમ પોર્ટને આંતરિક વિગત બનાવી રાખે છે.

સંબંધિત લેખો