IPv6-ны эки аймактын ортосунда бар болгон VPN аркылуу багыттоо

Бир гана 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 аларды өзү тандаган интерфейстин ички тармактарынан чыгарат. Dual-stack хостто бул кыскартуу көбүнчө гана 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 интерфейстери демейки боюнча 1420 байт MTU-га ээ, ал эми IPv4 үстүндөгү IPsec андан да көп алат, ошондуктан ички MTU-ну орнотуу ICMPv6-ны таштаган файрвол аркылуу жол MTU-сун табууну күтүүдөн артык.

Файрвол көйгөйүнө окшош акау режимдери

Эң көп кездешкени такыр файрвол эмес: кызмат :: ордуна 0.0.0.0-га байланышып, AAAA жазуусу бар, ал эми кардар IPv6 аркылуу тез баш тартуу алат, аны dual-stack браузер IPv4-ке кайра өтүп жашырат. Бир гана кээ бир колдонмолор ийгиликсиз болсо, эрежелер жыйынтыгына тийишпестен угуучу топту текшериңиз.

Экинчиси — ICMPv6 чыпкалоо. Neighbor Discovery менен Packet Too Big кадимки иштин бөлүгү, диагностика эмес, ал эми бардык ICMPv6-ны таштаган саясат туташкан, аутентификацияланган, андан кийин кичине пакеттен чоң нерселердин баарында токтоп калган туннель жаратат. Жолго керектүү түрлөргө уруксат бериңиз жана эсептегичтерди күйүк калтырыңыз, ташталганы көрүнүшү үчүн.

Үчүнчүсү — туннелге кошулган, бирок ага ээлик кылган аймактын дарек планына эч качан кошулбаган префикс, ошондуктан эч бир маршрутизатор аны жарыялабайт жана эч бир хост андан жооп бере албайт. Бир префикс жана бир хост жубу менен баштап, эки багытты төрт баскыч менен далилдеңиз, андан кийин калганын кошуңуз; бузулган префикс кайра куруунун ордуна конфигурацияда бир сап болуп калат. Ачык кармоого татыктуу жалгыз расмий шилтеме — RFC 8200, ал туннель ташыган башталышты аныктайт.

Тектеш макалалар