Linux પર ફોરવર્ડિંગ ચાલુ કર્યા પછી IPv6 નો ડિફોલ્ટ રૂટ ગાયબ થઈ ગયો

VPN ક્લાયન્ટનું ટ્રાફિક આગળ મોકલી શકે તે માટે મેં Debian ગેટવે પર net.ipv6.conf.all.forwarding=1 સેટ કર્યું, અને લગભગ અડધા કલાક પછી મશીન પાસે કોઈ IPv6 ડિફોલ્ટ રૂટ બચ્યો નહોતો. ઉપરનું રાઉટર ચાલુ હતું, link-local પડોશી હજી જવાબ આપી રહ્યું હતું, અને અપલિંક પાસે હજી તેનું વૈશ્વિક સરનામું હતું. જે અટક્યું તે કર્નલની તે ઇન્ટરફેસ પર રાઉટર જાહેરાતો સ્વીકારતા રહેવાની તૈયારી હતી. sysctl લખ્યાની ક્ષણે રૂટ ગાયબ નહોતો થયો; તે ત્યારે ગાયબ થયો જ્યારે RA થી શીખેલા ડિફોલ્ટ રૂટની આયુ પૂરી થઈ અને કોઈએ તેને નવો કર્યો નહીં.

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

કોઈપણ sysctl ને અડવા પહેલાં રૂટનું કોષ્ટક વાંચો

ip -6 route show default થી શરૂ કરો અને ફક્ત ગેટવે નહીં, લક્ષણો વાંચો. RA થી શીખેલો ડિફોલ્ટ રૂટ proto ra થી ચિહ્નિત હોય છે, પ્રાધાન્ય ધરાવે છે અને expires ની ઊંધી ગણતરી દેખાડે છે. હાથે ઉમેરેલા રૂટમાં આમાંથી કંઈ હોતું નથી, અને એ જ ફરક કહે છે કે રૂટનો માલિક કઈ પ્રણાલી છે.

$ ip -6 route show default
default via fe80::1 dev eth0 proto ra metric 1024 expires 1432sec hoplimit 64 pref medium

પછી સરનામું જુઓ: ip -6 addr show dev eth0. કલાકોમાં માપેલી પ્રાધાન્ય અને માન્ય આયુ ધરાવતું વૈશ્વિક સરનામું એવા ડિફોલ્ટ રૂટ કરતાં વધુ જીવશે જેની રાઉટર આયુ મિનિટોમાં માપાય છે. સરનામું હાજર હોય અને ડિફોલ્ટ રૂટ ન હોય, એ જાહેરાત સમસ્યાની નિશાની છે. સરનામું પણ ન હોય તો પહેલાં લિંક, પ્રીફિક્સ માહિતી અથવા નકલી સરનામાંની શોધ પાછળ લાગવું પડે.

ફોરવર્ડિંગ RA પ્રોસેસિંગ કેમ બંધ કરે છે

RA એ 134 પ્રકારનું ICMPv6 પેકેટ છે, જે link-local સ્રોતથી 255 હોપ મર્યાદા સાથે મોકલાય છે. કર્નલ તેનો ઉપયોગ કરે તે પહેલાં ઇન્ટરફેસનું accept_ra જુએ છે. ડિફોલ્ટ મૂલ્ય 1 છે, અને 1 નો અર્થ હા નથી. તેનો અર્થ છે: ફક્ત ત્યાં સુધી સ્વીકારો જ્યાં સુધી આ હોસ્ટ ફોરવર્ડ કરતું ન હોય. forwarding=1 સેટ કરો અને એ શરત નિષ્ફળ જાય, તેથી જાહેરાત તેમાંના કોઈપણ પ્રીફિક્સ કે ડિફોલ્ટ રાઉટરને ધ્યાનમાં લેવાય તે પહેલાં જ કાઢી નાખવામાં આવે છે.

ત્રણ મૂલ્યો છે, અને ફોરવર્ડિંગમાંથી ફક્ત ત્રીજું બચે છે:

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

ત્રણ આદેશોથી પુષ્ટિ કરો

પહેલાં લોડ થયેલી માનેલી ફાઇલને બદલે ચાલુ મૂલ્યો વાંચો:

sysctl net.ipv6.conf.eth0.forwarding net.ipv6.conf.all.forwarding \
       net.ipv6.conf.eth0.accept_ra net.ipv6.conf.eth0.accept_ra_defrtr

બીજું, જાહેરાતો હજી આવે છે તે સાબિત કરો. ICMPv6 પ્રકારના બાઇટ પર ફિલ્ટર કરવું પૂરતું છે, અને તે પડોશી શોધના ટ્રાફિકની દીવાલ વાંચવાથી બચાવે છે:

tcpdump -ni eth0 'icmp6 and ip6[40] == 134'

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

rdisc6 eth0

rdisc6 Debian અને Ubuntu પર ndisc6 પેકેજમાં આવે છે. આઉટપુટમાં બીજું કંઈ બદલતાં પહેલાં રાઉટર આયુ અને પ્રાધાન્ય જુઓ. રાઉટર આયુ 0 વાળી જાહેરાત ડિફોલ્ટ રાઉટર દૂર કરવાનો આદેશ છે, અને accept_ra નું કોઈ મૂલ્ય તેને વાપરી શકાય એવો રૂટ બનાવતું નથી. આ રીતે બ્રિજ મોડમાં રહેલું ઉપરનું CPE પણ પકડાય છે, જે પ્રીફિક્સ વહેંચે છે પણ પોતાને ક્યારેય રાઉટર તરીકે રજૂ કરતું નથી.

અપલિંકને જ એકમાત્ર પરવાનગી આપતું ઇન્ટરફેસ બનાવો

જો ઉપરનો ભાગ જ ડિફોલ્ટ રાઉટર હોવો જોઈએ તો ફોરવર્ડિંગ હોવા છતાં ત્યાં જ જાહેરાતો સ્વીકારો, અને બીજે ક્યાંય નહીં:

# /etc/sysctl.d/60-ipv6-router.conf
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.eth0.accept_ra = 2
net.ipv6.conf.eth0.accept_ra_defrtr = 1

મર્યાદા નક્કી કરવી જરૂરી છે કારણ કે Linux માં IPv6 ફોરવર્ડિંગ એક વૈશ્વિક સ્વિચ છે, દરેક લિંક માટે એક નહીં. net.ipv6.conf.wg0.forwarding માં 1 લખો અને પછી net.ipv6.conf.all.forwarding વાંચો: વૈશ્વિક મૂલ્ય ઊંધું ફરે છે અને દરેક ઇન્ટરફેસ ફોરવર્ડ કરવા લાગે છે. તમે ટનલ પર રાઉટર અને LAN પર સામાન્ય હોસ્ટ એકસાથે ન હોઈ શકો. જે મર્યાદિત કરી શકો તે સ્વીકૃતિ છે. accept_ra=2 અપલિંક પર રાખો અને ટનલ તથા LAN ઇન્ટરફેસ 1 કે 0 પર છોડી દો, જેથી ટનલ થઈને આવેલી ભટકતી જાહેરાત તેની અંદર તરફ દોરતો ડિફોલ્ટ રૂટ બેસાડી ન શકે.

કામચલાઉ sysctl -w આગલા બૂટ સુધી ટકશે નહીં, અને systemd-networkd તથા NetworkManager બંને આ મૂલ્યો પોતાની રૂપરેખાંકનમાંથી લખે છે. networkd માં અપલિંકની .network ફાઇલમાં IPv6Forwarding=yes અને IPv6AcceptRA=yes સેટ કરો; networkd કર્નલના એ જ કારણસર IPv6Forwarding ને વૈશ્વિક ગણે છે. NetworkManager માં અપલિંક પર ipv6.method=auto જ accept_ra નું મૂલ્ય ચલાવે છે, તેથી પહેલી ચકાસણી પર ભરોસો કરવાને બદલે nmcli connection up પછી sysctl ફરી વાંચો.

સ્થિર વિકલ્પ ip -6 route add default via fe80::1 dev eth0 ખરેખર કામ કરે છે, અને ઉપરના રાઉટર પાસે સ્થિર link-local સરનામું હોય ત્યારે તે વાજબી જવાબ છે. તમે શું છોડી રહ્યા છો તે સ્પષ્ટ રાખો. સ્થિર ડિફોલ્ટ રૂટ ક્યારેય નવો થતો નથી અને ક્યારેય પાછો ખેંચાતો નથી, તેથી ઉપરનો ભાગ બદલાયા પછી પણ તે મૃત પડોશી તરફ ઇશારો કરતો રહે છે. RA નો રૂટ સુરક્ષિત રીતે નિષ્ફળ જાય છે; સ્થિર ચૂપચાપ નિષ્ફળ જાય છે.

ફોરવર્ડ થયેલું પેકેટ ચકાસો, ગેટવેનું પોતાનું નહીં

ગેટવેના પોતાના પિંગ એવા રૂટ પર સફળ થઈ શકે છે જે કોઈ ક્લાયન્ટ વાપરી ન શકે, અને તેઓ એટલા માટે પણ સફળ થઈ શકે કે ગેટવે જ સ્રોત છે. જોડાયેલા ક્લાયન્ટથી ચકાસો, પછી ગેટવેને પૂછો કે તે એ ક્લાયન્ટના સરનામા માટે શું કરશે:

# on the VPN client
ping -6 -c 3 2001:4860:4860::8888

# on the gateway, using a client address
ip -6 route get 2001:4860:4860::8888 from fd42:20::2

પછી એક રાઉટર આયુ રાહ જુઓ અને ફરી જુઓ. જે સ્થિર સ્થિતિ જોઈએ છે તે proto ra થી ચિહ્નિત ડિફોલ્ટ રૂટ છે જેનું expires મૂલ્ય વારંવાર રીસેટ થાય છે, સાથે all.forwarding=1. જો expires ફક્ત ઊંધી ગણતરી કરે છે તો જાહેરાતો હજી ક્યાંક કાઢી નાખવામાં આવે છે, અને સામાન્ય દોષિત એ નેટવર્ક મેનેજર છે જે બૂટ વખતનું sysctl ચાલી ગયા પછી accept_ra ફરી લખે છે.

આ બંધ કરતાં પહેલાં ચાર વસ્તુઓની પુષ્ટિ કરો: ડિફોલ્ટ રૂટ proto ra છે અને નવો થઈ રહ્યો છે, accept_ra=2 ફક્ત અપલિંકને લાગુ પડે છે, રીબૂટ પછી અને મેનેજર રીસ્ટાર્ટ પછી પણ ફોરવર્ડિંગ 1 છે, અને IPv6 પિંગ ક્લાયન્ટ પૂરું કરે છે, ગેટવે નહીં. તંદુરસ્ત રૂટ હોવા છતાં ક્લાયન્ટ નિષ્ફળ જાય તો આગળનો શંકાસ્પદ પરતનો રસ્તો અથવા ઉપરનો ફાયરવોલ છે, જાહેરાત નહીં.