સાઇટ-થી-સાઇટ VPN આખું IPv6 પ્રીફિક્સ ડેલિગેશન: ચેકલિસ્ટ
સાઇટ-થી-સાઇટ VPN આખું ડેલિગેટ કરેલું IPv6 પ્રીફિક્સ રાઉટ કરવા માટેની ચકાસણીઓ: પ્રીફિક્સ નકશો, ટ્રાફિક સિલેક્ટર, ફોરવર્ડિંગ, MTU, પરત માર્ગ અને ફરી-નંબરિંગ.
ટનલ ઊભી કરવી એ સહેલો અડધો ભાગ છે. મેં જોયું છે કે સાઇટ-થી-સાઇટ લિંક દિવસો સુધી સ્થાપિત રહે છે જ્યારે દૂરના LAN પરનું દરેક હોસ્ટ જવાબમાં મૌન જ પામે છે, કારણ કે તે ગેટવે પાછળનું ડેલિગેટ કરેલું પ્રીફિક્સ ઇન્ટરફેસ પર ગોઠવેલું હતું પણ ક્યારેય ટનલમાં રાઉટ થયું નહોતું. ટનલના સરનામાં આખો સમય પિંગનો જવાબ આપતાં રહ્યાં, અને તેથી જ કોઈએ પ્રીફિક્સ તરફ જોયું નહીં. જ્યારે ડેલિગેટ કરેલા IPv6 પ્રીફિક્સને સાઇટ VPN પાર કરવું પડે ત્યારે હું આ ક્રમમાં ચકાસું છું: પ્રીફિક્સ નકશો, ટ્રાફિક સિલેક્ટર, ફોરવર્ડિંગ અને ફાયરવોલ, અને પછી પરત માર્ગ.
ટનલને સ્પર્શ કરતા પહેલાં પ્રીફિક્સ નકશો લખો
પ્રીફિક્સ ડેલિગેશન બ્લોક તે રાઉટરને આપે છે જેણે તેની વિનંતી કરી હતી. તે પીઅર પર રાઉટ ઇન્સ્ટોલ કરતું નથી, તે બ્લોકને લિંક પર લંબાવતું નથી, અને દૂરના ગેટવેને કહેતું નથી કે વિનંતી કરનાર રાઉટર પાછળ શું છે. એ ત્રણ વસ્તુઓ તમારે ગોઠવવાની છે, અને કોઈપણ કન્ફિગ ફાઇલ બદલાય તે પહેલાં એ સરનામાં યોજનામાં હોવી જોઈએ.
દરેક સાઇટ માટે ડેલિગેટ કરેલું પ્રીફિક્સ, LAN પર ખરેખર વપરાતું /64, ટનલના સરનામાં અને દરેક રાઉટનો માલિક નોંધો. પ્રોવાઇડર સાઇટ A ને 2001:db8:a1::/56 ડેલિગેટ કરે છે, જે તેના LAN પર 2001:db8:a1:10::/64 સેવા આપે છે; સાઇટ B 2001:db8:b2::/64 રાખે છે. જો સાઇટ A ફક્ત એ જ એક /64 સેવા આપે, તો બંને છેડાએ આખા /56 ને બદલે 2001:db8:a1:10::/64 લખવું જોઈએ.
લગભગ દરેક વખતે બે ભૂલો દેખાય છે. એક એ છે કે દૂરના પ્રીફિક્સને લિંક પરનું માની લેવું, તેને બ્રિજ કરવું અથવા ટનલ ઇન્ટરફેસ પર મૂકવું જેથી ગેટવે એ હોસ્ટ માટે પડોશી વિનંતીનો જવાબ આપે જે સુધી પહોંચી શકતું નથી. બીજી એ છે કે ફક્ત એક /64 ગોઠવેલું હોય ત્યારે આખું /56 જાહેર કરવું: રાઉટ કોષ્ટક દાવો કરે છે કે બ્લોક પહોંચી શકાય તેવો છે અને મોટા ભાગનાં સરનામાં કાળા કૂવામાં પડે છે.
બંને છેડાના ટ્રાફિક સિલેક્ટરને રાઉટ સાથે મેળવો
IKEv2 અને WireGuard બંને અસંગત ટ્રાફિક નકારે છે, એટલા શાંતિથી કે ટનલ હજી સ્વસ્થ દેખાય.
strongSwan માં સિલેક્ટર સ્પષ્ટ હોય છે. સાઇટ A પર:
conn a-to-b
left=2001:db8:ff::1
leftsubnet=2001:db8:a1:10::/64
right=2001:db8:ff::2
rightsubnet=2001:db8:b2::/64
auto=startસાઇટ B નું conn બંને સબનેટનું પ્રતિબિંબ છે. જ્યારે તેઓ મેળ ખાતા નથી, ત્યારે રિસ્પોન્ડર TS_UNACCEPTABLE સાથે CHILD_SA નકારે છે, તેથી IKE_SA ઊભું થયું હોવા છતાં ચાઇલ્ડ SA ક્યારેય ઊભું થતું નથી. બંને બાજુએ ગોઠવેલું સબનેટ સ્થાનિક કર્નલ ટનલ તરફ જે રાઉટ કરે છે તેની સમાન હોવું જોઈએ.
WireGuard એ જ માહિતી AllowedIPs માં વહન કરે છે, એક વળાંક સાથે: AllowedIPs સ્વીકારમાં સ્રોત ફિલ્ટર છે અને મોકલવામાં રાઉટ પણ છે. જો સાઇટ B ની સાઇટ A માટેની પીઅર એન્ટ્રી 2001:db8:a1:10::/64 છોડી દે, તો સાઇટ A ના પેકેટ માન્ય હેન્ડશેક પર આવે છે અને મંજૂર ન હોવાથી કાઢી નાખવામાં આવે છે. એથી એ જાણીતી પેટર્ન બને છે: હેન્ડશેક સતત નવીકરણ પામે છે પણ કોઈ જવાબ ક્યારેય બહાર જતો નથી. બંને છેડાને wg show wg0 allowed-ips વડે સરખાવો. ડેલિગેશન બદલાય ત્યારે એ યાદી ફરી ચકાસો; જૂનું /64 સત્રને ચાલુ રાખે છે અને નવું પ્રીફિક્સ પહોંચાતું નથી.
પહેલાં ફોરવર્ડિંગ, ફાયરવોલ અને MTU બાકાત કરો
બીજી લોગ લાઇન વાંચતા પહેલાં ખાતરી કરો કે ગેટવે બિલકુલ ફોરવર્ડ કરે છે. sysctl net.ipv6.conf.all.forwarding એ બંને પર 1 પરત આપવો જોઈએ, ટનલ અને LAN ઇન્ટરફેસ પર પણ લાગુ કરીને. સાથે એક જાળ આવે છે: ફોરવર્ડિંગ ચાલુ થતાં જ accept_ra=1 વાળું ઇન્ટરફેસ પ્રોવાઇડરના રાઉટર જાહેરાત સ્વીકારવાનું બંધ કરે છે, તેથી બોક્સ ટનલની અંદર સંપૂર્ણ રાઉટ કરતું હોવા છતાં ઉપરનો ડિફોલ્ટ રાઉટ ગુમાવી શકે છે. જ્યાં પ્રોવાઇડર RA હજી જરૂરી હોય ત્યાં accept_ra=2 રાખો.
પછી ફાયરવોલ નિયમોએ પ્રીફિક્સને બંને દિશામાં મંજૂરી આપવી જોઈએ, અને ICMPv6 ટકી રહેવું જોઈએ: પડોશી શોધ, પેકેટ-ખૂબ-મોટું અને ગંતવ્ય-અપહોંચ એ વૈકલ્પિક નથી. એ ફેંકી દો તો પથ MTU શોધ તૂટે છે, અને એવા કનેક્શન મળે છે જે ખૂલે છે અને પછી પહેલા મોટા જવાબ પર અટકી જાય છે. ન્યૂનતમ નિયમ જોડ આવો દેખાય છે:
nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } acceptMTU એની પાછળ છે. ટનલ વાપરી શકાય તેવું MTU 1500 થી નીચે ઘટાડે છે, અને IPv6 માંગે છે કે દરેક લિંક ઓછામાં ઓછું 1280 વહન કરે. નાના પિંગ પસાર થાય છે, મોટા ઝાપટા પર SSH સત્ર થીજી જાય છે, અને /proc/net/snmp6 એ પેકેટ-ખૂબ-મોટું સંદેશા દર્શાવે છે જે ક્યારેય પાછા આવતા નથી. ટનલનું MTU સ્પષ્ટ રીતે સેટ કરો, અથવા mangle કોષ્ટકમાં TCP MSS ક્લેમ્પ કરો, અને નાનું MTU જણાવતા ICMPv6 ને પાછા આવવા દો.
ટનલનું સરનામું નહીં, પરત માર્ગ ચકાસો
સૌથી વધુ સમય ખર્ચાવતી નિષ્ફળતા એકતરફી રાઉટિંગ છે. દરેક ગેટવે દૂરના પ્રીફિક્સને ટનલમાં રાઉટ કરે છે, પણ હોસ્ટ પોતાના ડિફોલ્ટ ગેટવે દ્વારા જવાબ આપે છે કારણ કે તેમનું /64 ત્યાં જ રહે છે. પેકેટને ગંતવ્ય સુધી પહોંચાડવું એ અડધો જ માર્ગ છે.
| What you see | Likely cause | First check |
|---|---|---|
| Tunnel up, every host silent | remote prefix not routed into the tunnel | ip -6 route get on both gateways |
| Handshake renews, no replies | source prefix missing from selectors or AllowedIPs | ipsec statusall, wg show allowed-ips |
| Small pings pass, transfers stall | MTU or ICMPv6 packet-too-big filtered | /proc/net/snmp6 counters |
| Old prefix still works | stale /64 left in routes or selectors | delegation lease and route table |
બે આદેશો મોટા ભાગનું નક્કી કરે છે. સાઇટ A પર ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 દર્શાવે છે કે તે સ્રોત તરફથી આવતો જવાબ કયું ઇન્ટરફેસ વાપરશે; સાઇટ B પર અરીસા-ચકાસણી કરો. પછી ગેટવેને બદલે હોસ્ટ પરથી ટ્રાફિક ઉત્પન્ન કરો અને બંને છેડે કાઉન્ટર સરખાવો.
જો દૂરના પ્રીફિક્સ માટે પડોશી વિનંતી ટનલ પર દેખાય, તો એ પ્રીફિક્સ એવી જગ્યાએ લિંક પર છે જ્યાં તે ન હોવું જોઈએ; રાઉટ સમાવતા પહેલાં એ સુધારો. Proxy NDP એ એવા કિસ્સા આવરે છે જ્યાં બ્રિજિંગ ખરેખર જરૂરી છે, એ રાઉટનો વિકલ્પ નથી.
તમારા પગ નીચે પ્રીફિક્સ બદલાય તેની યોજના કરો
પ્રીફિક્સ ડેલિગેશન એ ડેલિગેટ કરનાર અને વિનંતી કરનાર રાઉટર વચ્ચેનું ભાડું છે, અને નવીકરણ બીજો બ્લોક પરત આપી શકે છે: પ્રોવાઇડર સ્થળાંતર પછી બીજું /56, અથવા ટનલ જેટલા સમયથી ઊભી છે તેનાથી ટૂંકું ભાડું. જૂનું પ્રીફિક્સ નામ આપતું દરેક સ્થળ એકસાથે જૂનું થઈ જાય છે: રાઉટ, સિલેક્ટર, AllowedIPs, ફાયરવોલ નિયમો, DNS રેકોર્ડ અને શાબ્દિક સરનામાં હાર્ડકોડ કરતું કોઈપણ મોનિટરિંગ. સંદેશ પ્રવાહ આમાં છે: RFC 8415.
જ્યાં પ્રીફિક્સ ખસેડવાની અપેક્ષા હોય, ત્યાં તેના પર આધારિત ન હોય એવી આંતરિક સરનામાં યોજના રાખો અને સીમા પર અનુવાદ કરો. NPTv6 સ્થિતિ-રહિત વિકલ્પ છે અને આંતરિક નીતિ વાંચી શકાય તેવી રાખે છે, પણ એ પ્રીફિક્સ અનુવાદ છે, જાદુઈ સ્તર નથી: /64 સીમાઓ મેળ ખાવી જોઈએ, ચેકસમ ગોઠવાય છે, અને શાબ્દિક સરનામાં સમાવતી એપ્લિકેશનો હજી તૂટે છે. જો તમે પ્રોવાઇડરના સરનામાં શરૂઆતથી અંત સુધી રાખો, તો ભાડાનું વર્તન અને બદલાવ પ્રક્રિયા સરનામાં યોજનામાં નોંધો.
સમય સામે ટકી રહે તેવી કસોટીથી અંત કરો: દરેક LAN પરનું મંજૂર હોસ્ટ બીજા LAN પરની સેવા સુધી પહોંચે છે, જવાબ ટનલ દ્વારા પાછો આવે છે, અને ટનલ પુનઃશરૂ કર્યા તથા ડેલિગેશન નવીકરણ પછી પણ એ જ જોડી કામ કરે છે. જો છેલ્લો ભાગ નિષ્ફળ જાય, તો ડિઝાઇન એવી સ્થિતિ પર આધારિત છે જે અઠવાડિયું ટકશે નહીં.