IPv6 maršrutēšana starp divām vietnēm esošā VPN

WAN ar tikai IPv4 joprojām var pārnēsāt iekšējo IPv6. Sekojiet selektoriem, kodola maršrutiem, pāradresācijai un atgriešanās prefiksam, kas klusi izmet atbildes.

Kad pievienojat IPv6 prefiksu vietnes-uz-vietni tunelim, pakete neceļo tā, kā liecina diagramma. Vietējā vārteja paņem visu IPv6 paketi, šifrē to un priekšā liek ārēju IP galveni, kuras adrešu saimi nosaka galapunktu adreses, nevis tas, kas atrodas iekšpusē. Tālā vārteja noņem šo ārējo galveni un pārsūta sākotnējo paketi uz savu LAN, kur tā atkal ir parasta IPv6 pakete. Ārējais tunelis un iekšējā satiksme ir divas atsevišķas sarunas, kas dalās ar atslēgu, galapunktu pāri un nekas cits.

Divas galvenes, divas adrešu saimes

IPsec tuneļa režīmā iekšējā IPv6 pakete kļūst par kravu aiz ESP galvenes. Ārējā galvene, kas pārnēsā šo ESP paketi, var būt IPv4 vai IPv6, un tā seko local_addrs un remote_addrs. WireGuard dara to pašu ar mazāk ceremoniju: iekšējā pakete ir UDP datagrammas krava uz partnera galapunktu. Abas atstāj iekšējo galveni neskartu, tāpēc tālā puse var to maršrutēt pēc dekapsulācijas.

Ceļš starp vietnēm redz tikai UDP 4500, kad IPsec izmanto NAT caurejošanu, vai UDP 51820 noklusējuma WireGuard klausītājam. Jebkurš maršrutētājs ceļā var būt tikai IPv4, un IPv6 satiksme tomēr šķērso, jo tā šajā ceļā nekad neparādās kā IPv6 pakete. Tas dod tīru pirmo dalījumu: tcpdump -ni eth0 udp port 51820 parāda šifrēto ceļu, tcpdump -ni wg0 ip6 parāda iekšējo satiksmi. Aizņemts ārējs uztveršanas fails ar klusu iekšējo nozīmē, ka kodols neliek IPv6 tunelī; tas ir maršrutēšana vai politika, nevis saites stāvoklis.

Vārteja arī samazina iekšējo Hop Limit, kad pārsūta, tāpēc galapunkti skaitās maršrutētāji IPv6 ceļā. Ārējais hopu skaits un iekšējais Hop Limit kustas neatkarīgi, un pakete, kas mirst tālajā vārtējā, mira pārsūtīšanā, nevis šifrēšanā.

Selektori un AllowedIPs ir atļauju saraksts

IKEv2 pārrunā, kurus iekšējos prefiksus child SA drīkst pārnēsāt. StrongSwan 5.9 un vēlākās versijās to ierakstīšana swanctl.conf izskatās šādi:

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

Ja izlaižat local_ts un remote_ts, strongSwan atvasina tos no izvēlētās saskarnes apakštīkliem. Dual-stack resursdatorā šis īsinājums bieži dod pāri tikai IPv4: SA paceļas un IPv6 tiek noraidīts, pirms tas sasniedz ESP kodu. Abu prefiksu ierakstīšana padara SA spējīgu tos pārnēsāt, un start_action = trap paceļ to pirmajā atbilstošajā paketē.

WireGuard ir viens saraksts, kas veic divus darbus. Partnera blokā AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 ir gan sūtīšanas laikā uzstādītais maršruts, gan saņemšanas laikā piemērotais filtrs: šifrēta pakete, kuras iekšējais avots krīt ārpus šī partnera saraksta, tiek klusi izmesta. wg-quick pievieno maršrutu katram ierakstam, tāpēc zemāk esošajam partnera blokam nav vajadzīga atsevišķa ip -6 route komanda.

[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

Abiem sarakstiem jābūt spoguļattēlam: vieta B pieņem vietas A prefiksu kā tālu selektoru un maršrutē to atpakaļ, un tunelis darbojas tikai tad, kad abi virzieni saskan. Asimetrisks saraksts dod simptomu, kas aizņem visvairāk laika — veselīgs rokasspiediens, skaitītāji kustas vienā pusē, un ping no A uz B, kas izdodas, kamēr nekas no B nesasniedz A.

Pārsūtīšana, maršruti un atgriešanās prefikss

Linux nepārsūta IPv6, kamēr nepasakāt, un iestatījums attiecas uz namespace, nevis uz saskarni:

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

Otrā rinda ir tas, ko cilvēki aizmirst maršrutā balstītos projektos. Uz politiku balstīts IPsec uzstāda XFRM politiku, kas atbilst prefiksiem, bet uz maršrutu balstīta konfigurācija ar vti6 vai WireGuard ir nepieciešams īsts IPv6 maršruts, kas norāda uz šo ierīci. Saglabājiet sysctl failā /etc/sysctl.d/; pretējā gadījumā pārstartēšana klusi atgriež pārsūtīšanu uz izslēgtu.

Pārsūtīšanai ir blakusefekts, ko ir vērts zināt: kodols tad ignorē maršrutētāju paziņojumus, ja vien net.ipv6.conf.<wan>.accept_ra nav 2, tāpēc vārteja, kuras WAN adrese nāk caur SLAAC, var zaudēt savu noklusējuma maršrutu tajā brīdī, kad ieslēdzat pārsūtīšanu. Iesestat accept_ra = 2 šajā saskarnē tajā pašā failā, un maršruts izdzīvo. Vietas B kodolam arī jāapgūst 2001:db8:aa::/48 no tuneļa vārtejas, izmantojot statisku maršrutu vai maršrutēšanas protokolu virs tuneļa, citādi atbilde mirst pašas B tīklā.

Četru posmu pārbaude, kas lokalizē lūzumu

Strādājiet šajā secībā un apstājieties pirmajā posmā, kas neizdodas, jo katrs nākamais posms ir atkarīgs no iepriekšējiem.

  1. Selektori: swanctl --list-sas jārāda IPv6 prefiksu pāris uz child SA, vai wg show wg0 allowed-ips attālais prefikss ar svaigu latest-handshakes.
  2. Kodola maršruts: ip -6 route get 2001:db8:bb::10 jāatbild ar tuneļa ierīci, nevis ar WAN saskarni.
  3. Iekšēja uztveršana: tcpdump -ni wg0 ip6 kamēr pingojat starp īstiem LAN resursdatoriem. Paketes, kas iziet, bet neviena neatgriežas, norāda uz B maršrutu vai ugunsmūri; pavisam nekādas paketes norāda atpakaļ uz posmu 1 vai 2.
  4. Galamērķis: uz B resursdatora ss -6 -ltn apstiprina, ka pakalpojums klausās IPv6, un vietējie ugunsmūra skaitītāji rāda, vai pakete tika pieņemta vai izmesta.

MTU ietilpst tajā pašā piegājienā. IPv6 maršrutētāji nedala, tāpēc pārāk liela pakete tiek izmesta un Packet Too Big atgriežas pie sūtītāja. Ja rokasspiedieni un mazi pingi darbojas, bet failu pārsūtīšana iestrēgst, samaziniet kravu, līdz tā pāriet: ping -6 -s 1400 -c 3 2001:db8:bb::10. WireGuard saskarnēm pēc noklusējuma ir 1420 baitu MTU, un IPsec virs IPv4 atņem vairāk, tāpēc iekšējā MTU iestatīšana ir labāka par cerību uz ceļa MTU atklāšanu caur ugunsmūri, kas izmet ICMPv6.

Kļūdu režīmi, kas izskatās pēc ugunsmūra problēmām

Visizplatītākais nemaz nav ugunsmūris: pakalpojums piesaistās 0.0.0.0 vietā ::, AAAA ieraksts pastāv, un klients saņem ātru atteikumu IPv6, ko dual-stack pārlūks slēpj, atgriežoties pie IPv4. Ja neizdodas tikai dažas lietojumprogrammas, pārbaudiet klausošo saimi, pirms pieskaraties noteikumu kopai.

Otrais ir ICMPv6 filtrēšana. Neighbor Discovery un Packet Too Big ir daļa no parastas darbības, nevis diagnostikas, un politika, kas izmet visu ICMPv6, rada tuneli, kas savienojas, autentificējas un pēc tam iestrēgst uz visa, kas lielāks par mazu paketi. Atļaujiet veidus, no kuriem ceļš ir atkarīgs, un atstājiet skaitītājus ieslēgtus, lai izmešana būtu redzama.

Trešais ir prefikss, kas pievienots tunelim, bet nekad nav pievienots tās vietnes adrešu plānam, kurai tas pieder, tāpēc neviens maršrutētājs to neizziņo un neviens resursdators nevar no tā atbildēt. Sāciet ar vienu prefiksu un vienu resursdatoru pāri, pierādiet abus virzienus ar četriem posmiem, pēc tam pievienojiet pārējo; bojāts prefikss paliek viena rinda konfigurācijā, nevis pārprojektēšana. Vienīgā oficiālā atsauce, ko ir vērts turēt atvērtu, ir RFC 8200, kas definē galveni, ko tunelis pārnēsā.

Saistītie raksti