Kodėl GRE ir ESP nepraeina pro AWS NAT tinklų sietuvą

Tunelis neveikia, saugos grupė jau leidžia visą srautą, o išvada – AWS blokuoja VPN. Ji nieko neblokuoja. Valdomas NAT tinklų sietuvas persiunčia dokumentuotą išorinių protokolų rinkinį, o vietinis GRE ar vietinis ESP į jį nepatenka, todėl jokia pridėta taisyklė neprivers sietuvo jų perduoti. Leidimo taisyklė ir perdavimo galimybė yra du skirtingi dalykai, ir tik vieną jų galite pakeisti.

Taisyklių rinkinys nėra protokolų rinkinys

Saugos grupė nusprendžia, kuriam srautui leidžiama palikti egzempliorių. NAT tinklų sietuvas nusprendžia, ką jis gali išversti ir persiųsti. Kai galioja antroji riba, leidžianti taisyklė sukuria būtent tą simptomą, kurį žmonės klaidingai skaito kaip ugniasienės problemą: paketai palieka egzempliorių, valdymo mainai gali net pasibaigti, o į partnerį niekas nepatenka.

AWS NAT tinklų sietuvo protokolų specifikacija valdomai paslaugai išvardija TCP, UDP ir ICMP. Tai visas palaikomas rinkinys. Kito IP protokolo leidimo taisyklė negali jo išplėsti, nes taisyklė vertinama gerokai anksčiau, nei pasiekiamas sietuvo persiuntimo kelias.

Šis skirtumas svarbus, nes abi klaidos iš kliento pusės atrodo vienodai ir turi visiškai skirtingus sprendimus.

PPTP parodo, kodėl prievado testas meluoja

PPTP yra ryškiausias senas prievado patikros, kuri nieko neįrodo, pavyzdys. Jis atidaro TCP valdymo ryšį 1723 prievade ir tada tunelio duomenis perduoda per GRE, kuris yra IP protokolas 47. Protokolas 47 nėra TCP prievadas 47, ir šie du skaičiai neturi nieko bendra, išskyrus skaitmenis.

Operatorius, kuris testuoja ryšį su 1723 ir mato baigtą rankos paspaudimą, daro išvadą, kad kelias veikia. Tada duomenų kanalas niekada nepraleidžia nė vieno paketo, nes sietuvas neturi GRE palaikymo, kurį galėtų pasiūlyti. Tai seno protokolo reikalavimų interpretacija, o ne patarimas diegti PPTP, kuris jau seniai pasenęs.

Tas pats samprotavimas galioja bet kuriam protokolui, kurio valdymo kanalas yra TCP arba UDP, o duomenų kelias – ne.

IPsec išlieka tik kaip UDP

IPsec yra atvejis, kai atsakymas yra sąlyginis, o ne griežtas ne. AWS dokumentuoja NAT perėjimą kaip palaikomą sprendimą IPsec per NAT tinklų sietuvą. Susiderėjus NAT-T, ESP įdedamas į UDP, ir sietuvas mato įprastą UDP, o ne 50 protokolą.

UDP 4500 leidimas nepriverčia galinių taškų naudoti NAT perėjimo. Jis tik leidžia paketus, jei jie jau suformuoti taip. Patvirtinkite iš paties kliento derybų išvesties, kokia inkapsuliacija buvo pasirinkta, ir patvirtinkite priėmimo pusėje, kad partneris ją priėmė. Du galiniai taškai, sukonfigūruoti vietiniam ESP, ir toliau siųs vietinį ESP, ką bebūtų sakoma taisyklių rinkinyje.

TCP arba UDP pagrindu veikiantis VPN telpa į dokumentuotą perdavimo rinkinį ir vis tiek gali nepavykti dėl maršrutizavimo, filtravimo ar autentifikavimo priežasčių. Telpti į rinkinį būtina, bet nepakanka.

Patikrinkite kelią prieš išplečiant politiką

Patikrinkite tikrąjį darbo krūvio potinklio maršrutą ir jo kito šuolio tapatybę pirmiausia. Tiesioginis viešas kelias, NAT egzempliorius, valdomas NAT tinklų sietuvas ir privatus kelias per tranzito sietuvą yra keturi skirtingi sprendimai, ir tik vienas jų yra čia aprašyta valdoma paslauga.

Tada užfiksuokite bandytą galinį tašką, adresų šeimą, išorinį protokolą ir prievadą, kai protokolas jį turi. Naudokite kliento diagnostiką ir tinklo savininko srauto stebėjimus, o ne sėkmingą naršyklės užklausą, kuri įrodo tik tai, kad TCP ir UDP veikia. Po to peržiūrėkite saugos grupę, potinklio ACL, svečio ugniasienę ir paslaugos politiką abiem srauto kryptims.

Neatverkite viso srauto, kad kompensuotumėte perdavimą, kurio paslauga negali perduoti. Taisyklės pakeitimas to neištaisys, ir jis išliks po incidento.

Kai perdavimas netinka

Jei išorinis protokolas yra už palaikomo rinkinio ribų, sprendimas architektūrinis: pasirinkite perdavimą, kurį kelias gali perduoti, arba perkelkite išėjimą į kažką, kas perduoda jums reikalingą. OpenVPN per UDP, WireGuard per UDP ir TLS pagrindu veikiantys tuneliai visi telpa į dokumentuotą rinkinį. Kliento valdomas NAT egzempliorius yra pasirinkimas, kai konkretus protokolas turi praeiti ir jo valdymo kaštai yra priimtini.

Įeinančio VPN serverio talpinimas yra atskira problema su atskiru atsakymu. NAT tinklų sietuvas teikia išėjimo vertimą ir neteikia bendro įeinančių prievadų persiuntimo, todėl serveriui už jo reikia savo patvirtinto viešo įėjimo, suprojektuoto pagal jo paties sąlygas.

Darbo tvarka: įvardykite išorinį protokolą, patvirtinkite kitą šuolį, palyginkite jį su dokumentuotu rinkiniu, tada keiskite architektūrą arba perdavimą. Kitas prievado numeris nepavers GRE į TCP, o dar viena leidžianti taisyklė nepavers baigtų valdymo mainų veikiančiu duomenų kanalu.