શું ઘરના VPN સર્વર માટે ડાયનેમિક DNS જરૂરી છે?

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

શરત એક: તમારું સરનામું ખરેખર ખસે છે

રહેણાંક સરનામાં સામાન્ય કારણોસર ખસે છે: વીજ કાપ પછી મોડેમ ફરી સિંક થાય છે, ISP પૂલ ફરી સંતુલિત કરે છે, લાંબા વિક્ષેપ પછી નવું લીઝ આવે છે. કેટલીક લાઇન પર તે ભાગ્યે જ ખસે છે, અને મેં એક જ સરનામું વર્ષ સુધી ટકી રહેતું જોયું છે; વ્યાવસાયિક પ્લાનમાં ઘણી વાર સ્થિર સરનામું હોય છે. જો બાર મહિનામાં કંઈ બદલાયું ન હોય, તો હાથે સંપાદિત કરેલો એક A રેકોર્ડ એક ડિમન ઓછો જીવતો રાખવાનો.

અનુમાન કરવાને બદલે માપો. રાઉટરના સ્ટેટસ પેજ પર WAN સરનામું વાંચો, પછી બહારની દુનિયા જે જુએ છે તેની સાથે સરખાવો. આ LAN ના મશીન પરથી ચલાવો:

curl -fsS https://api.ipify.org; echo

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

શરત બે: ક્લાયન્ટ ફરી નામ શોધે છે

ટૂંકું TTL એ ભાગ છે જે લોકો છોડી દે છે. રિકર્સિવ રિઝોલ્વર રેકોર્ડનું TTL માને છે, પણ ક્લાયન્ટ સ્ટેક અલગથી કેશ કરે છે, અને પહેલેથી ઊભેલો ટનલ ફરી કંઈ રિઝોલ્વ કરતો નથી. ડિબગ કરતી વખતે રેકોર્ડ 60-300 સેકન્ડ પર રાખો; તે જૂનો જવાબ પરોસાય તેવી વિન્ડો ટૂંકી કરે છે અને જોડાયેલું સેશન માઇગ્રેટ કરતું નથી.

OpenVPN દર વખતે ફરી જોડાય ત્યારે લાઇન remote vpn.example.net 1194 ફરી રિઝોલ્વ કરે છે, અને resolv-retry infinite તેને ફરી પ્રયત્ન કરતું રાખે છે, લુકઅપ નિષ્ફળ જાય ત્યારે બહાર નીકળવાને બદલે. સર્વર પર float સ્થાપિત સેશનને એવા પીઅરને અનુસરવા દે છે જેનું સ્રોત સરનામું બદલાયું છે. WireGuard વધુ સીધું છે: wg-quick up કન્ફિગરેશન લાગુ થાય ત્યારે Endpoint રિઝોલ્વ કરે છે, અને ક્લાયન્ટ ટનલ ફરી બનાવે ત્યારે તેને ફરી રિઝોલ્વ કરે છે, તેથી જૂના સરનામા સામે હજી સફળ થતો હેન્ડશેક અટકે ત્યાં સુધી સફળ રહે છે.

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

શરત ત્રણ: અંદર જવાનો રસ્તો હજી ખુલ્લો છે

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

બહારથી પરીક્ષણ કરો. Wi-Fi બંધ રાખીને સેલ્યુલર ડેટા પરનો ફોન સૌથી સસ્તું પ્રામાણિક પરીક્ષણ છે; એ જ LAN પરનું લેપટોપ નહીં. જ્યારે નામ તમારા જાહેર સરનામા પર રિઝોલ્વ થાય અને રાઉટરમાં NAT લૂપબેક ન હોય, ત્યારે અંદરનું પરીક્ષણ નિષ્ફળ જાય છે જ્યારે રેકોર્ડ સંપૂર્ણ સાચો હોય છે, અને એ જ મોટા ભાગના લોકોને કદી ખોટો ન હોય તેવો રેકોર્ડ સંપાદિત કરવા મોકલે છે.

ત્રણેય પૂરી થાય ત્યારે શું ચલાવવું

નાના હોસ્ટ માટે ddclient સૌથી ઓછું આશ્ચર્યજનક અપડેટર છે. ન્યૂનતમ કન્ફિગરેશન પ્રોવાઇડર જે સરનામું જુએ છે તે પ્રકાશિત કરે છે, જે ડબલ-NAT ભૂલ ટાળે છે:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

તેને shell લૂપને બદલે દર થોડી મિનિટે systemd ટાઇમરથી ચલાવો, અને સફળતા ધારવાને બદલે પ્રોવાઇડરનો જવાબ લોગ કરો. ક્રેડેન્શિયલને ચાવીની જેમ ગણો, કારણ કે તે નક્કી કરે છે દરેક ક્લાયન્ટ ક્યાં મોકલાય છે: એકાઉન્ટ પાસવર્ડને બદલે મર્યાદિત અપડેટ ટોકન વાપરો, ફાઇલને 0600 મોડ પર રાખો અને અપડેટ HTTPS પર મોકલો.

પ્રતિબદ્ધ થવા પહેલાં ચકાસો

એક લુકઅપ તમને કહે છે બાકીની દુનિયા શું જુએ છે, અને તે TTL છાપે છે જે બદલાવ પછી રાહ જોવી પડે:

dig +noall +answer vpn.example.net @1.1.1.1

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

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

જ્યારે જવાબ ના હોય

જો શરત એક કે ત્રણ નિષ્ફળ જાય, તો કન્ફિગરેશન નહીં પણ નિર્ણય બદલાય છે. કેરિયર NAT પાછળ તમારા વ્યવહારુ વિકલ્પો છે ISP પાસે જાહેર સરનામું માંગવું, પ્રવેશ બિંદુને સ્થિર સરનામાવાળા નાના VPS પર ખસેડવું, અથવા પોતાનું મિલન રાખતું ઓવરલે વાપરવું. જો સરનામું સ્થિર હોય, તો અપડેટર છોડી દો: એક A રેકોર્ડ, IPv6 ચલાવો તો એક AAAA રેકોર્ડ, એ જ પોર્ટ ફોરવર્ડિંગ.

જો ક્લાયન્ટ જોડાયેલા રહે ત્યારે સરનામું બદલાય, તો પ્રામાણિક ઉપાય ક્લાયન્ટમાં રહે છે: ફરી જોડાવાની લોજિક અને ફરી પ્રયત્નનું અંતર, ઝડપી અપડેટર નહીં. બીજો પ્રોવાઇડર ઉમેરવાથી ફક્ત અંતર છુપાય છે.

આગળ વધતા પહેલાં ક્રમમાં ચાર વસ્તુઓની પુષ્ટિ કરો:

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

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