Rrugëtimi i IPv6 midis dy site-ve përmes një VPN ekzistuese

Kur shtoni një prefiks IPv6 në një tunel site-më-site, paketa nuk udhëton siç sugjeron diagrami. Gateway-i lokal merr të gjithë paketën IPv6, e kripton dhe vendos përpara një header IP të jashtëm, familja e adresave të të cilit vendoset nga adresat e pikave fundore, jo nga ajo që ndodhet brenda. Gateway-i i largët heq atë header të jashtëm dhe përçon paketën origjinale në LAN-in e tij, ku ajo është përsëri një paketë IPv6 e zakonshme. Tuneli i jashtëm dhe trafiku i brendshëm janë dy biseda të ndara që ndajnë një çelës, një çift pikash fundore dhe asgjë tjetër.

Dy header-a, dy familje adresash

Në modalitetin tunel IPsec, paketa IPv6 e brendshme bëhet ngarkesa pas një header ESP. Header-i i jashtëm që mban atë paketë ESP mund të jetë IPv4 ose IPv6, dhe ndjek local_addrs dhe remote_addrs. WireGuard bën të njëjtën gjë me më pak ceremoni: paketa e brendshme është ngarkesa e një datagram UDP drejt pikës fundore të peer-it. Të dyja e lënë header-in e brendshëm të paprekur, prandaj ana e largët mund ta rrugëtojë pas dekapsulimit.

Rruga midis site-ve sheh vetëm UDP 4500 kur IPsec përdor NAT traversal, ose UDP 51820 për një dëgjues standard WireGuard. Çdo router në rrugë mund të jetë vetëm IPv4 dhe trafiku IPv6 kalon gjithsesi, sepse nuk shfaqet kurrë si paketë IPv6 në atë rrugë. Kjo jep një ndarje të parë të pastër: tcpdump -ni eth0 udp port 51820 tregon rrugën e kriptuar, tcpdump -ni wg0 ip6 tregon trafikun e brendshëm. Një kapje e jashtme e zënë me një të brendshme të heshtur do të thotë që kernel-i nuk po vendos IPv6 në tunel; ky është rrugëtim ose politikë, jo gjendje e lidhjes.

Gateway-i gjithashtu zvogëlon Hop Limit të brendshëm ndërsa përçon, kështu që pikat fundore numërohen si router-a në rrugën IPv6. Numri i hop-eve të jashtëm dhe Hop Limit i brendshëm lëvizin në mënyrë të pavarur, dhe një paketë që vdes në gateway-in e largët vdiq në përçim, jo në kriptim.

Selektorët dhe AllowedIPs janë lista e lejeve

IKEv2 negocion cilat prefikse të brendshme një child SA mund të mbajë. Në strongSwan 5.9 e më pas, shkrimi i tyre në swanctl.conf duket kështu:

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

Hiqni local_ts dhe remote_ts dhe strongSwan i nxjerr nga subrrjetet e ndërfaqes që zgjedh. Në një host dual-stack ai shkurtim shpesh prodhon një çift vetëm IPv4: SA ngrihet dhe IPv6 refuzohet përpara se të arrijë kodin ESP. Shkrimi i të dy prefikseve e bën SA të aftë t'i mbajë, dhe start_action = trap e ngre në paketën e parë që përputhet.

WireGuard ka një listë të vetme që kryen dy punë. Në bllokun e peer-it, AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 është njëkohësisht rruga e instaluar gjatë dërgimit dhe filtri i aplikuar gjatë marrjes: një paketë e dekriptuar, burimi i brendshëm i të cilës bie jashtë listës së atij peer-i, hidhet në heshtje. wg-quick shton një rrugë për çdo zë, prandaj blloku i peer-it më poshtë nuk ka nevojë për një komandë ip -6 route të veçantë.

[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

Të dyja listat duhet të pasqyrohen: site B pranon prefiksin e site A si selektor të largët dhe e rrugëton mbrapsht, dhe tuneli funksionon vetëm kur të dy drejtimet bien dakord. Një listë asimetrike jep simptomën që harxhon më shumë kohë — një shtrëngim duarsh i shëndoshë, numërues që lëvizin në njërën anë, dhe një ping nga A në B që ka sukses ndërsa asgjë nga B nuk e arrin A.

Përçimi, rrugët dhe prefiksi i kthimit

Linux nuk e përçon IPv6 derisa ta thuash, dhe cilësimi është për namespace, jo për ndërfaqe:

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

Rreshti i dytë është ai që njerëzit harrojnë në modelet e bazuara në rrugë. IPsec i bazuar në politikë instalon një politikë XFRM që përputhet me prefikset, por një konfigurim i bazuar në rrugë me vti6 ose WireGuard ka nevojë për një rrugë reale IPv6 që tregon drejt atij pajisjeje. Vazhdoje sysctl-in nën /etc/sysctl.d/; përndryshe një rindezje e kthen përçimin në të fikur në heshtje.

Përçimi ka një efekt anësor që ia vlen të dihet: kernel-i atëherë i shpërfill njoftimet e router-it, përveç rastit kur net.ipv6.conf.<wan>.accept_ra është 2, kështu që një gateway, adresa WAN e të cilit arrin përmes SLAAC, mund të humbasë rrugën e tij standarde në çastin që aktivizoni përçimin. Vendosni accept_ra = 2 në atë ndërfaqe në të njëjtin skedar dhe rruga mbijeton. Bërthama e site B duhet gjithashtu të mësojë 2001:db8:aa::/48 nga gateway-i i tunelit, përmes një rruge statike ose një protokolli rrugëtimi mbi tunel, përndryshe përgjigja vdes brenda rrjetit të vetë B.

Një kontroll me katër hapa që lokalizon thyerjen

Punoni në këtë rend dhe ndaloni në hapin e parë që dështon, sepse çdo hap i mëvonshëm varet nga ata të mëparshëm.

1. Selektorët: swanctl --list-sas duhet të tregojë çiftin e prefikseve IPv6 në child SA, ose wg show wg0 allowed-ips prefiksin e largët me një latest-handshakes të freskët.
2. Rruga e kernel-it: ip -6 route get 2001:db8:bb::10 duhet të përgjigjet me pajisjen e tunelit, jo me ndërfaqen WAN.
3. Kapja e brendshme: tcpdump -ni wg0 ip6 ndërsa bëni ping midis host-eve reale të LAN-it. Paketat që dalin por asnjë që kthehet tregojnë rrugën ose firewall-in e B; asnjë paketë fare tregon përsëri në hapin 1 ose 2.
4. Destinacioni: në hostin B, ss -6 -ltn konfirmon që shërbimi dëgjon në IPv6, dhe numëruesit lokalë të firewall-it tregojnë nëse paketa u pranua ose u hodh.

MTU bën pjesë në të njëjtin kalim. Router-at IPv6 nuk fragmentojnë, kështu që një paketë tepër e madhe hidhet dhe Packet Too Big kthehet te dërguesi. Nëse shtrëngimet e duarsh dhe ping-et e vogla funksionojnë, por një transferim skedari ngec, zvogëloni ngarkesën derisa të kalojë: ping -6 -s 1400 -c 3 2001:db8:bb::10. Ndërfaqet WireGuard kanë si parazgjedhje një MTU prej 1420 bajtësh dhe IPsec mbi IPv4 heq më shumë, prandaj vendosja e MTU-së së brendshme ia vlen më shumë sesa shpresa për zbulim të MTU-së së rrugës përmes një firewall-i që hedh ICMPv6.

Mode dështimi që duken si probleme firewall-i

Më i zakonshmi nuk është fare firewall: shërbimi lidhet me 0.0.0.0 në vend të ::, rekordi AAAA ekziston, dhe klienti merr një refuzim të shpejtë mbi IPv6 që një shfletues dual-stack e fsheh duke u kthyer te IPv4. Nëse dështojnë vetëm disa aplikacione, kontrolloni familjen e dëgjimit përpara se të prekni një grup rregullash.

I dyti është filtrimi ICMPv6. Neighbor Discovery dhe Packet Too Big janë pjesë e funksionimit normal, jo e diagnostikimit, dhe një politikë që hedh çdo ICMPv6 prodhon një tunel që lidhet, autentikohet dhe më pas ngec në çdo gjë më të madhe se një paketë e vogël. Lejoni llojet nga të cilat varet rruga dhe lini numëruesit ndezur që një hedhje të jetë e dukshme.

I treti është një prefiks i shtuar në tunel, por kurrë në planin e adresave të site-it që e zotëron, kështu që asnjë router nuk e shpall dhe asnjë host nuk mund të përgjigjet prej tij. Filloni me një prefiks dhe një çift host-esh, provoni të dy drejtimet me katër hapat, pastaj shtoni pjesën tjetër; një prefiks i prishur mbetet një rresht në një konfigurim në vend të një rikonstruksioni. Referenca e vetme zyrtare që ia vlen të mbahet hapur është RFC 8200, e cila përcakton header-in që mban tuneli.