શું Pi ગેટવેનું હોસ્ટનામ જાતે જ સ્ટેટિક રૂટ અપડેટ કરે છે?

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

DNS જવાબ અને રૂટ અલગ વસ્તુઓ છે

ધારો કે તમારું Pi vpn-gw.lan પર જવાબ આપે છે અને 10.44.0.0/16 ને ટનલમાં ફોરવર્ડ કરે છે. 192.168.30.0/24 પરના ક્લાયન્ટ સ્ટેટિક રૂટ દ્વારા ત્યાં પહોંચે છે. જ્યારે Pi નું સરનામું 192.168.30.4 થી 192.168.30.11 પર ખસ્યું, રેકોર્ડ તેના TTL ની અંદર અનુસર્યો અને રૂટ નહીં.

બે દૃષ્ટિકોણ એવી રીતે અસહમત છે કે જે ચૂકી જવી સહેલી છે, કારણ કે અલગથી પૂછો ત્યારે બંને વિશ્વસનીય લાગે છે:

$ ip route get 10.44.0.1
10.44.0.1 via 192.168.30.4 dev eth0 src 192.168.30.20
$ dig +short vpn-gw.lan
192.168.30.11

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

કમાન્ડ પૂરો થયા પછી ટેબલમાં શું રહે છે

Linux રૂટ અહીં મહત્વની બે વસ્તુઓ નોંધે છે: પ્રોટોકોલ સરનામા તરીકે આગલું હોપ, અને ઇન્ડેક્સ નંબર તરીકે આઉટગોઇંગ ઇન્ટરફેસ. rtnetlink રૂટ એટ્રિબ્યુટ એ પ્રથમ ફીલ્ડને RTA_GATEWAY કહે છે, અને તેમાં બાઇટ્સ રહે છે. એન્ટ્રી એક વાર જગ્યાએ બેસે પછી તેના પર કોઈ TTL જોડાયેલું રહેતું નથી અને કોઈ બેકગ્રાઉન્ડ લુકઅપ તેને તાજું કરતું નથી.

એટલે જ ip route add 10.44.0.0/16 via vpn-gw.lan કામ કરતું હોય એવું લાગી શકે. સાધન કમાન્ડ ચાલતી વખતે નામનું સમાધાન કરે છે, પરિણામી સરનામું લખે છે, અને નામ સંપૂર્ણપણે ભૂલી જાય છે. પછી ip route show 10.44.0.0/16 ચલાવો અને તમને શાબ્દિક સરનામું પાછું મળશે.

ટનલને દોષ આપવા પહેલાં આ વર્તન જાણવા જેવું છે.

તમારા વતી નામનું સમાધાન કરતાં સાધનો, અને ક્યારે

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

મેનેજ્ડ સેટઅપ સામાન્ય રીતે કામ વહેંચે છે. DHCP રિઝર્વેશન કે સ્ટેટિક લીઝ Pi ને એક સરનામા પર રાખે છે, અને DNS રેકોર્ડ ફક્ત લીઝને અનુસરે છે. કોઈને ફરતા લક્ષ્યને ટ્રેક કરવાની જરૂર નથી, કારણ કે લક્ષ્ય ફરતું નથી.

નિરીક્ષણ કરાયેલ અપડેટર બીજી કાયદેસર પેટર્ન છે, અને તેને માલિકની જરૂર છે.

સરનામું પિન કરો અથવા અપડેટર જાતે ચલાવો

નાના LAN માટે DHCP સર્વર પર રિઝર્વેશન સૌથી સસ્તો ઉપાય છે. ડાયનેમિક પૂલની બહાર સરનામું પસંદ કરો, તેને Pi ના MAC સરનામા સાથે બાંધો, અને આગલા લીઝ નવીકરણ પછી ip -4 addr show dev eth0 થી તેની પુષ્ટિ કરો. પછી ક્લાયન્ટના આગલા હોપને એક વાર તે સરનામા તરફ દોરો. હવે તમારી પાસે સ્થિર ગેટવે અને તેનું વર્ણન કરતો રેકોર્ડ છે, અને સંબંધ ખરેખર જે ક્રમમાં કામ કરે છે તે એ છે.

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

new=$(dig +short vpn-gw.lan | head -n1)
cur=$(ip route get 10.44.0.1 | awk '{print $3}')
if [ "$new" != "$cur" ]; then
  ip route replace 10.44.0.0/16 via "$new"
fi
ip route get 10.44.0.1

છેલ્લું કમાન્ડ સ્વીકૃતિ પરીક્ષણ છે, કારણ કે તે ગેટવે છાપે છે જે કર્નલ ખરેખર વાપરશે. જો છપાયેલું સરનામું હજી જૂનું છે, તો સ્ક્રિપ્ટ ખોટા નેટવર્ક નેમસ્પેસમાં ચાલ્યું અથવા પરવાનગી નહોતી, અને DNS બાજુ અપ્રસ્તુત છે.

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