AWS–Azure сайт-сайт VPN: адегенде кайтаруу маршрутун жазыңыз
Эки булуттун ортосундагы туташкан туннель ар бир жумуш жүктөмүнүн ички тармагы алыскы префикске маршруттамайынча эч нерсени далилдебейт. Планды катары менен аткарып, анан кызматты сынаңыз.
Туннель көтөрүлөт. Адатта ошондой болот, анткени IKEге дал келген сунуштар жана жеткиликтүү өнөктөш дареги гана керек. Андан кийин ишке ашпаган нерсе — кайтаруу жолу: AWS жүктөмү пакеттерди туннелге жөнөтөт, бирок Azure тарабында 10.10.0.0/16га кантип жооп берүүнү эч ким билбейт, же Azure маршруту жүктөмдүн ички тармагы колдонбогон таблицада турат. Каалаган консолго тийүүдөн мурун маршрут планын жазыңыз, ошондо туннель иштин эң кызыксыз бөлүгү болуп калат.
1-кадам: дарек планын тоңдуруңуз
Так маанилер менен иштеңиз. AWS жүктөмү 10.10.0.0/16 ичиндеги 10.10.1.20 дарегинде жана 10.20.0.0/16 ичиндеги 10.20.1.30 дарегиндеги Azure кызматына TCP 443 керек. Эки диапазон кабатталбашы керек, ал эми кабыл алуу сынагы — туннель эмес, кызмат жубу.
Ошол төрт фактыны башка нерседен мурун жазыңыз, анткени ар бир кийинки кадам ошолорго каршы текшерилет.
2-кадам: ар бир учтун ээси болгон шлюзду атаңыз
AWS Site-to-Site VPN виртуалдык жеке шлюзде же транзиттик шлюзде аякташы мүмкүн, ал эми булар ар башка маршруттоо ээлери. Azure өзүнүн башкарылуучу VPN Gateway жана өзүнчө, кардарлар өздөрү иштеткен VM негизиндеги түзмөктөрдү сунуштайт. Кайсы жуп бар экенин жазыңыз, анткени кийинки секирик ар бир айкалышта башкача.
Башкарылуучу шлюз үчүн божомолдонгон жеке түзмөк дарегине көрсөткөн маршрутту көчүрбөңүз. Түзмөк үчүн булуттагы маршрут таратуу конок операциялык системасын конфигурациялайт деп ойлобоңуз, анткени ал андай кылбайт.
Бул жерде ката кетирүү толук көрүнгөн план түзүп, пакеттерди эч качан жооп бербеген дарекке жөнөтөт.
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де колдонуучу аныктаган маршрут таблицасы виртуалдык тармакка эмес, ички тармакка байланышат, ошондуктан натыйжалуу маршрутту VNet блейдинде эмес, жүктөмдүн NICинде текшериңиз.
Башкарылуучу Azure шлюзу алыскы префиксти шлюз таратуу аркылуу үйрөнө алат, ал эми UDR бул чечимди жокко чыгара алат. UDRди себебиңиз болгондо кошуңуз, адат боюнча эмес. Кошсоңуз, түзмөк дарегин ойлоп табуунун ордуна аны шлюз VPN жолу үчүн жарыялаган кийинки секирикке багыттаңыз. Андан кийин NICтеги натыйжалуу маршруттарды кайра окуңуз, анткени чечим чындыгында ошол жерде кабыл алынат.
4-кадам: көлөмдү шайкештештириңиз
BGP үчүн ар бир тарап жарыялаганды экинчи тарап чындыгында үйрөнгөнү менен префикс-префикс салыштырыңыз. Статикалык маршруттоо үчүн конфигурацияланган алыскы диапазондорду 3-кадамда жазган жүктөм маршруттары менен салыштырыңыз.
Криптография боюнча макулдашкан IKE мамилеси кайсы бир тарап 10.10.0.0/16 же 10.20.0.0/16 үйрөнгөнүнүн далили эмес. Пландаган /16нын ордуна бир гана /24 жарыялап, эки туннель турушу мүмкүн. Префиксти туннелдин абалынан эмес, маршруттоо таблицасынан текшериңиз. Шайкешсиздик кийин бир иштеген жана эч качан жооп бербеген ички тармак катары көрүнөт.
5-кадам: кызматты чыныгы булактан сынаңыз
Көздөлгөн агымды AWS коопсуздук топторунда жана тармактык ACLдерде, Azure NSGлеринде жана жолдогу каалаган түзмөк фильтринде уруксат бериңиз. Андан кийин 10.10.1.20дан бекитилген кызмат дареги менен портуна бир туташуу ачып, жооп ошол эле булакка кайтарын ырастаңыз.
Булуттун коопсуздук топтору да, NSGлер да абалдуу, ошондуктан четке кагылган кайтаруу пакети маршруттоонун белгиси, тескери багытта жазууну унуткан эреже эмес.
Каалаган шлюзден ping эч нерсени чечпейт. Шлюз дарегине ICMP башкаруу тегиздигинин жолун машыктырат, жүктөмгө керектүү өткөрүлгөн TCP кызматын эмес.
Кайтаруу жана жазуулар
Маршрут ээлерин туннелдин идентификаторлорунун жанына жазып, өзгөрүүгө чейинки маршрут таблицаларын сактаңыз. Эгер өзгөрүүнү алып салуу керек болсо, туннелди бузуудан мурун жүктөм маршруттарын жок кылыңыз, ошондо эч бир ички тармак эми жок болгон кийинки секирикке көрсөтпөйт.
Ошондо кийинки ички тармакты жылдыруу же spoke кошуу жаңыртуу үчүн бир белгиленген орунга ээ болот, эч качан өзүнүкү болбогон маршрут үчүн күнөөнү көтөргөн иштеп турган туннелдин ордуна.