Сайт-сайт VPN паміж AWS і Azure: спачатку напішыце зваротны маршрут
Злучаны міжхмарны тунэль нічога не даказвае, пакуль кожная падсетка працоўнай нагрузкі не маршрутызуе да далёкага прэфікса. Выканайце план па парадку, затым праверце службу.
Тунэль узнімецца. Звычайна так і адбываецца, бо IKE патрабуе толькі адпаведных прапаноў і дасяжнага адраса партнёра. Пасля гэтага здае зваротны шлях: працоўная нагрузка AWS адпраўляе пакеты ў тунэль, але на баку Azure нішто не ведае, як адказаць на 10.10.0.0/16, або маршрут Azure існуе ў табліцы, якую падсетка працоўнай нагрузкі не выкарыстоўвае. Напішыце план маршрутаў да таго, як дакрануцца да любой кансолі, і тунэль стане найменш цікавай часткай працы.
Крок 1: замарозьце план адрасоў
Працуйце з канкрэтнымі значэннямі. Працоўная нагрузка AWS знаходзіцца на 10.10.1.20 унутры 10.10.0.0/16 і патрабуе TCP 443 да службы Azure на 10.20.1.30 унутры 10.20.0.0/16. Два дыяпазоны не павінны перакрывацца, і прыёмачным тэстам з’яўляецца пара службаў, а не тунэль.
Запішыце гэтыя чатыры факты перад усім іншым, бо кожны наступны крок правяраецца супраць іх.
Крок 2: назвіце шлюз, які валодае кожным канцом
AWS Site-to-Site VPN можа завяршацца на віртуальным прыватным шлюзе або на транзітным шлюзе, і гэта розныя ўладальнікі маршрутызацыі. Azure прапануе кіраваны VPN Gateway і асобна прылады на базе ВМ, якія кліенты запускаюць самі. Запішыце, якая пара ў вас ёсць, бо наступны пераход адрозніваецца ў кожнай камбінацыі.
Для кіраванага шлюза не капіюйце маршрут, які паказвае на меркаваны адрас прыватнай прылады. Для прылады не мяркуйце, што распаўсюджванне маршрутаў у хмары наладжвае гасцявую аперацыйную сістэму, бо яно гэтага не робіць.
Памылка тут дае план, які выглядае поўным і накіроўвае пакеты на адрас, які ніколі не адказвае.
Крок 3: напішыце маршрут, які кожная працоўная нагрузка рэальна выкарыстоўвае
Кожная мяжа ніжэй — асобны пошук, і маршрут у адной з іх не з’яўляецца маршрутам для пакета. Запоўніце табліцу сваімі значэннямі да запуску тунэля.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
У AWS табліца маршрутаў падсеткі працоўнай нагрузкі — вашая, нават пасля таго як BGP або тунэль стане здаровым; агляд маршрутызацыі лічыць гэта часткай злучэння. У Azure табліца маршрутаў, вызначаных карыстальнікам, звязваецца з падсеткай, а не з віртуальнай сеткай, таму правярайце эфектыўны маршрут на NIC працоўнай нагрузкі, а не ў раздзеле VNet.
Кіраваны шлюз Azure можа вывучыць далёкі прэфікс праз распаўсюджванне шлюза, а UDR можа пераадолець гэтае рашэнне. Дадавайце UDR, калі ў вас ёсць прычына, а не рэфлекторна. Калі дадаеце, накіруйце яго на наступны пераход, які шлюз публікуе для шляху VPN, а не выдумляйце адрас прылады. Затым перачытайце эфектыўныя маршруты на NIC, бо менавіта NIC прымае рашэнне.
Крок 4: узгадніце абсяг
Для BGP параўнайце, што абвяшчае кожны бок, з тым, што іншы бок фактычна вывучыў, прэфікс за прэфіксам. Для статычнай маршрутызацыі параўнайце наладжаныя далёкія дыяпазоны з маршрутамі працоўнай нагрузкі, якія вы напісалі на кроку 3.
Адносіны IKE, якія дамовіліся пра крыптаграфію, не доказ таго, што які-небудзь бок вывучыў 10.10.0.0/16 або 10.20.0.0/16. Два тунэлі могуць быць узнятыя, пакуль адзін бок абвяшчае адзін /24 замест /16, які вы планавалі. Правярайце прэфікс у табліцы маршрутаў, а не ў статусе тунэля. Няўзгодненасць пазней выявіцца як адна працоўная падсетка і адна, якая ніколі не адказвае.
Крок 5: праверце службу з рэальнай крыніцы
Дазвольце меркаваны паток у групах бяспекі AWS і сеткавых ACL, у NSG Azure і ў любым фільтры прылады на шляху. Затым адкрыйце адно злучэнне з 10.10.1.20 да зацверджанага адраса і порта службы і пераканайцеся, што адказ вяртаецца да той жа крыніцы.
І хмарныя групы бяспекі, і NSG маюць стан, таму адхілены зваротны пакет — гэта сімптом маршрутызацыі, а не правіла, якое вы забыліся напісаць у адваротным кірунку.
Ping з любога шлюза нічога не вырашае. ICMP да адраса шлюза практыкуе шлях плоскасці кіравання, а не прапушчаную службу TCP, якая патрэбна працоўнай нагрузцы.
Адкат і запісы
Запішыце ўладальнікаў маршрутаў побач з ідэнтыфікатарамі тунэля і захавайце табліцы маршрутаў да змены. Калі змену трэба адмяніць, выдаліце маршруты працоўнай нагрузкі перад дэмантажом тунэля, каб ні адна падсетка не засталася паказваць на пераход, якога больш няма.
Тады наступны перанос падсеткі або далучэнне spoke мае адно вызначанае месца для абнаўлення, замест працуючага тунэля, які нясе віну за маршрут, якім ён ніколі не валодаў.