AWS Site-to-Site VPN-нан NAT Gateway-ке: VGW немесе Transit Gateway

virtual private gateway Site-to-Site VPN трафигін NAT gateway-ке бере алмайды. VGW мен transit gateway жолдарын және әрқайсысына қажет route-тарды салыстырыңыз.

Барлығы бірінші рет бірдей диаграмма салады: VPN VPC-ке, NAT gateway интернетке, дайын. Бірақ VPN virtual private gateway-де аяқталғанда AWS бұл жолды қолдамайды, ал сәтсіздік соншалықты үнсіз, командалар оны бірнеше рет қайта салады. Жұмыс істейтін шешімге transit gateway керек, ол екі жақтағы gateway мен route кестелерін өзгертеді. Бірдеңе салмас бұрын екі пішінді салыстырыңыз.

Айқын көрінетін, бірақ қолдау жоқ топология

AWS-тің NAT gateway құжаттамасы тек бір VPC шешімін салғандарды таңқалдыратын сызық жүргізеді: Site-to-Site VPN қосылысының трафигін virtual private gateway арқылы NAT gateway-ке маршруттау мүмкін емес. VPN аяқталатын gateway түрі трансляция жолының бар-жоғын анықтайды. Қате сол күйінде қалады, өйткені туннель күйі UP және сол subnet-тегі EC2 данасы интернетке проблемасыз жетеді. Бұл екі байқаудың ешқайсысы бұзылған бағытты тексермейді.

Іс жүзінде пакет жергілікті желінің бастапқы мекенжайымен келеді және оны түрлендіретін қолдау көрсетілген келесі hop табылмайды. Кестелерге қарай ол шығу шекарасында тасталады, ал туннель UP болып қалады және сол subnet-тегі дана интернетке жетеді, сондықтан сәтсіздік жергілікті firewall мәселесі ретінде хабарланады.

Virtual private gateway transit gateway-ге қарсы

Virtual private gateway бір VPC-ге тиесілі. Ол VPN-ді аяқтайды, сол VPC кестелеріне route-тар орнатады және сонда тоқтайды. Оның attachment моделі жоқ, сондықтан трафикті басқа VPC-ке немесе ортақ шығу сегментіне бере алмайды. Осы бір VPC ауқымы — бүкіл шектеу, және VPC ішінде қосылған ешбір route оны өзгертпейді.

Transit gateway — аймақтық хаб, онда VPN, әр spoke VPC және ортақ қызметтер VPC-сі attachment ретінде көрінеді. Оның өз route кестелері бар, олар берілген prefix-ті қай attachment алатынын таңдайды.

Орталықтандырылған шығуды дәл осы хаб мүмкін етеді: VPN бір attachment болып қонады, шығу VPC екіншісі болып қонады, transit gateway кестесі интернетке бағытталған prefix-терді біріншіден екіншіге жібереді. Virtual private gateway кезінде жіберетін екінші attachment жоқ, сондықтан шешімді кейін жамау мүмкін емес.

Қолдау көрсетілген шығу жолы, hop сайын

Анықтамалық шешімде бес hop бар және әр көрсеткі — конфигурациялауға тиіс маршруттау шешімі. Трафик жергілікті желіден Site-to-Site VPN attachment-іне шығады, transit gateway кестесі оны шығу VPC attachment-іне жібереді, онда subnet кестесі оны жалпыға қолжетімді NAT gateway-ке жібереді. NAT gateway бастапқы мекенжайды түрлендіреді, internet gateway пакетті сыртқа шығарады.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

Соңғы hop-тар жұмыс істей ме — оны екі бөлшек шешеді. NAT gateway жалпыға қолжетімді болуы керек, elastic IP және internet gateway-ке route-пен, өйткені жеке NAT gateway желілер арасында түрлендіреді және ешқашан интернет шығысына айналмайды.

Қызмет көрсететін әр Availability Zone үшін бір NAT gateway жоспарлаңыз, ал әр subnet кестесі жергіліктісін көрсетсін. Жазбаларыңызда transit gateway кестесі мен VPC кестелерін бөлек нысандар ретінде ұстаңыз, өйткені біреуі attachment, екіншісі VPC ішіндегі ресурс таңдайды. Тек біреуінде default route болса, жолдың жартысы анықталмай қалады және тиесілігін анықтау ең қиын ішінара ақаулар пайда болады.

Бұл шешімдер қайтару жолында сәтсіздікке ұшырайды

NAT gateway бұрын көрген ағындар үшін күйді сақтайды, сондықтан шығыс қосылысқа жауаптар жаңа кіріс ережесінсіз оралады. Бұл қасиет жергілікті қызметті интернетте жарияламайды, оны солай деп қарау команданы ешқашан орнамайтын қосылысты жөндеуге бір күн жұмсауға мәжбүр етеді. Клиенттен басталған трафикке төрт route келісуі керек: жергілікті саясат, transit gateway кестесі, шығу subnet кестесі және NAT subnet кестесі. Соңғысын өткізіп алсаңыз, сұраныс ғимараттан шығады, ал жауап AWS ішінде өледі.

VPN артындағы нақты клиентпен текеріңіз және ол қандай жалпыға қолжетімді бастапқы мекенжайды ұсынатынын қараңыз. Егер бұл NAT gateway-тің elastic IP-і болса, түрлендіру жүріп жатыр; егер басқа нәрсе болса, басқа шығуды өлшеп жатырсыз.

Бұл ақаудың асимметриялы нұсқасын ерте таныған жөн. Бір Availability Zone-ның NAT subnet кестесінде клиент prefix-іне қайтару route-ы бар, екіншісінде жоқ болса, жаңа қосылыстар ағын түсетін аймаққа қарай сәтті немесе сәтсіз болады, және бұл үлгі тұрақсыз интернет деп қате оқылады. Билет ашылған аймақты түзетудің орнына қызмет көрсететін әр аймақтың subnet кестелерін салыстырыңыз, өйткені жетіспейтін route — бүкіл ақау, ал арғы жақта ештеңе өзгертудің қажеті жоқ.

Қашан ашық proxy жақсырақ шешім болады

Шығу VPC-сіндегі данадағы HTTP proxy — заңды балама және жиі арзанырақ. Клиенттер оны қолдануға конфигурацияланады, proxy өз қосылысын сыртқа ашады, ал қайтару жолы симметриялы маршруттау жұмбағы емес, оның мәселесі болады. Бірнеше қолданба үшін бұл transit gateway жұмысының басым бөлігін жояды. Ол сондай-ақ NAT gateway жасай алмайтын пайдаланушы бойынша журналдауды береді.

Алайда ол мөлдір емес. Proxy параметрлерін елемейтін кез келген нәрсе және HTTP емес әрбір протокол бұл жолмен жүрмейді.

Таңдау қолданбаларыңыз шын мәнінде қандай тілде сөйлейтініне және журналдарда қанша сәйкестік қажет екеніне байланысты. Олар HTTP сөйлейтін жерде proxy өз орнын алады; еркін протоколдар үшін жалпы шығу қажет жерде AWS қолдайтын шешім — transit gateway. Мұны алдын ала шешу route кестелері салынғаннан кейін анықтағаннан арзан.

Қатысты мақалалар