તમારા VPN સર્વર માટે DHCP રિઝર્વેશન સ્થિર IP કેમ નથી

મેં ઘરનું VPN બોક્સ Wi-Fi થી Ethernet પર ખસેડ્યું અને તેનું “કાયમી” સરનામું તે જ સાંજે બદલાઈ ગયું. રાઉટર પર કંઈ તૂટ્યું ન હતું. રિઝર્વેશન વાયરલેસ એડેપ્ટર સાથે મેળ ખાતું હતું, અને એ એડેપ્ટર હવે માર્ગમાં ન હતું.

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

રિઝર્વેશન ક્લાયન્ટ સાથે મેળ ખાય છે, ઉપકરણ સાથે નહીં

DHCPv4 માં રિઝર્વેશન ક્લાયન્ટના હાર્ડવેર સરનામા પર આધારિત છે; DHCPv6 માં તે DUID પર આધારિત છે જે ક્લાયન્ટે રાખવાનું મનાય છે. hostname ક્ષેત્ર માણસો માટેનું લેબલ છે. રાઉટર ખરેખર વિનંતીમાં આવતી ઓળખની સરખામણી કરે છે.

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

OpenWrt આકાર સ્પષ્ટ બતાવે છે. /etc/config/dhcp માં એક config host બ્લોક નામ, MAC અને સરનામું એકસાથે બાંધે છે, અને સ્થિર લીઝનું દસ્તાવેજીકરણ સમજાવે છે કે એ એન્ટ્રી પૂલ સાથે કેવી રીતે કામ કરે છે. બીજા રાઉટર સમાન ત્રણ ક્ષેત્રોને જુદા લેબલ પાછળ છુપાવે છે.

જ્યાં મેળ ચૂપચાપ તૂટે છે

હાર્ડવેર બદલવું સામાન્ય કિસ્સો છે. NIC બદલો, અથવા મશીનને Ethernet અને Wi-Fi વચ્ચે ખસેડો, અને રાઉટર જે સરનામું જુએ છે તે તેની સાથે બદલાય છે. જૂનું રિઝર્વેશન યાદીમાં રહે છે, હજુ પણ સાચું લાગે છે.

પુનઃસ્થાપન બીજો કિસ્સો છે, અને તે IPv6 પર સૌથી વધુ દાંત કરે છે. નવું સ્થાપન નવું DUID બનાવી શકે છે જ્યારે જૂની IPv4 લીઝ હજુ માન્ય છે, તેથી v4 સરનામું થોડો સમય ટકે છે અને v6 એન્ટ્રી કોઈ દૃશ્ય સંપાદન વિના લાગુ થવાનું બંધ કરે છે.

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

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

હોસ્ટ તરફનું કન્ફિગરેશન અને તેની કિંમત

હોસ્ટ પર સરનામું સેટ કરવાથી મેળવણીનો પ્રશ્ન સંપૂર્ણપણે દૂર થાય છે. DHCP જવાબ આપે કે ન આપે, ઇન્ટરફેસ એ સરનામા સાથે જ ઉપર આવે છે, અને રાઉટર રીબૂટ પછી પણ પહોંચી શકાય તેવી મશીન પાસેથી તમે એ જ ઇચ્છો છો.

કિંમત માલિકી છે. હવે પ્રીફિક્સ, ગેટવે અને રિઝોલ્વર તમે જ આપો છો, અને સરનામું ગતિશીલ પૂલની બહાર તમારે જ રાખવું પડે છે. netplan સાથે Ubuntu માં તેને /etc/netplan/01-vpn.yaml વહન કરે છે:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      addresses: [192.168.50.10/24]
      routes:
        - to: default
          via: 192.168.50.1
      nameservers:
        addresses: [192.168.50.1]

NetworkManager વપરાશકર્તા nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1 સાથે, પછી nmcli con up "Wired connection 1" સાથે એ જ સ્થિતિમાં પહોંચે છે. પ્રથમ પ્રયાસે netplan apply ને બદલે netplan try સાથે netplan લાગુ કરો; ખોટું લખાયેલું ગેટવે બોક્સને નેટવર્ક પરથી ઉતારી નાખે છે અને તમને કન્સોલ શોધતા મૂકી દે છે.

તેમ છતાં મેળ ખાતું રિઝર્વેશન રાખો. તે વધારાનું નથી. એન્ટ્રી રાઉટરની બાજુએ સરનામું નોંધે છે અને કોઈ પછીથી પૂલ મોટું કરે તો DHCP સર્વરને એ સરનામું મહેમાન ઉપકરણને આપતું અટકાવે છે.

સ્થિર LAN સરનામું જાહેર અંતિમ બિંદુ નથી

પોર્ટ ફોરવર્ડને 192.168.50.10 તરફ દોરો અને નિયમ LAN બાજુના દરેક ફેરફારમાં ટકી રહે છે. તે તમને સ્થિર ઇન્ટરનેટ સરનામું આપતું નથી. તમારું જાહેર IP ISP નું છે અને ફરીથી જોડાવા કે મોડેમ બદલવા પર ખસી શકે છે, ગતિશીલ DNS એ માટે જ છે.

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

ત્રીજું સરનામું ટનલ પૂલ છે, ઘણી વાર 10.8.0.0/24 જેવું કંઈક. એ સરનામાં ફક્ત ટનલની અંદર જ હોય છે અને LAN પર ક્યારેય દેખાતાં નથી. તેમને સર્વરના LAN સરનામા સાથે ગૂંચવવું એ જ રીત છે જેમાં પોર્ટ આખરે એવા ક્લાયન્ટ તરફ ફોરવર્ડ થાય છે જે ફક્ત જોડાયેલો હોય ત્યારે જ ઓનલાઇન હોય છે.

માર્ગને એ ક્રમમાં તપાસો જેમાં તે તૂટે છે

રાઉટરથી શરૂ કરો. લીઝ ટેબલની એન્ટ્રીની રિઝર્વેશનના લક્ષ્ય સાથે સરખામણી કરો; જો સર્વરે પૂલ સરનામું લીધું હોય, તો ઓળખ ખોટી છે, અને હોસ્ટ પર ip link show તમને સરખામણી માટે મૂલ્ય આપે છે.

પછી હોસ્ટ. ip -4 addr show eth0 એ અપેક્ષિત સરનામું અને પ્રીફિક્સ બતાવવું જોઈએ. એ જ ઇન્ટરફેસ પર બીજું સરનામું સામાન્ય રીતે એનો અર્થ છે કે DHCP હજુ તમારા સ્થિર કન્ફિગરેશનની બાજુમાં ચાલી રહ્યું છે.

પછી ફોરવર્ડ. ખાતરી કરો કે ગંતવ્ય હજુ પણ તમે હમણાં ચકાસેલા સરનામા જેટલું જ છે, અને ખાતરી કરો કે કંઈક ss -lntp સાથે સાંભળી રહ્યું છે. બંધ પોર્ટ તરફનું ફોરવર્ડ બહારથી તૂટેલા ફોરવર્ડ જેવું જ દેખાય છે.

બહારથી પૂરું કરો, Wi-Fi બંધ હોય તેવા ફોન પર. એ એક પરીક્ષણ “સ્થાનિક સરનામું ખોટું છે” અને “જાહેર પહોંચ તૂટેલી છે” વચ્ચે ભેદ પાડે છે, આ સેટઅપ જે બે સમસ્યાઓ વારંવાર ભેળવે છે.

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