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 таблицаларына route-торду орнотот жана ошол жерде токтойт. Анын attachment модели жок, ошондуктан трафикти башка VPCке же жалпы чыгуу сегментине бере албайт. Бул бир VPCнин чеги — бүткүл чектөө, жана VPC ичинде кошулган эч бир route аны өзгөртпөйт.

Transit gateway — аймактык борбор, анда VPN, ар бир spoke VPC жана жалпы кызматтардын VPC attachment катары көрүнөт. Анын өз route таблицалары бар, алар берилген prefixти кайсы attachment аларын тандайт.

Борборлоштурулган чыгууну ушул борбор мүмкүн кылат: VPN бир attachment болуп конот, чыгуу VPC экинчиси болуп конот, transit gateway route таблицасы интернетке багытталган 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 таблицалары курулгандан кийин аныктоодон арзан.

Тектеш макалалар