તમે ગોઠવી ન શકો તેવા NAT પાછળ VPN: શું હજી કામ કરે છે

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

મેપિંગ ટેબલ બધું નક્કી કરે છે

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

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

રેન્ડેવઝસ સેવા શું કરી શકે અને શું ન કરી શકે

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

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

કીપએલાઇવ, રીબૂટ અને ખસતો એન્ડપોઈન્ટ

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

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

ખૂટતા ફોરવર્ડની આસપાસ ત્રણ રસ્તા

પહેલો રસ્તો રાઉટરને જાતે એન્ટ્રી બનાવવા કહે છે, UPnP IGD, NAT-PMP અથવા PCP દ્વારા, જ્યારે સુવિધા હાજર હોય અને ચાલુ હોય. બીજો ટ્રાફિકને જાહેર સરનામાવાળા રિલેને સોંપે છે, જે હંમેશા કામ કરે છે અને હંમેશા બેન્ડવિડ્થ ઉપરાંત એક અલગ વિશ્વાસ-સીમાનો ખર્ચ કરે છે. ત્રીજો દિશા ઉલટાવે છે: આંતરિક હોસ્ટ જાહેર સર્વર તરફ આઉટબાઉન્ડ ટનલ ખોલે છે અને બાકીનું બધું તેની અંદર સવારી કરે છે.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

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

ઉપાયને રાઉટરનો માલિક કોણ છે તેની સાથે મેળવો

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

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