AWS Site-to-Site VPN ja NAT Gateway: VGW vai Transit Gateway

Kaikki piirtävät ensimmäisellä kerralla saman kaavion: VPN VPC:hen, NAT gateway internetiin, valmis. AWS ei kuitenkaan tue tätä polkua, kun VPN päättyy virtual private gatewayhun, ja virhe on niin hiljainen, että tiimit rakentavat sen useammin kuin kerran. Toimiva ratkaisu vaatii transit gatewayn, mikä muuttaa gatewayn ja reititystaulut molemmin puolin. Vertaa kahta muotoa ennen piirtämistä.

Topologia, joka näyttää ilmeiseltä mutta ei ole tuettu

AWS:n NAT gateway -dokumentaatio vetää viivan, joka yllättää jokaisen vain yhden VPC:n ratkaisuja rakentaneen: Site-to-Site VPN -yhteyden liikennettä ei voi reitittää NAT gatewaylle virtual private gatewayn kautta. VPN:n päättävä gateway-tyyppi ratkaisee, onko käännöspolkua lainkaan. Virhe säilyy, koska tunnelin tila on UP ja samassa subnetissä oleva EC2-instanssi saavuttaa internetin ongelmitta. Kumpikaan havainto ei testaa rikkinäistä suuntaa.

Käytännössä paketti saapuu paikallisen verkon lähdeosoitteella eikä löydä tuettua seuraavaa hyppyä, joka kääntäisi sen. Tauluista riippuen se pudotetaan ulostulorajalla, ja koska tunneli pysyy UP:nä samalla kun saman subnetin instanssi saavuttaa internetin, vika raportoidaan paikallisen palomuurin ongelmana.

Virtual private gateway vs. transit gateway

Virtual private gateway kuuluu yhdelle VPC:lle. Se päättää VPN:n, asentaa reitit kyseisen VPC:n reititystauluihin ja pysähtyy siihen. Sillä ei ole attachment-mallia, joten se ei voi luovuttaa liikennettä toiselle VPC:lle tai jaetulle ulostulosegmentille. Koko rajoitus on tämä yhden VPC:n laajuus, eikä mikään VPC:n sisään lisätty reitti muuta sitä.

Transit gateway on alueellinen keskus, jossa VPN, kukin spoke-VPC ja jaettujen palvelujen VPC näkyvät attachmenteina. Sillä on omat reititystaulut, jotka valitsevat, mikä attachment vastaanottaa tietyn prefiksin.

Tämä keskus mahdollistaa keskitetyn ulostulon: VPN laskeutuu yhtenä attachmentina, ulostulo-VPC toisena, ja transit gatewayn reititystaulu lähettää internetiin suuntautuvat prefiksit ensimmäisestä toiseen. Virtual private gatewayllä ei ole toista attachmentia, jolle lähettää, joten ratkaisua ei voi paikata jälkikäteen.

Tuettu ulostulopolku, hyppy hypyltä

Vertailuratkaisussa on viisi hyppyä ja jokainen nuoli on reitityspäätös, joka sinun on määritettävä. Liikenne lähtee paikallisesta verkosta Site-to-Site VPN -attachmentiin, transit gatewayn taulu välittää sen ulostulo-VPC:n attachmentiin, jossa subnetin taulu lähettää sen julkiselle NAT gatewaylle. NAT gateway kääntää lähteen ja internet gateway vie paketin ulos.

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

Kaksi yksityiskohtaa ratkaisee, toimivatko viimeiset hypyt. NAT gatewayn on oltava julkinen, elastic IP ja reitti internet gatewaylle, koska yksityinen NAT gateway kääntää verkkojen välillä eikä koskaan muutu internetin ulostuloksi.

Suunnittele yksi NAT gateway jokaista palveltavaa Availability Zonea kohden ja anna jokaisen subnet-taulun osoittaa paikalliseen. Pidä transit gatewayn taulu ja VPC:n taulut erillisinä objekteina muistiinpanoissasi, koska toinen valitsee attachmentin ja toinen VPC:n sisäisen resurssin. Oletusreitti vain toisessa jättää puolet polusta määrittelemättä ja tuottaa osittaiset viat, joita on vaikein kohdistaa.

Paluupolku on se, missä nämä ratkaisut pettävät

NAT gateway muistaa jo näkemänsä vuot, joten lähtevän yhteyden vastaukset palaavat ilman uutta saapuvan liikenteen sääntöä. Tämä ominaisuus ei julkaise paikallista palvelua internetiin, ja sen kohteleminen niin kuin julkaisisi maksaa tiimille päivän sellaisen yhteyden vianetsintään, jota ei koskaan olisi muodostunut. Asiakkaan aloittamalle liikenteelle neljän reitin on oltava yhtä mieltä: paikallinen käytäntö, transit gatewayn taulu, ulostulo-subnetin taulu ja NAT-subnetin taulu. Jos viimeinen puuttuu, pyyntö lähtee rakennuksesta ja vastaus kuolee AWS:n sisällä.

Varmista todellisella asiakkaalla VPN:n takana ja katso, minkä julkisen lähdeosoitteen se esittää. Jos se on NAT gatewayn elastic IP, käännös tapahtuu; jos jokin muu, mittaat toista ulostuloa.

Tämän vian epäsymmetrinen versio kannattaa tunnistaa aikaisin. Kun yhden Availability Zonen NAT-subnetin taulussa on paluureitti asiakkaan prefiksiin ja toisessa ei, uudet yhteydet onnistuvat tai epäonnistuvat sen mukaan, mihin vyöhykkeeseen vuo osuu, ja kuvio tulkitaan väärin epävakaaksi internetiksi. Vertaa subnet-tauluja jokaiselle palveltavalle vyöhykkeelle sen sijaan että korjaisit sen, jossa tiketti avattiin, koska puuttuva reitti on koko vika eikä toisella puolella tarvitse muuttaa mitään.

Milloin eksplisiittinen proxy on parempi ratkaisu

HTTP-proxy ulostulo-VPC:n instanssilla on laillinen vaihtoehto ja usein halvempi. Asiakkaat määritetään käyttämään sitä, proxy avaa oman yhteytensä ulospäin ja paluupolku on sen ongelma eikä symmetrisen reitityksen pulma. Muutamalle sovellukselle se poistaa suurimman osan transit gatewayn työstä. Se antaa myös käyttäjäkohtaiset lokit, joita NAT gateway ei pysty tuottamaan.

Se ei kuitenkaan ole läpinäkyvä. Kaikki proxyasetukset sivuuttava ja jokainen protokolla, joka ei ole HTTP, ei seuraa tätä polkua.

Valinta riippuu siitä, mitä sovelluksesi todella puhuvat ja kuinka paljon identiteettiä tarvitset lokeihin. Missä ne puhuvat HTTP:tä, proxy ansaitsee paikkansa; missä tarvitset yleisen ulostulon mielivaltaisille protokollille, transit gateway -ratkaisu on se, jota AWS tukee. Sen päättäminen etukäteen on halvempaa kuin sen löytäminen reititystaulujen rakentamisen jälkeen.