VPN દ્વારા જોડાયેલા સર્વર માટે DNS માં કયું સરનામું જાય છે?
હોસ્ટ કરેલા સર્વર પાસે ત્રણ સરનામાં હોય છે અને તે એકબીજાના બદલે વાપરી શકાતાં નથી. દરેક સેવાને જે મૂલ્ય જોઈએ તે પસંદ કરો, પછી તેને મશીનની બહારથી ચકાસો.
VPN ઇન્સ્ટોલ કરેલા હોસ્ટ કરેલા સર્વર પાસે અંતે ત્રણ સરનામાં હોય છે, અને તેમાંથી ફક્ત એક જ તમે કન્ફિગર કરવા જઈ રહ્યા છો તે દરેક જગ્યા સાથે સંબંધિત હોય છે. પ્રદાતાની પેનલમાંથી નંબર DNS માં, કોઈ શ્રોતામાં કે પરવાનગી યાદીમાં કૉપિ કરવો એ એવો રસ્તો છે જેના પર ચાલતું ટનલ એવી સેવા બની જાય છે જ્યાં કોઈ પહોંચી શકતું નથી. આ માર્ગદર્શિકા કામને એવા ક્રમમાં ગોઠવે છે કે દરેક સરનામું જાહેર કરેલા હેતુ માટે પસંદ થાય. તે એ આદેશોની પણ યાદી આપે છે જે ચકાસે છે કે તમે ખરેખર શું પ્રકાશિત કર્યું.
કંઈપણ પ્રકાશિત કરતાં પહેલાં ત્રણ સરનામાંનો નકશો બનાવો
તેમને કાર્ય પ્રમાણે નામ આપો. underlay સરનામું એ છે જે મશીન ઇન્ટરનેટ દ્વારા VPN ના અંતિમ બિંદુ સુધી પહોંચવા માટે વાપરે છે, અને તે ઘણી વાર પ્રદાતાના NAT પાછળ ખાનગી હોય છે. ટનલનું સરનામું VPN ની અંદર રહે છે અને ઉત્પાદન પ્રમાણે સર્વર કે ક્લાયન્ટ આપે છે. જાહેર નિકાસ એ સરનામું છે જે કોઈ દૂરસ્થ વેબસાઇટ અનુવાદ પછી નોંધે છે, અને તમે પૂછી શકો એવા કોઈ પણ ઇન્ટરફેસ પર તેનું અસ્તિત્વ હોવું જરૂરી નથી.
એક પેનલ જે મશીન માટે એક જાહેર સરનામું બતાવે છે તે બાકીની બે ભૂમિકાઓ વિશે તમને બહુ ઓછું કહે છે. underlay ની પહોંચ એ જરૂરિયાત છે, ખરીદી નહીં: ઘરેલું રાઉટર પાછળનું લેપટોપ જાહેર IPv4 સરનામું રાખ્યા વિના હોસ્ટ કરેલા VPN અંતિમ બિંદુ સુધી પહોંચી શકે છે. તમે જે કરી શકતા નથી તે એ છે કે એવું નામ લખીને પ્રવેશમાર્ગ ઘડી કાઢો જે એવા સરનામા પર ઉકેલાય જેને કોઈ આગળ મોકલતું નથી.
સરનામું સેવા પ્રમાણે પસંદ કરો, લેબલ પ્રમાણે નહીં
નંબર પસંદ કરતાં પહેલાં લખી લો કે સર્વરે શું કરવાનું છે. બહાર જતા API કૉલને સ્થિર નિકાસ જોઈએ જ્યારે બીજી બાજુ પરવાનગી યાદી રાખે છે. ખાનગી ઍક્સેસને એવું ટનલ સરનામું જોઈએ જ્યાં ક્લાયન્ટ રૂટ કરી શકે અને તેની સાથે જોડાયેલ શ્રોતા. જાહેર હોસ્ટિંગને એવું પ્રવેશ મેપિંગ જોઈએ જે પ્રદાતા ખરેખર આપે છે, અને ફક્ત નિકાસનું સરનામું તે આપતું નથી.
એક જ મશીન ત્રણેય હેતુ પૂરા કરી શકે છે અને તેમ છતાં ત્રણ અલગ સરનામાં વાપરી શકે છે. જે તૂટે છે તે એ માન્યતા છે કે એક મૂલ્ય તે બધાને ઢાંકી દે છે:
| Requirement | Value that belongs there | What you see when the roles are swapped |
|---|---|---|
| Outbound allowlisting | Public exit | Requests reach the service but are rejected |
| Private client access | Tunnel address | Client connects, nothing answers |
| Inbound web service | Provider mapping | Name resolves, connection times out |
પ્રવેશની લાઇન એ જ છે જેના પર લોકો દલીલ કરે છે. નિકાસના સરનામા તરફ ઇશારો કરતું રેકોર્ડ કોઈ શ્રોતા, ફાયરવોલમાં છિદ્ર કે પોર્ટ મેપિંગ બનાવતું નથી, અને રાહ જોવાથી તે બદલાતું નથી. જ્યારે પ્રદાતા સમર્પિત સરનામું પ્રવેશ નિયમ સાથે વેચે છે, ત્યારે તે બંડલ એ જ ક્ષમતા છે જે તમે ખરીદી છે; ફક્ત સરનામું પોતે અધિકાર નથી.
કયું સરનામું કયું છે તે દર્શાવતા આદેશો
મશીન વાંચો, પેનલ નહીં. ઇન્ટરફેસના નામ સિસ્ટમ પ્રમાણે અલગ હોય છે, તેથી સરનામાંને ઉપકરણો સાથે મેળવો, કોઈ લેબલ પર ભરોસો કરવાને બદલે.
પહેલી લાઇન દરેક IPv4 સરનામું અને તેનું ઉપકરણ સૂચવે છે, અને બીજી કર્નલને પૂછે છે કે જાણીતા બાહ્ય ગંતવ્ય માટે તે કયું ઉપકરણ વાપરશે:
ip -brief -4 addr show
ip -4 route get 198.51.100.10
curl -4 -s https://ifconfig.me
ss -lntp | grep -E ':(443|1194)'જો રૂટ શોધ જાહેર ટ્રાફિક માટે ટનલ ઉપકરણ સાથે જવાબ આપે, તો તમારું સંપૂર્ણ ટનલ અમલમાં છે. શ્રોતાની તપાસ પણ એટલી જ મહત્ત્વની છે, કારણ કે ફક્ત 127.0.0.1 સાથે બંધાયેલી પ્રક્રિયા ટનલ સરનામા પર ક્યારેય જવાબ નહીં આપે, તમે જે નામ પણ પ્રકાશિત કરો.
તેને પ્રકાશિત કરો, પછી બહારથી ચકાસો
ફક્ત તે મૂલ્ય પ્રકાશિત કરો જે સેવાને જોઈએ છે અને તેનાથી વધુ કંઈ નહીં: હોસ્ટિંગ માટે A કે AAAA રેકોર્ડ, બહાર જતા કૉલ માટે પરવાનગી યાદીની નોંધ, ખાનગી ઍક્સેસ માટે ક્લાયન્ટ પ્રોફાઇલ. પછી જે સ્થિતિ મહત્ત્વની છે ત્યાંથી પરીક્ષણ કરો, અને તે ક્યારેય એ મશીન નથી જે તમે હમણાં જ સંપાદિત કર્યું.
બે તપાસો મોટા ભાગને આવરી લે છે, અને બંને સ્ક્રિપ્ટમાં રાખવા જેટલી સસ્તી છે:
dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/healthતમારું રેકોર્ડ અસ્તિત્વમાં છે તેવું સાબિત કરતો DNS જવાબ એ વાતનો પુરાવો નથી કે વિનંતી પહોંચે છે, અને એક સફળ વિનંતી ફક્ત એટલું સાબિત કરે છે કે એક માર્ગ એક નેટવર્કથી કામ કરે છે. પરવાનગી યાદી સામેલ હોય ત્યારે મોબાઇલ કનેક્શનથી તપાસનું પુનરાવર્તન કરો, કારણ કે તમે જે નિકાસ જુઓ છો તે સરનામા પરિવાર અને લીધેલા માર્ગ પર આધારિત હોઈ શકે. તમે કયો પરિવાર ચકાસ્યો તે નોંધો; કામ કરતો IPv4 માર્ગ IPv6 વિશે કંઈ જ કહેતો નથી.
જો સેવા પ્રવેશમુખી હોય, તો નિકાસનું સરનામું પૂરતું નથી
પ્રવેશ ઍક્સેસ માટે ચાર વસ્તુઓ એક લાઇનમાં જરૂરી છે: એવું નામ કે સરનામું જ્યાં સુધી ક્લાયન્ટ પહોંચી શકે, એવો માર્ગ જે પેકેટને મશીન સુધી પહોંચાડે, એવો શ્રોતા જે તેને સ્વીકારે, અને એવી નીતિ જે તેને પડતું ન મૂકે. VPN બીજું ઘટક બદલે છે અને ક્યારેક પહેલું પણ, અને ત્રીજા તથા ચોથા માટે કંઈ કરતું નથી. જ્યારે ટનલ જ ડિલિવરીનો માર્ગ હોય, ત્યારે ક્લાયન્ટ નિકાસને બદલે ટનલ સરનામા સાથે જોડાય છે.
દરેક સેવા કયા સરનામા પર આધારિત છે તે નોંધો, પછી પ્રદાતા તેનું રૂટિંગ મોડેલ બદલે ત્યારે તે નોંધ ફરી જુઓ. જે સર્વર ખાનગી રીતે જવાબ આપે છે અને જાહેરમાં નિષ્ફળ જાય છે તે સામાન્ય રીતે બગડેલું હોતું નથી; તે ખોટી ઓળખ સાથે જવાબ આપી રહ્યું હોય છે, અને સુધારો ફાયરવોલ ફેરફાર નહીં પણ મેપિંગનો નિર્ણય છે.