Двухстэкавыя пулы VPN: абодва сямействы адрасоў у strongSwan

Унутраныя пулы IPv4 і IPv6, абароненыя прэфіксы і сямейства знешняга тунэля — гэта тры асобныя рашэнні. Сплануйце кожнае, перш чым называць гэта двухстэкавым.

Шлюз можа выдаць вандроўнаму карыстальніку і адрас IPv4, і адрас IPv6, пакуль знешні тунэль па-ранейшаму ідзе праз IPv4. Гэта незалежныя рашэнні, і менавіта спроба разглядаць іх як адно і развальвае двухстэкавыя планы. Унутраныя сямействы кліента, абароненыя прэфіксы, да якіх ён можа дацягнуцца, і транспарт, які нясе інкапсуляцыю, — гэта тры асобныя выбары.

Большасць блытаніны ўзнікае таму, што слова «двухстэкавы» прымяняюць да праекта, які двухстэкавы толькі ў адным месцы. Сэрвіс можа быць двухстэкавым унутры, аднастэкавым на знешнім адрасе і пры гэтым цалкам добра працаваць для кліентаў. Чаго ён не можа — працаваць выпадкова.

Два сямействы ўнутры, адзін шлях звонку

Знешняе злучэнне — гэта IKE паверх UDP, і яму патрэбна адно дасяжнае сямейства адрасоў з таго месца, дзе знаходзіцца кліент. Унутраны адрас IPv6 не патрабуе правайдэра з падтрымкай IPv6, бо ўнутраны пакет — гэта карысная нагрузка ўнутры знешняга. Шмат працоўных разгортванняў перадаюць прэфіксы IPv6 праз канал, які падтрымлівае толькі IPv4.

Што знешні шлях сапраўды абмяжоўвае, дык гэта дасяжнасць і праходжанне NAT. Калі шлюз аб’яўляе толькі адрас IPv4, кліент у сетцы толькі з IPv6 не зможа падключыцца ўвогуле, якія б пулы вы ні наладзілі. Выбірайце знешняе сямейства па сваёй кліенцкай базе, а не па ўнутраным плане адрасоў.

Дайце кліенту адрас у кожным сямействе

Запрос абодвух сямействаў — гэта адзін радок на баку кліента, пры ўмове, што шлюзу ёсць што выдаць. Імянныя пулы трымаюць крыніцы асобна ад сэрвісных сетак, і менавіта гэтая ўласцівасць робіць правілы файрвола чытальнымі праз шэсць месяцаў.

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

Значэнне vips запытвае адрас кожнага сямейства, а спіс пулаў вызначае, адкуль бяруцца гэтыя адрасы. Дакументацыя strongSwan пра віртуальныя IP-адрасы апісвае мноства запытаў і размеркаванне па пулах, у тым ліку той момант, што кліент, які просіць пэўны адрас, выказвае толькі перавагу, якую адказны бок можа перагледзець. Не будайце правіла доступу, якое мяркуе, што кліент заўсёды атрымлівае адно і тое ж значэнне.

Генеруйце ўласны ўнікальны лакальны прэфікс замест таго, каб капіяваць прыклад. Дзве арганізацыі, якія абедзве fd42::/16 разгорнуць, выявяць канфлікт пры першым злучэнні паміж сабой, і дыягнаставаць гэта непрыемна.

Селектары апісваюць прызначэнні, а не крыніцы

Лакальныя селектары трафіку даччынай SA паказваюць, якія абароненыя сеткі стаяць за шлюзам, а аддаленыя селектары апісваюць, што кліент можа выкарыстоўваць як крыніцу. Адрас віртуальнага пула належыць да боку крыніцы гэтай палітыкі; змяшчаць яго ў спіс прызначэнняў — распаўсюджанае памылковае чытанне канфігурацыі.

Абодвум сямействам патрэбны зваротныя маршруты і дазволены форвардынг на шлюзе. Даданне прэфікса ў селектар без маршруту назад да пула стварае тунэль, які ўзнімаецца, прапускае адзін кірунак трафіку і моўчкі адкідае адказ. Селектар — гэта палітыка, а не маршрутызацыя.

Трымайце пулы і прэфіксы сэрвісаў у асобных блоках плана адрасоў. Калі яны перасякаюцца, маршрут, які павінен дасягнуць абароненага хоста, можа супасці з адрасам пула і знікнуць у тунэлі.

DNS і шлях адказу вызначаюць, ці выглядае гэта завершаным

Адказы рэзалвера не залежаць ад транспарту, якім да яго дабіраюцца. Імя можа вярнуць запіс A, запіс AAAA або абодва, і кліент выбірае паводле сваіх уласных правілаў перавагі . Калі ўнутраны сэрвіс публікуе запіс AAAA, але нішто не маршрутызуе гэты прэфікс, кліенты ў двухстэкавых сетках паспрабуюць шлях IPv6 першым і будуць чакаць, пакуль ён не праваліцца. У канфігурацыі тунэля ў гэты час нічога не выглядае няправільным.

Таму вызначце для кожнага імя, якія сямействы павінны быць прыдатныя, затым праверце, што адпаведны прэфікс ёсць у селектары і мае зваротны маршрут. Гэта рашэнне па кожным сэрвісе. Суцэльная публікацыя абодвух тыпаў запісаў — гэта тое, як працоўны сэрвіс толькі з IPv4 пачынае аддаваць таймаўт палове сваіх карыстальнікаў.

Праверце абодва сямействы, перш чым назваць гэта гатовым

Канфігурацыя, якая загружаецца, — не тое ж самае, што канфігурацыя, якая працуе. Прачытайце стан, які паведамляе дэман, пацвердзіце размеркаванне пулаў, а затым паглядзіце на маршруты, якія кліент фактычна ўсталяваў.

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

Першыя дзве каманды паказваюць усталяваныя даччыныя SA і тое, у якіх пулах яшчэ ёсць адрасы, так што план, які працуе для першага кліента і зрываецца на дзясятым, робіцца бачным. Апошнія дзве паказваюць, ці атрымаў кліент глабальны адрас IPv6 з пула і куды насамрэч пойдзе трафік да абароненага прэфікса. Параўнайце прызначаны адрас з пулам, які вы наладзілі, а не з адрасам, на які спадзяваліся. Калі адказны бок выбраў іншае значэнне па сваёй палітыцы, маршруты і правілы файрвола ўсё роўна павінны адпавядаць яго выбару.

Затым праверце адзін абаронены хост на кожнае сямейства і імя, якое развязваецца ў абодва. Тэст аднаго сямейства нічога не кажа пра тую палову плана, якую вы не задзейнічалі, і менавіта ў ёй звычайна хаваецца адсутны маршрут.

Падобныя артыкулы