કેમ /32 હોસ્ટ રૂટ VPN એન્ડપોઇન્ટને પહોંચવા યોગ્ય રાખે છે

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

એક સરનામું, ટેબલમાં એક નોંધ

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

એ ગુણધર્મ હોસ્ટ રૂટને સારો અપવાદ અને ખરાબ ટેવ બનાવે છે. સેવાના મુખ્ય દરવાજાને નામ આપતી બે /32 નોંધો તેનું બીજું સરનામું, તેનું IPv6 સરનામું કે આવતા મહિને તે જ્યાં ખસે છે તે સરનામું આવરી લેતી નથી. અસ્પષ્ટ એક-સરનામા નોંધોથી ભરેલું ટેબલ સામાન્ય રીતે એમ કહે છે કે કોઈ સબનેટ નિર્ણય લેવાને બદલે તેની આસપાસ પેચ કરતું રહ્યું. પહેલાં પ્રીફિક્સની લંબાઈ વાંચો, પછી પૂછો કે નોંધ શેનું રક્ષણ કરવાની છે.

ક્લાયન્ટથી બહાર તરફ નોંધ વાંચો

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

ip route get 203.0.113.25
ip -6 route get 2001:db8:4::25
ip route show | grep -F 203.0.113.25
Find-NetRoute -RemoteIPAddress 203.0.113.25

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

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

એન્ડપોઇન્ટ અપવાદ અને રિકર્શન ફાંદો

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

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

એપ્લિકેશન ખરેખર જે માર્ગ વાપરે છે તે ચકાસો

હોસ્ટનામ પર સફળ ping નબળો પુરાવો છે જ્યારે એપ્લિકેશન બીજા સરનામે કે બીજી ફેમિલી સાથે જોડાય છે. ક્લાયન્ટ ચલાવતા મશીનથી સરનામું, ફેમિલી, પોર્ટ અને ઇન્ટરફેસનું ચોક્કસ સંયોજન ચકાસો.

ip route get 203.0.113.25
sudo nft list ruleset | grep -A 4 'chain output'
curl -sS --max-time 8 -o /dev/null -w '%{remote_ip}
' https://app.example.net

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

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