Miksi GRE ja ESP epäonnistuvat AWS NAT-yhdyskäytävän kautta

Tunneli epäonnistuu, tietoturvaryhmä sallii jo kaiken liikenteen, ja johtopäätös on, että AWS estää VPN:n. Se ei estä mitään. Hallittu NAT-yhdyskäytävä välittää dokumentoidun joukon ulkoisia protokollia, eikä natiivi GRE tai natiivi ESP kuulu siihen, joten mikään lisäämäsi sääntö ei saa yhdyskäytävää kuljettamaan niitä. Sallintasääntö ja kuljetuskyky ovat kaksi eri asiaa, ja vain toista niistä voit muuttaa.

Sääntöjoukko ei ole protokollajoukko

Tietoturvaryhmä päättää, mikä liikenne saa poistua instanssista. NAT-yhdyskäytävä päättää, mitä se pystyy kääntämään ja välittämään. Kun toinen raja tulee voimaan, salliva sääntö tuottaa täsmälleen sen oireen, jonka ihmiset tulkitsevat väärin palomuuriongelmaksi: paketit poistuvat instanssista, ohjausvaihto voi jopa valmistua, eikä mitään saavu vastapuolelle.

AWS:n NAT-yhdyskäytävän protokollamäärittely luettelee hallitulle palvelulle TCP:n, UDP:n ja ICMP:n. Se on koko tuettu joukko. Toisen IP-protokollan sallintasääntö ei voi laajentaa sitä, koska sääntö arvioidaan kauan ennen kuin yhdyskäytävän välityspolulle päästään.

Ero on tärkeä, koska molemmat viat näyttävät asiakkaan puolelta samoilta ja niillä on täysin erilaiset korjaukset.

PPTP osoittaa, miksi porttitesti valehtelee

PPTP on selvin vanha esimerkki porttitarkistuksesta, joka ei todista mitään. Se avaa TCP-ohjausyhteyden porttiin 1723 ja kuljettaa sitten tunnelidatan GRE:n kautta, joka on IP-protokolla 47. Protokolla 47 ei ole TCP-portti 47, eikä näillä kahdella numerolla ole mitään tekemistä keskenään paitsi yhteiset numerot.

Operaattori, joka testaa yhteyttä porttiin 1723 ja näkee valmiin kättelyn, päättelee, että polku toimii. Sitten datakanava ei koskaan läpäise yhtään pakettia, koska yhdyskäytävällä ei ole tarjota GRE-tukea. Tämä on tulkinta vanhan protokollan vaatimuksista, ei kehotus ottaa käyttöön PPTP:tä, joka on ollut vanhentunut vuosia.

Sama päättely pätee mihin tahansa protokollaan, jonka ohjauskanava on TCP tai UDP, kun taas sen datapolku ei ole.

IPsec säilyy vain UDP:nä

IPsec on tapaus, jossa vastaus on ehdollinen eikä jyrkkä ei. AWS dokumentoi NAT-läpäisyn tuetuksi järjestelyksi IPsecille NAT-yhdyskäytävän kautta. Kun NAT-T on neuvoteltu, ESP kapseloidaan UDP:n sisään ja yhdyskäytävä näkee tavallisen UDP:n protokollan 50 sijaan.

UDP 4500:n salliminen ei saa päätelaitteita käyttämään NAT-läpäisyä. Se vain sallii paketit, jos ne on jo muotoiltu niin. Vahvista asiakkaan omasta neuvottelutulosteesta, mikä kapselointi valittiin, ja vahvista vastaanottavalla puolella, että vastapuoli hyväksyi sen. Kaksi natiiville ESP:lle määritettyä päätelaitetta lähettävät edelleen natiivia ESP:tä riippumatta siitä, mitä sääntöjoukko sanoo.

TCP- tai UDP-pohjainen VPN sopii dokumentoituun kuljetusjoukkoon ja voi silti epäonnistua reitityksen, suodatuksen tai todennuksen vuoksi. Joukkoon sopiminen on välttämätöntä, ei riittävää.

Tarkista polku ennen käytännön laajentamista

Varmista työkuorman aliverkon todellinen reitti ja sen seuraavan hypyn identiteetti ensin. Suora julkinen polku, NAT-instanssi, hallittu NAT-yhdyskäytävä ja yksityinen polku siirtoyhdyskäytävän kautta ovat neljä eri suunnittelua, ja vain yksi niistä on tässä kuvattu hallittu palvelu.

Tallenna sitten yritetty päätepiste, osoiteperhe, ulkoinen protokolla ja portti, jos protokollalla on sellainen. Käytä asiakkaan diagnostiikkaa ja verkon omistajan virtaushavaintoja onnistuneen selainpyynnön sijaan, joka todistaa vain, että TCP ja UDP toimivat. Tarkista sen jälkeen tietoturvaryhmä, aliverkon ACL, vieraan palomuuri ja palvelukäytäntö virran molempiin suuntiin.

Älä avaa kaikkea liikennettä kompensoidaksesi kuljetusta, jota palvelu ei voi kuljettaa. Sääntömuutos ei korjaa sitä, ja se elää tapauksen jälkeen.

Kun kuljetus ei sovi

Jos ulkoinen protokolla on tuetun joukon ulkopuolella, korjaus on arkkitehtoninen: valitse kuljetus, jonka polku voi kuljettaa, tai siirrä lähtevä liikenne johonkin, joka kuljettaa tarvitsemasi. OpenVPN UDP:n yli, WireGuard UDP:n yli ja TLS-pohjaiset tunnelit sopivat kaikki dokumentoituun joukkoon. Asiakkaan hallitsema NAT-instanssi on vaihtoehto, kun tietyn protokollan on päästävä läpi ja sen käytön kustannus on hyväksyttävä.

Saapuvan VPN-palvelimen isännöinti on erillinen ongelma, jolla on erillinen vastaus. NAT-yhdyskäytävä tarjoaa lähtevän käännöksen eikä yleistä saapuvien porttien edelleenohjausta, joten sen takana oleva palvelin tarvitsee oman hyväksytyn julkisen sisäänkäyntinsä, joka on suunniteltu omilla ehdoillaan.

Työjärjestys: nimeä ulkoinen protokolla, vahvista seuraava hyppy, vertaa sitä dokumentoituun joukkoon ja muuta sitten arkkitehtuuria tai kuljetusta. Toinen porttinumero ei voi muuttaa GRE:tä TCP:ksi, eikä yksi sallivampi sääntö voi muuttaa valmista ohjausvaihtoa toimivaksi datakanavaksi.