તમારું VPN ટ્યુનલ સરનામું ઇનબાઉન્ડ પોર્ટ કેમ ખોલતું નથી
ટ્યુનલ સરનામું તમારા ક્લાયન્ટને એવા પીઅર્સ સમક્ષ ઓળખે છે જે તેના સુધી રૂટ કરી શકે, અને ક્યારેય શ્રોતા બનાવતું નથી. બાઇન્ડ, રિટર્ન રૂટ અને પછી પોલિસી તપાસો.
ઓફિસ VPN સાથે જોડાઓ, પોર્ટ 8443 પર નાની સેવા શરૂ કરો, ટ્યુનલ સરનામું સહકર્મીને મોકલો અને કનેક્શન નિષ્ફળ થતું જુઓ જ્યારે ક્લાયન્ટ હજી પણ જોડાયેલું હોવાનું જણાવે છે. ટ્યુનલમાં કંઈ તૂટ્યું નથી: સરનામું આપવામાં આવ્યું છે, સેશન ચાલુ છે, અને જવાબ લઈ જતા પેકેટ ક્યારેય સ્વીકારાતા નથી. નીચેની ત્રણ તપાસ ક્રમમાં કરો અને જે નિષ્ફળ જાય તેની પાસે થોભો, કારણ કે દરેકનો ઉપાય અલગ છે અને તેમાંથી ફક્ત એક જ VPN સાથે સંબંધિત છે.
સોકેટ ખરેખર ક્યાં બાઇન્ડ થયું છે તેનાથી શરૂ કરો
કંઈ પણ રૂટ થાય તે પહેલાં, કોઈએ એવા સરનામા પર સાંભળવું જોઈએ જ્યાં કૉલર પહોંચી શકે. ડેવલપમેન્ટ સર્વર સામાન્ય દોષિત છે, કારણ કે તેમાંથી ઘણા ડિફૉલ્ટ રૂપે loopback પર બાઇન્ડ થાય છે અને ફક્ત એ જ મશીન પરથી આવતા કનેક્શન સ્વીકારે છે. ટ્યુનલ સરનામું તે બાઇન્ડિંગ બદલતું નથી, અને ઓપરેટિંગ સિસ્ટમ VPN સંડોવાય તે પહેલાં ઘણું વહેલું કનેક્શન નકારી દેશે.
ss -ltnp | grep 8443
netstat -ano | findstr 8443સ્ટેટ નહીં, લોકલ એડ્રેસ કૉલમ વાંચો. 127.0.0.1:8443 એટલે ફક્ત loopback, અને ઉપાય 0.0.0.0 અથવા ટ્યુનલ સરનામા પર જ બાઇન્ડ કરવો છે. 0.0.0.0:8443 દરેક ઇન્ટરફેસ પર સ્વીકારે છે, જે મશીન પાસે પબ્લિક સરનામું પણ હોય ત્યારે મોટાભાગના લોકો ધારે છે તેના કરતાં વધુ વિશાળ છે; 10.64.7.15:8443 એ સાંકડી આવૃત્તિ છે જે ફક્ત ત્યાં જ સાંભળે છે જ્યાં સહકર્મી પહોંચી શકે. તે જ આઉટપુટમાં પ્રોસેસનું નામ પણ નોંધો, કારણ કે અગાઉની કસોટીનું ભૂલું પડેલું ઇન્સ્ટન્સ સામાન્ય કારણ છે કે પોર્ટ ખુલ્લું દેખાય અને ખોટા સામગ્રી સાથે જવાબ આપે.
પછી પૂછો કે કંઈ તે સરનામા સુધી રૂટ કરી શકે છે કે નહીં
ટ્યુનલ સરનામું ફક્ત એવા પીઅર્સ માટે અર્થપૂર્ણ છે જે તે પ્રીફિક્સ ટ્યુનલમાં મોકલવા માટે રૂપરેખાંકિત છે. સહકર્મીના મશીનનું પોતાનું ટેબલ છે, અને ટ્યુનલ સબનેટ માટે રૂટ ન હોય તો પેકેટ ડિફૉલ્ટ ગેટવે તરફ જાય છે અને એવી જગ્યાએ મરી જાય છે જેને સરનામાના અસ્તિત્વની કોઈ જાણ નથી. આ કૉલરની બાજુનો રૂટિંગ પ્રશ્ન છે, તમારી બાજુની પરવાનગી નહીં.
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
બે ક્લાયન્ટ વચ્ચેનું સર્વર પણ એટલું જ મહત્ત્વનું છે. સામાન્ય રિમોટ-એક્સેસ ડિઝાઇનમાં દરેક ક્લાયન્ટ ગેટવે તરફ આઉટબાઉન્ડ કનેક્શન ખોલે છે અને ગેટવે તે ફ્લોનું સ્ટેટ રાખે છે, તેથી જવાબો એવા માર્ગે પાછા આવે છે જે તે પહેલેથી જાણે છે. એક ક્લાયન્ટથી બીજા ક્લાયન્ટ સુધીનું કનેક્શન નવો ફ્લો છે જે ગેટવેએ સ્વીકારીને ફોરવર્ડ કરવો પડે, અને ઘણા ડિપ્લોયમેન્ટ ક્લાયન્ટને એકબીજાથી અલગ રાખવા માટે તેને જાણી જોઈને બંધ રાખે છે. કન્ઝ્યુમર VPN સેવાઓ સામાન્ય રીતે ડિફૉલ્ટ રૂપે અલગ રાખે છે; કોર્પોરેટ ગેટવે ક્યારેક જૂથ પ્રમાણે મંજૂરી આપે છે.
હોસ્ટ પર કંઈ પણ બદલતા પહેલાં દિશા તપાસો. જો ટ્યુનલ સરનામું ગેટવે પોતે જવાબ આપે પણ પીઅરથી નહીં, તો ગેટવેનું ક્લાયન્ટ-થી-ક્લાયન્ટ સેટિંગ જ ફરક છે, અને લોકલ ફાયરવોલના કોઈ પણ ફેરફાર તેનો વિકલ્પ બની શકતા નથી.
છેલ્લે, જે પોલિસી ફ્લોને મંજૂરી આપે છે તે શોધો
રૂટ થયેલા પેકેટ અને જવાબ આપતી સેવા વચ્ચે પોલિસીના ત્રણ સ્તર છે: VPN સર્વરનો ફોરવર્ડિંગ નિર્ણય, હોસ્ટ ફાયરવોલ, અને ઇન્સ્ટન્સની સામેનું કોઈ પણ ક્લાઉડ સિક્યોરિટી ગ્રુપ. ત્રણેયે સહમત થવું પડે, અને તે જુદી જુદી રીતે નિષ્ફળ જાય છે, તેથી ઉપરના ટેબલનું લક્ષણ બ્રાઉઝરની ભૂલ સંદેશ કરતાં વધુ ઉપયોગી છે.
સફળ બાઇન્ડ પછી લોકો જે સ્તર ભૂલી જાય છે તે હોસ્ટ ફાયરવોલ છે, કારણ કે LAN ઇન્ટરફેસ પર પોર્ટને મંજૂરી આપતો નિયમ તેને ટ્યુનલ ઇન્ટરફેસ પર આપોઆપ મંજૂરી આપતો નથી. ઇન્ટરફેસ-મર્યાદિત નિયમો સાચી ડિઝાઇન છે અને તે જ ઓફિસથી કામ કરતી પણ ઘરથી ન કરતી સેવાનું સામાન્ય કારણ છે. નિયમનો પોર્ટ નંબર નહીં, તેનો વ્યાપ વાંચો.
સ્ટેટફુલ ફિલ્ટરિંગ વિરુદ્ધ કિસ્સો સમજાવે છે. તમારા લેપટોપથી આઉટબાઉન્ડ કનેક્શન સ્ટેટ બનાવે છે, અને તેના જવાબો ઇનબાઉન્ડ નિયમ વિના સ્વીકારાય છે. સહકર્મીનું કનેક્શન સાવ નવો ફ્લો છે જેની પાછળ કોઈ સ્ટેટ નથી, તેથી તેને સ્પષ્ટ મંજૂરીની જરૂર છે. આ અસમાનતા એ જ કારણ છે કે તમારા પોતાના મશીન પર ચાલતું બ્રાઉઝર સેશન સેવા બહારથી પહોંચી શકાય છે કે નહીં તે વિશે કંઈ કહેતું નથી.
એક તપાસ નિષ્ફળ જાય ત્યારે ટ્યુનલ નહીં, ડિઝાઇન બદલો
જો જરૂરિયાત એ હોય કે સહકર્મી તમારી લોકલ સેવા ખોલે, તો પ્રામાણિક જવાબ સામાન્ય રીતે ઇનબાઉન્ડ એક્સેસ માટે બનાવેલી કોઈ પદ્ધતિ હોય છે. રિવર્સ SSH ટ્યુનલ સૌથી નાનું છે: તમારું મશીન બહારની તરફ એવા હોસ્ટ સાથે જોડાય છે જ્યાં સહકર્મી પહેલેથી પહોંચી શકે છે, અને શ્રોતા તે હોસ્ટ પર જ હોય છે.
ssh -N -R 8443:127.0.0.1:8443 [email protected]રિલેને તેની SSH સર્વર ગોઠવણીમાં GatewayPorts clientspecified ની જરૂર છે, નહીં તો ફોરવર્ડ કરેલો શ્રોતા રિલે પર loopback સાથે બંધાય છે અને સહકર્મી પહેલાં જેવો જ અસ્વીકાર અનુભવે છે. એક બપોર કરતાં વધુ ટકે તેવી કોઈ પણ વસ્તુ માટે હેલ્થ ચેક અને પ્રકાશિત નામ માટે પ્રમાણપત્ર સાથેનું લોડ બેલેન્સર કે ingress વધુ સારું સાધન છે, અને બે નેટવર્કે ખરેખર વાત કરવી હોય ત્યારે બંને સબનેટ માટે રૂટ સાથેનું સાઇટ-ટુ-સાઇટ ટ્યુનલ સાચો જવાબ છે.
આમાંથી દરેક ડિઝાઇન એક્સપોઝરને સ્પષ્ટ કરે છે, અને તે જ મુદ્દો છે. VPN પેકેટને એવા નેટવર્ક વચ્ચે ખસેડે છે જેનો ઉપયોગ કરવાની અનુમતિ તમને પહેલેથી હતી; તે સેવા પ્રકાશિત કરતું નથી અને લેપટોપને ઇન્ટરનેટ તરફના હોસ્ટમાં ફેરવતું નથી. ત્રણ સ્તરોમાંથી કયું બદલવું તે નક્કી કરવું એ કામ છે, અને ટ્યુનલ તેમાંથી ભાગ્યે જ એક હોય છે.