Miks GRE ja ESP ei läbi AWS NAT-lüüsi

Tunnel ei tööta, turvagrupp lubab juba kogu liiklust ja järeldatakse, et AWS blokeerib VPN-i. See ei blokeeri midagi. Hallatav NAT-lüüs edastab dokumenteeritud kogumi välisprotokolle ning natiivne GRE või natiivne ESP ei kuulu selle hulka, seega ükski lisatud reegel ei pane lüüsi neid kandma. Lubamisreegel ja transpordivõimekus on kaks eri asja ning ainult ühte neist saate teie muuta.

Reeglistik ei ole protokollistik

Turvagrupp otsustab, millisel liiklusel on lubatud instantsist lahkuda. NAT-lüüs otsustab, mida see suudab tõlkida ja edasi saata. Kui kehtib teine piirang, tekitab lubav reegel täpselt selle sümptomi, mida inimesed loevad ekslikult tulemüüri probleemiks: paketid lahkuvad instantsist, juhtimisvahetus võib isegi lõpule jõuda ja partnerini ei jõua midagi.

AWS-i NAT-lüüsi protokollispetsifikatsioon loetleb hallatava teenuse jaoks TCP, UDP ja ICMP. See on kogu toetatud kogum. Teise IP-protokolli lubamisreegel ei saa seda laiendada, sest reeglit hinnatakse kaua enne, kui jõutakse lüüsi edastusteele.

See erinevus on oluline, sest kaks tõrget näevad kliendi poolelt identsed välja ja neil on täiesti erinevad parandused.

PPTP näitab, miks porditest valetab

PPTP on kõige selgem vana näide pordikontrollist, mis ei tõesta midagi. See avab TCP juhtühenduse pordil 1723 ja kannab seejärel tunneli andmeid GRE kaudu, mis on IP-protokoll 47. Protokoll 47 ei ole TCP port 47 ja neil kahel numbril pole teineteisega midagi ühist peale numbrite jagamise.

Operaator, kes testib ühenduvust pordile 1723 ja näeb lõpetatud kätlust, järeldab, et tee töötab. Seejärel ei läbi andmekanal kunagi ühtegi paketti, sest lüüsil pole pakkuda GRE-tuge. See on vana protokolli nõuete tõlgendus, mitte soovitus PPTP-d juurutada, mis on juba aastaid vananenud.

Sama loogika kehtib iga protokolli kohta, mille juhtkanal on TCP või UDP, samas kui selle andmetee seda ei ole.

IPsec jääb püsima ainult UDP-na

IPsec on juhtum, kus vastus on tingimuslik, mitte otsene ei. AWS dokumenteerib NAT-i läbimise toetatud lahendusena IPsecile läbi NAT-lüüsi. Kokkulepitud NAT-T korral kapseldatakse ESP UDP sisse ja lüüs näeb tavalist UDP-d protokolli 50 asemel.

UDP 4500 lubamine ei pane lõpp-punkte NAT-i läbimist kasutama. See lubab pakette ainult siis, kui need on juba sellise kujuga. Kinnitage kliendi enda läbirääkimise väljundist, milline kapseldus valiti, ja kinnitage vastuvõtva poole peal, et partner selle vastu võttis. Kaks natiivse ESP jaoks seadistatud lõpp-punkti jätkavad natiivse ESP saatmist, ükskõik mida reeglistik ütleb.

TCP- või UDP-põhine VPN sobib dokumenteeritud transpordikogumisse ja võib siiski ebaõnnestuda marsruutimise, filtreerimise või autentimise tõttu. Kogumisse sobimine on vajalik, mitte piisav.

Kontrollige teed enne poliitika laiendamist

Kontrollige töökoormuse alamvõrgu tegelikku marsruuti ja selle järgmise hüppe identiteeti kõigepealt. Otsene avalik tee, NAT-i eksemplar, hallatav NAT-lüüs ja privaatne tee läbi transiitlüüsi on neli erinevat lahendust ning ainult üks neist on siin kirjeldatud hallatav teenus.

Seejärel registreerige proovitud lõpp-punkt, aadressiperekond, väline protokoll ja port, kui protokollil see on. Kasutage kliendi diagnostikat ja võrguomaniku voovaatlusi, mitte õnnestunud brauseripäringut, mis tõestab ainult seda, et TCP ja UDP töötavad. Pärast seda vaadake üle turvagrupp, alamvõrgu ACL, külalise tulemüür ja teenusepoliitika voo mõlemas suunas.

Ärge avage kogu liiklust, et kompenseerida transporti, mida teenus kanda ei suuda. Reegli muutmine ei paranda seda ja see elab juhtumist kauem.

Kui transport ei sobi

Kui väline protokoll on väljaspool toetatud kogumit, on parandus arhitektuurne: valige transport, mida tee suudab kanda, või viige väljund millelegi, mis kannab vajalikku. OpenVPN UDP kaudu, WireGuard UDP kaudu ja TLS-põhised tunnelid sobivad kõik dokumenteeritud kogumisse. Kliendi hallatav NAT-i eksemplar on valik siis, kui konkreetne protokoll peab läbi minema ja selle käitamise tegevuskulu on vastuvõetav.

Sissetuleva VPN-serveri majutamine on eraldi probleem eraldi vastusega. NAT-lüüs pakub väljuvat tõlget ja üldist sissetulevate portide edasisaatmist ei pakuta, seega vajab selle taga olev server oma kinnitatud avalikku sissepääsu, mis on kavandatud omadel tingimustel.

Töö järjekord: nimetage väline protokoll, kinnitage järgmine hüpe, võrrelge seda dokumenteeritud kogumiga ja seejärel muutke arhitektuuri või transporti. Teistsugune pordi number ei saa muuta GRE-d TCP-ks ja veel üks lubav reegel ei saa muuta lõpetatud juhtimisvahetust töötavaks andmekanaliks.