ddclient VPN એક્ઝિટ પ્રકાશિત કરે છે: શોધ સ્રોત સુધારો

તમારું DNS નામ હવે VPN પ્રદાતાના સરનામા પર રિઝોલ્વ થાય છે, અને અપડેટ લોગ સંપૂર્ણ સ્વસ્થ દેખાય છે. આ સંયોજન સામાન્ય છે. વેબ-આધારિત શોધ પ્રોબ બાહ્ય સેવાને પૂછે છે કે તે કયો સ્રોત જુએ છે, અને જ્યારે વિનંતી સંપૂર્ણ ટનલ VPN દ્વારા બહાર જાય છે, ત્યારે જવાબ VPN એક્ઝિટ હોય છે, તમારું ઘરનું WAN સરનામું નહીં. અપડેટરે તેનું કામ કર્યું; કામ ખોટા નિરીક્ષણ તરફ નિર્દેશિત હતું.

નામ શું સુધી પહોંચવું જોઈએ તેની ખાતરી કરો

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

VPN ક્લાયન્ટના ટનલ સરનામા માટે ખાનગી નામ એ બીજા જવાબ સાથેની બીજી સમસ્યા છે: તે ખાનગી DNS માં આવે છે, અને તેને જાહેર શોધ સેવાની જરૂર જ નથી. બે જરૂરિયાતો ભેળવવી એ રીત છે જેમાં કાર્યક્ષમ રૂપરેખાંકન એવું સરનામું પ્રકાશિત કરવા લાગે છે જે કોઈએ માંગ્યું ન હતું.

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

કંઈપણ બદલતા પહેલાં મૂલ્યનું પુનરુત્પાદન કરો

બંને માર્ગો અલગથી જુઓ. ટનલ ચાલુ હોય ત્યારે પ્રોબ એક્ઝિટની જાણ કરે છે; ટનલ બંધ હોય ત્યારે, અથવા પ્રોબ ભૌતિક ઇન્ટરફેસ સાથે બંધાયેલ હોય ત્યારે, તે ઘરનું સરનામું જણાવે છે: curl --interface eth0 https://ifconfig.me. જો તે બે જવાબ અલગ હોય, તો તમે અપડેટરને સ્પર્શ કર્યા વિના ખામીનું પુનરુત્પાદન કર્યું છે.

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

શોધને પસંદ કરેલા માર્ગ તરફ નિર્દેશિત કરો

જો નામે ઘરનું WAN સરનામું પ્રકાશિત કરવું હોય, તો શોધે તે જ સરનામું નિરીક્ષણ કરવું જોઈએ. ત્રણ વિકલ્પ કામ કરે છે, આશરે પ્રાધાન્ય ક્રમમાં: રાઉટરને તેના પોતાના સમર્થિત અપડેટર દ્વારા પ્રકાશિત કરવા દો; રાઉટર ખરેખર જે પૃષ્ઠ પર સેવા આપે છે તેની સામે ddclient ની રાઉટર-સ્થિતિ શોધ વાપરો; અથવા વેબ પ્રોબ રાખો પણ તેને ભૌતિક ઇન્ટરફેસ સાથે બાંધો જેથી તે ટનલની બહાર નીકળે.

રાઉટર-સ્થિતિ માર્ગ માટે, નવા ddclient પ્રકાશનો usev4 અને fwv4 વિકલ્પ પરિવાર વાપરે છે, આસપાસના પૃષ્ઠ લખાણ માટે વૈકલ્પિક સ્કિપ પેટર્ન સાથે. તમારા સ્થાપિત સંસ્કરણ માટે README તપાસો, કારણ કે જૂના પ્રકાશનો એ જ વિચાર use અને fw થી લખે છે, અને ખોટા પ્રકાશનમાંથી નકલ કરેલ વિકલ્પ નામ શરૂઆતમાં નિષ્ફળ જાય છે.

જો તમે વેબ શોધ રાખો છો, તો યાદ રાખો કે પ્રોબનું રૂટિંગ અને અપડેટ API કૉલનું રૂટિંગ અલગ નિર્ણયો છે. અપડેટ કૉલ રેકોર્ડ પહોંચાડે છે; પ્રોબ નક્કી કરે છે કે કયું મૂલ્ય પહોંચાડવું.

રહસ્યો અને સંસ્કરણો સુવ્યવસ્થિત રાખો

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

ddclient README શોધ અભિગમો અને તેમના વિકલ્પ નામોનું દસ્તાવેજીકરણ કરે છે. એક જ રેકોર્ડમાં IPv4 અને IPv6 પરિણામો ભેળવશો નહીં, અને એવું ન માનો કે એક પ્રકાશનમાં હાજર વિકલ્પ બીજામાં પણ છે.

મૂલ્યની ચકાસણી કરો, પછી પહોંચની

લાઇવ અપડેટની પરવાનગી આપતા પહેલાં પ્રસ્તાવિત સરનામાને ઇચ્છિત એન્ડપોઇન્ટ સાથે સરખાવો, પછી એક અધિકૃત અપડેટ પછી અધિકૃત DNS તપાસો અને રિઝોલ્વર કેશ ધ્યાનમાં લો. નીચું TTL પ્રતીક્ષા ટૂંકાવે છે; ખોટા મૂલ્યને સાચું બનાવતું નથી.

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