AWS Site-to-Site VPN: знешнія, унутраныя адрасы і прэфікс LAN

Тры ролі адрасоў блытаюцца на адным AWS VPN: знешнія партнёры, унутранае звяно /30 і абароненыя прэфіксы LAN. Чытайце іх са спампаванай канфігурацыі.

Большасць памылак у AWS Site-to-Site VPN — гэта памылкі ў адрасах, і яны робяцца яшчэ да таго, як рушыць хоць адзін пакет. Знешнія адрасы тунеля дасягаюць партнёраў IPsec, унутраныя адрасы ўтвараюць маршрутнае звяно паміж імі, а абароненыя прэфіксы — гэта тое, дзеля чаго існуе гэтае звяно. Скапіюйце адну ролю ў іншую — і тунель узнімаецца, хоць нішто не маршрутызуецца. Вось паслядоўнасць чытанне-праверка-наладка, якую я выкарыстоўваю на кліенцкім шлюзе BGP, а значэнні бяру са спампаванай канфігурацыі прылады, а не з памяці.

Тры ролі адрасоў, адзін тунель

Знешнія адрасы публічныя і належаць партнёрам IPsec: па адным на тунель з боку AWS, і дасяжны ідэнтыфікатар кліенцкага шлюза з вашага боку, адаптаваны пад тую схему NAT, якая ў вас фактычна ёсць. Унутраныя адрасы прыватныя і належаць лагічнаму звяну, якое AWS апісвае як /30, узяты з 169.254.0.0/16. Абароненыя прэфіксы — гэта сеткі VPC, лакальныя або транзітныя, якія вы маршрутызуеце і абвяшчаеце праз гэтае звяно.

Прызначэнне прэфікса LAN у якасці адраса інтэрфейса тунеля — класічная форма гэтай памылкі. Інтэрфейс выглядае наладжаным, LAN не абвяшчаецца, і ў процілеглага боку няма маршруту да яго. Тунель можа нават прайсці свой уласны ўнутраны ping, пакуль кожнае імя праграмы выходзіць па тайм-ауце. Даведнік па опцыях тунеля пералічвае абмежаванні ўнутранага CIDR, уключаючы дыяпазон адрасоў, з якога ён павінен брацца.

Чытайце значэнні са спампаванай канфігурацыі

Спампуйце канфігурацыю менавіта для вашай мадэлі прылады з злучэння, а затым лічыце яе табліцу адрасоў крыніцай праўды. Кансоль паказвае тыя ж значэнні для кожнага тунеля: знешні IP, унутраны CIDR і адрас партнёра BGP з боку AWS. Два тунелі — гэта асобныя аб’екты з асобнымі знешнімі канчатковымі пунктамі і асобнымі ўнутранымі /30, нават калі абодва перадаюць тыя ж абароненыя сеткі.

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query 'VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,TunnelInsideCidr]'
aws ec2 describe-customer-gateways --customer-gateway-ids cgw-0123456789abcdef0 \
  --query 'CustomerGateways[0].[IpAddress,BgpAsn]'

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

Пабудуйце звяно з правільным адрасам на ім

На шлюзе Linux тунель — гэта інтэрфейс VTI або XFRM, і ўнутраны /30 ідзе на гэты інтэрфейс. Два тунелі азначаюць два інтэрфейсы і двух суседзяў BGP, па адным на кожны канчатковы пункт AWS. Канавенцыя, якую AWS друкуе ў спампаванай канфігурацыі прылады, ставіць віртуальны прыватны шлюз на першы адрас кожнага ўнутранага /30, а ваш кліенцкі шлюз — на другі, таму вы бярэце вышэйшы адрас і ўсталёўваеце суседства з ніжэйшым. Нішто тут не патрабуе адраса LAN.

ip tunnel add tun0 mode vti local 203.0.113.10 remote 18.230.1.1 key 42
ip addr add 169.254.10.2/30 dev tun0
ip link set tun0 up mtu 1400
ip tunnel add tun1 mode vti local 203.0.113.10 remote 18.230.2.1 key 43
ip addr add 169.254.10.6/30 dev tun1
ip link set tun1 up mtu 1400

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

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

Праверце BGP перш, чым правяраць маршруты

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

ip -s addr show dev tun0
vtysh -c 'show bgp summary'
vtysh -c 'show bgp neighbors 169.254.10.1'
vtysh -c 'show ip bgp neighbors 169.254.10.1 advertised-routes'

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

Прасочце маршрутызаваны пакет і спыніцеся

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

Reachability Analyzer — гэта інструмент на баку AWS, які бярэ крыніцу, прызначэнне і шлях і паведамляе, які кампанент у падтрымоўванай канфігурацыі яго заблакаваў. Выкарыстоўвайце яго, каб праверыць шлях ад VPC да адраса вашага кліенцкага шлюза, а не ад хоста праграмы. Ён аналізуе канфігурацыю і не адпраўляе пакет праз лакальны фэйрвол, таму трымайце яго вердыкт асобна ад вашых уласных лічыльнікаў інтэрфейса і захопаў пакетаў.

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

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