Site-to-Site 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, защото решението всъщност се взема там.
Стъпка 4: съгласувайте обхвата
За BGP сравнете какво обявява всяка страна с това, което другата страна действително е научила, префикс по префикс. За статична маршрутизация сравнете конфигурираните отдалечени диапазони с маршрутите на натоварването, които написахте в стъпка 3.
IKE връзка, която е съгласна за криптографията, не е доказателство, че някоя страна е научила 10.10.0.0/16 или 10.20.0.0/16. Два тунела могат да са вдигнати, докато едната страна обявява един /24 вместо /16, който сте планирали. Проверявайте префикса в таблицата с маршрути, не в състоянието на тунела. Несъответствието после се проявява като една работеща подмрежа и една, която никога не отговаря.
Стъпка 5: тествайте услугата от реалния източник
Разрешете предвидения поток в групите за сигурност и мрежовите ACL на AWS, в NSG на Azure и във всеки филтър на устройство по пътя. След това отворете една връзка от 10.10.1.20 към одобрения адрес и порт на услугата и потвърдете, че отговорът се връща към същия източник.
И облачните групи за сигурност, и NSG са stateful, така че отказан обратен пакет е симптом на маршрутизация, а не правило, което сте забравили да напишете в обратна посока.
Ping от който и да е шлюз не решава нищо. ICMP към адрес на шлюз упражнява пътя на контролната плоскост, не препращаната TCP услуга, от която натоварването се нуждае.
Връщане назад и записи
Запишете собствениците на маршрути до идентификаторите на тунела и запазете таблиците с маршрути преди промяната. Ако промяната трябва да се извади, премахнете маршрутите на натоварването, преди да разглобите тунела, за да не остане подмрежа, сочеща към следващ хоп, който вече не съществува.
Тогава по-късно преместване на подмрежа или свързване на spoke има едно определено място за актуализация, вместо работещ тунел, който носи вината за маршрут, който никога не е притежавал.