બે સાઇટ વચ્ચે હાલના VPN દ્વારા IPv6 રૂટિંગ

ફક્ત IPv4 ધરાવતું WAN પણ આંતરિક IPv6 વહન કરી શકે છે. સિલેક્ટર, કર્નલ રૂટ, ફોરવર્ડિંગ અને જવાબો ચૂપચાપ ફેંકી દેતું પરત પ્રીફિક્સ અનુસરો.

જ્યારે તમે બે સાઇટ વચ્ચેના ટનલમાં IPv6 પ્રીફિક્સ ઉમેરો છો, ત્યારે પેકેટ આકૃતિ સૂચવે તેમ મુસાફરી કરતું નથી। સ્થાનિક ગેટવે આખું IPv6 પેકેટ લે છે, તેને એન્ક્રિપ્ટ કરે છે અને તેની આગળ બહારનું IP હેડર મૂકે છે જેનું સરનામું કુટુંબ અંદરની સામગ્રીથી નહીં, પણ છેડાના સરનામાંથી નક્કી થાય છે। દૂરનું ગેટવે તે બહારનું હેડર હટાવે છે અને મૂળ પેકેટ પોતાના LAN પર મોકલે છે, જ્યાં તે ફરી સામાન્ય IPv6 પેકેટ છે। બહારનું ટનલ અને અંદરનું ટ્રાફિક બે અલગ વાતચીત છે જે એક કી, એક છેડા જોડી અને આ સિવાય કંઈ શેર કરતી નથી।

બે હેડર, બે સરનામા કુટુંબ

IPsec ટનલ મોડમાં અંદરનું IPv6 પેકેટ ESP હેડર પાછળનું પેલોડ બને છે। તે ESP પેકેટ વહન કરતું બહારનું હેડર IPv4 અથવા IPv6 હોઈ શકે છે અને local_addrs તથા remote_addrs અનુસરે છે। WireGuard તે જ કામ ઓછી વિધિથી કરે છે: અંદરનું પેકેટ સાથીના છેડા તરફ જતા UDP ડેટાગ્રામનું પેલોડ છે। બંને અંદરનું હેડર અડીને રાખે છે, તેથી દૂરની બાજુ ડીકેપ્સ્યુલેશન પછી તેને રૂટ કરી શકે છે।

સાઇટ વચ્ચેનો રસ્તો ફક્ત UDP 4500 જુએ છે જ્યારે IPsec NAT ટ્રાવર્સલ વાપરે છે, અથવા ડિફોલ્ટ WireGuard શ્રોતા માટે UDP 51820। રસ્તા પરનો કોઈ પણ રાઉટર ફક્ત IPv4 હોઈ શકે છે અને IPv6 ટ્રાફિક તો પણ પસાર થાય છે, કારણ કે તે તે રસ્તા પર ક્યારેય IPv6 પેકેટ તરીકે દેખાતું નથી। તે સ્વચ્છ પ્રથમ વિભાજન આપે છે: tcpdump -ni eth0 udp port 51820 એન્ક્રિપ્ટેડ રસ્તો દર્શાવે છે, tcpdump -ni wg0 ip6 અંદરનું ટ્રાફિક દર્શાવે છે। બહારનું કેપ્ચર વ્યસ્ત અને અંદરનું શાંત હોય તો અર્થ છે કે કર્નલ IPv6 ટનલમાં નાખતું નથી; તે રૂટિંગ કે નીતિ છે, લિંકની સ્થિતિ નહીં।

ગેટવે ફોરવર્ડ કરતી વખતે અંદરની Hop Limit પણ ઘટાડે છે, તેથી છેડા IPv6 રસ્તા પર રાઉટર ગણાય છે। બહારની હોપ સંખ્યા અને અંદરની Hop Limit અલગ અલગ ચાલે છે, અને દૂરના ગેટવે પર મરતું પેકેટ ફોરવર્ડિંગમાં મર્યું, એન્ક્રિપ્શનમાં નહીં।

સિલેક્ટર અને AllowedIPs પરવાનગી યાદી છે

IKEv2 નક્કી કરે છે કે child SA કઈ આંતરિક પ્રીફિક્સ વહન કરી શકે। strongSwan 5.9 અને પછી તેમને swanctl.conf માં લખવા આમ દેખાય છે:

children {
  net6 {
    local_ts  = 2001:db8:aa::/48
    remote_ts = 2001:db8:bb::/48
    mode = tunnel
    esp_proposals = aes256gcm16-prfsha384-ecp384
    start_action = trap
  }
}

જો local_ts અને remote_ts છોડી દો તો strongSwan તેમને પોતાના પસંદ કરેલા ઇન્ટરફેસના સબનેટમાંથી કાઢે છે। ડ્યુઅલ સ્ટેક હોસ્ટ પર તે શોર્ટકટ ઘણી વાર ફક્ત IPv4 ની જોડી આપે છે: SA ઉપર આવે છે અને IPv6 ESP કોડ સુધી પહોંચતા પહેલા નકારવામાં આવે છે। બંને પ્રીફિક્સ લખવાથી SA તેમને વહન કરવા સક્ષમ બને છે, અને start_action = trap તેને પહેલા મળતા પેકેટ પર ઉપર લે છે।

WireGuard પાસે એક જ યાદી છે જે બે કામ કરે છે। સાથી બ્લોકમાં AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 મોકલતી વખતે બેસાડેલો રસ્તો પણ છે અને મેળવતી વખતે લગાવેલો ફિલ્ટર પણ: જે ડીક્રિપ્ટ થયેલા પેકેટનો આંતરિક સ્રોત તે સાથીની યાદી બહાર પડે છે તે ચૂપચાપ ફેંકી દેવાય છે। wg-quick દરેક નોંધ માટે રસ્તો ઉમેરે છે, તેથી નીચેના સાથી બ્લોકને અલગ ip -6 route આદેશની જરૂર નથી।

[Interface]
Address = 2001:db8:aa:ff::1/64, fd00:aa:ff::1/64
ListenPort = 51820

[Peer]
PublicKey = <site-b-public-key>
Endpoint = 203.0.113.20:51820
AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48

બંને યાદી અરીસા જેવી હોવી જોઈએ: સાઇટ B સાઇટ A નું પ્રીફિક્સ દૂરનું સિલેક્ટર માની સ્વીકારે છે અને તેને પાછું રૂટ કરે છે, અને ટનલ ત્યારે જ ચાલે છે જ્યારે બંને દિશા સહમત હોય। અસમમિત યાદી તે લક્ષણ આપે છે જે સૌથી વધુ સમય લે છે — સ્વસ્થ હેન્ડશેક, એક બાજુ ચાલતા કાઉન્ટર, અને A થી B સુધી સફળ ping જ્યારે B થી કંઈ પણ A સુધી પહોંચતું નથી।

ફોરવર્ડિંગ, રૂટ અને પરત પ્રીફિક્સ

Linux તમે કહો ત્યાં સુધી IPv6 ફોરવર્ડ કરતું નથી, અને સેટિંગ ઇન્ટરફેસને બદલે namespace પ્રમાણે છે:

sysctl -w net.ipv6.conf.all.forwarding=1
ip -6 route add 2001:db8:bb::/48 dev wg0
ip -6 route get 2001:db8:bb::10 from 2001:db8:aa::10

બીજી લાઇન તે જ છે જે રૂટ આધારિત ડિઝાઇનમાં લોકો ભૂલી જાય છે। નીતિ આધારિત IPsec પ્રીફિક્સ સાથે મળતી XFRM નીતિ સ્થાપિત કરે છે, પણ vti6 કે WireGuard વાળી રૂટ આધારિત ગોઠવણને તે ઉપકરણ તરફ ઇશારો કરતો ખરો IPv6 રસ્તો જોઈએ। sysctl ને /etc/sysctl.d/ નીચે ટકાઉ રાખો; નહીં તો ફરી બૂટ ફોરવર્ડિંગ ચૂપચાપ બંધ કરે છે।

ફોરવર્ડિંગની એક આડઅસર છે જે જાણવા જેવી છે: કર્નલ ત્યારે રાઉટર જાહેરાતો અવગણે છે જ્યાં સુધી net.ipv6.conf.<wan>.accept_ra 2 ન હોય, તેથી જે ગેટવેનું WAN સરનામું SLAAC દ્વારા આવે છે તે ફોરવર્ડિંગ ચાલુ કરો તે ક્ષણે પોતાનો ડિફોલ્ટ રસ્તો ગુમાવી શકે છે। તે જ ફાઇલમાં તે ઇન્ટરફેસ પર accept_ra = 2 સેટ કરો અને રસ્તો ટકી રહે છે। સાઇટ B ના કોરને પણ ટનલ ગેટવેથી 2001:db8:aa::/48 શીખવું પડે, સ્થિર રસ્તા કે ટનલ પરના રૂટિંગ પ્રોટોકોલ દ્વારા, નહીં તો જવાબ B ના પોતાના નેટવર્કમાં મરે છે।

ભંગનું સ્થાન શોધતી ચાર પગલાંની ચકાસણી

આ ક્રમમાં કામ કરો અને પહેલા નિષ્ફળ પગલે થોભો, કારણ કે દરેક આગળનું પગલું પાછલાં પર આધારિત છે।

  1. સિલેક્ટર: swanctl --list-sas એ child SA પર IPv6 પ્રીફિક્સની જોડી દર્શાવવી જોઈએ, અથવા wg show wg0 allowed-ips એ દૂરનું પ્રીફિક્સ તાજા latest-handshakes સાથે।
  2. કર્નલ રૂટ: ip -6 route get 2001:db8:bb::10 એ ટનલ ઉપકરણ સાથે જવાબ આપવો જોઈએ, WAN ઇન્ટરફેસ સાથે નહીં।
  3. આંતરિક કેપ્ચર: tcpdump -ni wg0 ip6 ખરા LAN હોસ્ટ વચ્ચે ping કરતી વખતે। જે પેકેટ બહાર જાય પણ એક પણ પાછું ન આવે તે B ના રસ્તા કે ફાયરવોલ તરફ ઇશારો કરે છે; બિલકુલ પેકેટ ન હોવું પગલું 1 કે 2 તરફ પાછું ઇશારો કરે છે।
  4. ગંતવ્ય: B હોસ્ટ પર ss -6 -ltn પુષ્ટિ કરે છે કે સેવા IPv6 પર સાંભળે છે, અને સ્થાનિક ફાયરવોલ કાઉન્ટર બતાવે છે કે પેકેટ સ્વીકારાયું કે ફેંકાયું।

MTU તે જ રાઉન્ડમાં આવે છે। IPv6 રાઉટર ખંડન કરતા નથી, તેથી વધુ મોટું પેકેટ ફેંકાય છે અને Packet Too Big મોકલનાર પાસે પાછું આવે છે। જો હેન્ડશેક અને નાના ping ચાલે પણ ફાઇલ સ્થાનાંતરણ અટકે, તો પેલોડ ઘટાડો જ્યાં સુધી તે પસાર ન થાય: ping -6 -s 1400 -c 3 2001:db8:bb::10। WireGuard ઇન્ટરફેસનું ડિફોલ્ટ MTU 1420 બાઇટ છે અને IPv4 પર IPsec વધુ કાપે છે, તેથી આંતરિક MTU સેટ કરવું ICMPv6 ફેંકતા ફાયરવોલમાંથી રસ્તાનું MTU શોધવાની આશા કરતાં સારું છે।

ફાયરવોલની સમસ્યા જેવા દેખાતા નિષ્ફળતાના પ્રકાર

સૌથી સામાન્ય તો ફાયરવોલ જ નથી: સેવા :: ને બદલે 0.0.0.0 સાથે બંધાય છે, AAAA રેકોર્ડ અસ્તિત્વમાં છે, અને ગ્રાહકને IPv6 પર ઝડપી ઇનકાર મળે છે જે ડ્યુઅલ સ્ટેક બ્રાઉઝર IPv4 પર પાછા જઈ છુપાવે છે। જો ફક્ત કેટલાક એપ્લિકેશન નિષ્ફળ થાય, તો નિયમસમૂહને અડકતા પહેલા સાંભળતું કુટુંબ તપાસો।

બીજું ICMPv6 ફિલ્ટરિંગ છે। Neighbor Discovery અને Packet Too Big સામાન્ય કામગીરીનો ભાગ છે, નિદાનનો નહીં, અને જે નીતિ બધું ICMPv6 ફેંકે છે તે એવું ટનલ બનાવે છે જે જોડાય, પ્રમાણિત થાય અને પછી નાના પેકેટ કરતાં મોટી દરેક વસ્તુ પર અટકે। જે પ્રકારો પર રસ્તો આધારિત છે તેમને પરવાનગી આપો અને કાઉન્ટર ચાલુ રાખો જેથી ફેંકવું દેખાય।

ત્રીજું તે પ્રીફિક્સ છે જે ટનલમાં ઉમેરાય છે પણ જે સાઇટની માલિકી છે તેના સરનામા પ્લાનમાં ક્યારેય ઉમેરાતું નથી, તેથી કોઈ રાઉટર તેની જાહેરાત કરતું નથી અને કોઈ હોસ્ટ તેમાંથી જવાબ આપી શકતું નથી। એક પ્રીફિક્સ અને એક હોસ્ટ જોડીથી શરૂ કરો, બંને દિશા ચાર પગલાંથી સાબિત કરો, પછી બાકીનું ઉમેરો; બગડેલું પ્રીફિક્સ ફરી ડિઝાઇનને બદલે રૂપરેખામાં એક લાઇન રહે છે। ખુલ્લું રાખવા લાયક એકમાત્ર સત્તાવાર સંદર્ભ RFC 8200 છે, જે ટનલ વહન કરતું હેડર વ્યાખ્યાયિત કરે છે।

સંબંધિત લેખો