AWS Site-to-Site VPN és NAT Gateway: VGW vagy Transit Gateway

Elsőre mindenki ugyanazt a rajzot készíti: VPN a VPC-be, NAT gateway az internet felé, kész. Az AWS azonban nem támogatja ezt az utat, ha a VPN virtual private gatewayen végződik, és a hiba olyan csendes, hogy a csapatok többször is újraépítik. A működő megoldáshoz transit gateway kell, ami mindkét oldalon megváltoztatja a gatewayt és a route-táblákat. Rajzolás előtt hasonlítsa össze a két formát.

A topológia, amely nyilvánvalónak tűnik, mégsem támogatott

Az AWS NAT gateway dokumentációja olyan vonalat húz, amely mindenkit meglep, aki csak egyetlen VPC-s megoldásokat épített: a Site-to-Site VPN kapcsolat forgalma nem irányítható NAT gatewayre virtual private gatewayen keresztül. A gateway típusa, amelyen a VPN végződik, dönti el, hogy létezik-e egyáltalán fordítási útvonal. A hiba azért marad fenn, mert az alagút állapota UP, és egy EC2 példány ugyanabban a subnetben gond nélkül eléri az internetet. Egyik megfigyelés sem teszteli a hibás irányt.

A gyakorlatban a csomag a helyi hálózat forrás-címével érkezik, és nem talál támogatott következő hopot, amely lefordítaná. A tábláktól függően az egress határon eldobódik, és mivel az alagút UP marad, miközben egy példány ugyanabban a subnetben eléri az internetet, a hibát helyi tűzfalproblémaként jelentik.

Virtual private gateway kontra transit gateway

A virtual private gateway egyetlen VPC-hez tartozik. Lezárja a VPN-t, route-okat telepít annak a VPC-nek a route-tábláiba, és ott megáll. Nincs attachment-modellje, ezért nem tud forgalmat átadni másik VPC-nek vagy közös egress szegmensnek. Ez az egy-VPC-s hatókör a teljes korlát, és a VPC-n belül hozzáadott route nem változtat rajta.

A transit gateway regionális központ, ahol a VPN, minden spoke VPC és egy közös szolgáltatásokhoz tartozó VPC attachmentként jelenik meg. Saját route-táblái vannak, amelyek kiválasztják, melyik attachment kap egy adott prefixet.

Ez a központ teszi lehetővé a központosított egress: a VPN egy attachmentként landol, az egress VPC egy másikként, és a transit gateway route-táblája az internet felé mutató prefixeket az elsőtől a másodikhoz küldi. Virtual private gateway esetén nincs második attachment, ahová bármit küldeni lehetne, ezért a megoldás utólag nem foltozható.

A támogatott egress útvonal, hopról hopra

A referencia-megoldásnak öt hopja van, és minden nyíl egy útválasztási döntés, amelyet be kell állítania. A forgalom a helyi hálózatból a Site-to-Site VPN attachmentbe lép, a transit gateway táblája továbbítja az egress VPC attachmentjéhez, ahol a subnet táblája egy nyilvános NAT gatewayhez küldi. A NAT gateway lefordítja a forrást, az internet gateway pedig kiviszi a csomagot.

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

Két részlet dönti el, működnek-e az utolsó hopok. A NAT gatewaynek nyilvánosnak kell lennie, elastic IP-vel és internet gateway felé mutató route-tal, mert a privát NAT gateway hálózatok között fordít, és soha nem válik internetes kijárattá.

Tervezzen egy NAT gatewayt minden kiszolgálni kívánt Availability Zone-hoz, és minden subnet-tábla a helyire mutasson. Tartsa a transit gateway tábláját és a VPC tábláit külön objektumként a jegyzeteiben, mert az egyik attachmentet, a másik a VPC-n belüli erőforrást választ. Ha csak az egyikben van default route, az útvonal fele meghatározatlan marad, és azok a részleges hibák keletkeznek, amelyeket a legnehezebb hozzárendelni.

Ezek a megoldások a visszaúton hibáznak

A NAT gateway stateful a már látott folyamatokhoz, ezért a kimenő kapcsolat válaszai új bejövő szabály nélkül visszatérnek. Ez a tulajdonság nem tesz közzé helyi szolgáltatást az interneten, és úgy kezelni, mintha mégis, annyit jelent, hogy a csapat egy napot tölt egy olyan kapcsolat hibakeresésével, amely soha nem jött volna létre. Az ügyfél által indított forgalomhoz négy route-nak egyeznie kell: a helyi szabályzat, a transit gateway táblája, az egress subnet táblája és a NAT subnet táblája. Ha az utolsó kimarad, a kérés elhagyja az épületet, a válasz pedig meghal az AWS-en belül.

Ellenőrizze egy valódi, a VPN mögötti ügyféllel, és nézze meg, milyen nyilvános forrás-címet mutat. Ha ez a NAT gateway elastic IP-je, fordítás történik; ha valami más, akkor másik kijáratot mér.

Érdemes korán felismerni a hiba aszimmetrikus változatát. Ha az egyik Availability Zone NAT subnet táblájában van visszaútvonal az ügyfél prefixéhez, a másikban pedig nincs, az új kapcsolatok attól függően sikerülnek vagy hibáznak, hogy a folyamat melyik zónába esik, és a mintát tévesen instabil internetként olvassák. Hasonlítsa össze a subnet-táblákat minden kiszolgált zónában, ahelyett hogy azt javítaná, ahol a ticket keletkezett, mert a hiányzó route a teljes hiba, és a másik oldalon semmit nem kell változtatni.

Mikor jobb megoldás egy explicit proxy

Az egress VPC egyik példányán futó HTTP proxy jogos alternatíva, és gyakran olcsóbb. Az ügyfeleket erre állítják be, a proxy saját kapcsolatot nyit kifelé, és a visszaút az ő problémája lesz, nem szimmetrikus útválasztási rejtvény. Néhány alkalmazás esetén ez a transit gateway munka nagy részét megszünteti. Felhasználónkénti naplózást is ad, amit egy NAT gateway nem tud előállítani.

Átlátszó viszont nem. Minden, ami figyelmen kívül hagyja a proxybeállításokat, és minden nem HTTP protokoll, nem ezt az utat követi.

A választás attól függ, mit beszélnek valójában az alkalmazásai, és mennyi identitásra van szüksége a naplókban. Ahol HTTP-t beszélnek, ott a proxy megérdemli a helyét; ahol általános egress kell tetszőleges protokollokhoz, ott a transit gatewayes megoldás az, amelyet az AWS támogat. Ezt előre eldönteni olcsóbb, mint a route-táblák felépítése után felfedezni.