હેરપિન NAT: અંદરથી VPN એન્ડપોઇન્ટ કેમ નિષ્ફળ જાય છે
જાહેર સરનામું વાપરતો સ્થાનિક ક્લાયન્ટ LAN છોડીને ફરી અંદર આવે છે. જ્યારે રાઉટર હેરપિન કરતું નથી, ત્યારે બહાર કામ કરે છે અને અંદર નહીં.
મોબાઇલ નેટવર્કથી જવાબ આપતો પણ સોફા પરથી નિષ્ફળ જતો VPN સર્વર સામાન્ય રીતે પ્રમાણપત્રની સમસ્યા નથી. LAN ની અંદરનો ક્લાયન્ટ રાઉટરને એવું પેકેટ અનુવાદિત કરવા કહે છે જેનું લક્ષ્ય રાઉટરનું પોતાનું જાહેર સરનામું છે, એટલે પેકેટે બહાર જઈને તરત જ પાછું આવવું પડે. આ દાવને હેરપિનિંગ કહે છે, અને ઘણાં રાઉટર કાં તો તેને લાગુ જ કરતાં નથી કાં તો ફક્ત ચેકબોક્સ ચાલુ હોય ત્યારે કરે છે. બહારની કસોટી પાસ થવી એ જ વસ્તુને ગૂંચવણભરી બનાવે છે, કારણ કે તે સાબિત કરે છે કે શ્રોતા અને ફોરવર્ડિંગ નિયમ ઠીક છે.
પેકેટ બહાર જાય છે અને પાછું અંદર આવે છે
પેકેટને અનુસરો. ક્લાયન્ટ જાહેર નામ ઉકેલે છે, જાહેર સરનામા સાથે જોડાય છે, અને રાઉટરનું લક્ષ્ય NAT લક્ષ્યને આંતરિક સર્વર તરફ ફરી લખે છે. સર્વરનો જવાબ ક્લાયન્ટના LAN સરનામા પર સંબોધાયેલો છે, તેથી તે રાઉટરના LAN ઇન્ટરફેસ દ્વારા પાછો જાય છે, તે NAT નિયમમાંથી ક્યારેય પસાર થયા વિના જે સ્રોતને પાછો અનુવાદિત કર્યો હોત.
હવે ક્લાયન્ટને એવા સરનામેથી પેકેટ મળે છે જ્યાં તેણે ક્યારેય કંઈ મોકલ્યું નથી, અને તેને ફેંકી દે છે. એ અસમપ્રમતા જ આખી ખામી છે.
RFC 4787 આ કિસ્સામાં NAT પાસેથી અપેક્ષિત વર્તનનું વર્ણન કરે છે, અને ટૂંકો સાર એ છે કે વ્યવહારમાં તે વૈકલ્પિક છે, જ્યાં સિદ્ધાંતમાં નિર્દિષ્ટ હોય ત્યાં પણ. કેટલાંક રાઉટર આ સેટિંગને NAT loopback કહે છે, અન્ય હેરપિન NAT અથવા NAT reflection કહે છે, અને કેટલાંક કંઈ જ દર્શાવતાં નથી. જે રાઉટરમાં તે નથી તે ખોટું રૂપરેખાંકિત નથી; તે સામાન્ય કામ કરે છે, અને ઉપાય બીજે ક્યાંક આવે છે. સ્થાનિક કસોટી નિષ્ફળ ગઈ એટલે જાહેર ફોરવર્ડિંગ નિયમ ખોટો છે એવું તારણ ન કાઢો.
તપાસ 1: બે માર્ગ અલગ અલગ ચકાસો
LAN ની બહારથી, સાચો વપરાશકર્તા વાપરે તે જ પ્રોફાઇલ સાથે જોડાઓ અને સત્ર સ્થપાય છે તેની ખાતરી કરો. અંદરથી, તે જ પ્રોફાઇલ સાથે જાહેર સરનામે જોડાઓ અને ચોક્કસ ભૂલ તથા સમય નોંધો.
ચોક્કસ સ્થાનિક કસોટી યજમાનનામ રાખે છે અને ફક્ત સરનામું બદલે છે: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ વિનંતીને જાહેર સરનામે મોકલે છે અને સાથે સાચું સર્વર નામ રજૂ કરે છે. આ નામ-ઉકેલની સમસ્યાને અનુવાદની સમસ્યાથી અલગ પાડે છે, જે એક જ નામ કેફેથી કામ કરે ત્યારે સરળતાથી ગૂંચવાઈ જાય છે. નોંધો કે ક્લાયન્ટ TCP જોડાણમાં નિષ્ફળ જાય છે કે પછી TLS માં, કારણ કે પ્રથમ અનુવાદ તરફ અને બીજું ઓળખ તરફ ઇશારો કરે છે.
તપાસ 2: સર્વર શું જુએ છે તે વાંચો
સૌથી ઉપયોગી નિરીક્ષણ સર્વરનું દૃશ્ય છે. VPN યજમાન પર ક્લાયન્ટના LAN સરનામા અને રાઉટરના LAN સરનામા પર ગાળેલ કેપ્ચર ચલાવો, પછી સ્થાનિક પ્રયાસનું પુનરાવર્તન કરો. જો કંઈ ન આવે, તો પેકેટ અનુવાદમાંથી બચ્યું નથી.
જો જોડાણ ક્લાયન્ટના સરનામાને બદલે રાઉટરના LAN સરનામેથી આવે, તો હેરપિનિંગ થઈ રહ્યું છે અને સ્રોત ફરી લખાયો છે. આ કાર્યકારી રૂપરેખાંકન છે, ખામી નથી.
તપાસ 3: બહારના માર્ગને અડ્યા વિના સુધારો
ત્રણ સમર્થિત સ્વરૂપો છે, અસરના વ્યાસના વધતા ક્રમમાં. સૌથી સાંકડું છે વિભાજિત DNS: આંતરિક રેકોર્ડ પ્રકાશિત કરો જેથી એ જ સર્વર નામ LAN ના ક્લાયન્ટ માટે આંતરિક સરનામે ઉકેલાય, જે જાહેર માર્ગને સંપૂર્ણપણે ટાળે છે. પછીનું છે રાઉટરનું દસ્તાવેજીકૃત loopback અથવા reflection વિકલ્પ ચાલુ કરવો, જો હોય તો, અને તેને ફક્ત આ સેવા પર લાગુ કરવો. સૌથી પહોળું છે રાઉટર પર source-NAT નિયમ જે LAN માંથી આવતા ટ્રાફિકને સર્વર તરફ ફરી લખે છે જેથી જવાબ રાઉટર દ્વારા પાછો આવે; Linux રાઉટર પર તે સર્વરના સરનામા અને પોર્ટ સાથે મેળ ખાતો MASQUERADE નિયમ POSTROUTING છે. ત્રણેય બાહ્ય માર્ગને અસ્પૃશ્ય રાખે છે, અને એ જ ગુણધર્મ જાળવવાનો છે.
સ્થાનિક માર્ગને બાહ્ય જેવો બનાવવા અસંબંધિત પોર્ટ ફોરવર્ડિંગ પહોળું ન કરો, અને સમસ્યા ટાળવા સેવાને બીજા પોર્ટ પર ન ખસેડો. બંને ફેરફારો બહારની દુનિયા શું પહોંચી શકે તે બદલે છે, ફક્ત અંદરની દુનિયા જે જુએ છે તેને સુધારવા માટે.
વિભાજિત DNS માં એક જાળ છે જેનો ઉલ્લેખ કરવા જેવો છે. યજમાનનામને મનસ્વી IP સાથે બદલવાથી ક્લાયન્ટ શું માન્ય કરે છે તે બદલાય છે, તેથી આંતરિક રેકોર્ડ હજી પણ પ્રમાણપત્રના નામ સાથે મેળ ખાવો જોઈએ.
તપાસ 4: પછી બંને માર્ગ ચકાસો
LAN ની બહારથી બાહ્ય પ્રયાસનું પુનરાવર્તન કરો, તે જ પ્રોફાઇલ સાથે આંતરિક પ્રયાસનું પુનરાવર્તન કરો, અને ખાતરી કરો કે સર્વર લોગ એક સફળતા અને એક મૌનને બદલે બે અલગ સફળ સત્રો દર્શાવે છે. પછી તપાસો કે અન્ય ક્લાયન્ટ હજી શ્રોતા સુધી પહોંચે છે અને ખાનગી સંસાધનોના માર્ગ બદલાયા નથી.
નોંધ ટૂંકી રાખો: કયા ક્લાયન્ટે કયું સરનામું વાપર્યું, સર્વરે શું જોયું અને ત્રણ ઉપાયોમાંથી કયો લાગુ કરાયો. RFC 4787 ની હેરપિનિંગ આવશ્યકતાઓ અહીં NAT પાસેથી શું અપેક્ષિત છે તેનો સંદર્ભ છે, અને સમજાવે છે કે આ સુવિધા વિનાનું રાઉટર સામાન્ય રીતે કેમ વર્તે છે. બહારની દુનિયા જે પુનઃઉત્પાદન કરી શકતી નથી તેવી સ્થાનિક નિષ્ફળતા વિરુદ્ધ સાબિત ન થાય ત્યાં સુધી અનુવાદનો પ્રશ્ન છે, તેથી તેને એ રીતે ચકાસો.