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 қосу жаңартуға арналған бір белгілі орынға ие болады, ешқашан өзінікі болмаған маршрут үшін кінә арқалайтын жұмыс істеп тұрған туннельдің орнына.