Pse GRE dhe ESP dështojnë përmes një gateway NAT të AWS

Tuneli dështon, grupi i sigurisë tashmë lejon të gjithë trafikun, dhe përfundimi është se AWS po bllokon VPN-në. Nuk bllokon asgjë. Një gateway NAT i menaxhuar përcjell një grup të dokumentuar protokollesh të jashtme, dhe GRE origjinal ose ESP origjinal nuk janë në të, prandaj asnjë rregull që shtoni nuk do ta bëjë gateway-in t'i mbajë ato. Rregulli i lejes dhe aftësia e transportit janë dy gjëra të ndryshme, dhe vetëm njëra prej tyre është në dorën tuaj për t'u ndryshuar.

Grupi i rregullave nuk është grupi i protokolleve

Një grup sigurie vendos cili trafik lejohet të largohet nga instanca. Gateway-i NAT vendos çfarë mund të përkthejë dhe të përcjellë. Kur zbatohet kufiri i dytë, një rregull lejues prodhon pikërisht simptomën që njerëzit e lexojnë gabimisht si problem i murit të zjarrit: paketat largohen nga instanca, shkëmbimi i kontrollit mund edhe të përfundojë, dhe asgjë nuk arrin te pala tjetër.

Specifikimi i protokolleve të gateway-it NAT nga AWS liston TCP, UDP dhe ICMP për shërbimin e menaxhuar. Ky është i gjithë grupi i mbështetur. Një rregull leje për një protokoll tjetër IP nuk mund ta zgjerojë atë, sepse rregulli vlerësohet shumë përpara se të arrihet rruga e përcjelljes së gateway-it.

Dallimi ka rëndësi sepse të dyja dështimet duken identike nga ana e klientit dhe kanë rregullime krejtësisht të ndryshme.

PPTP tregon pse një test porte gënjen

PPTP është shembulli më i qartë i vjetër i një kontrolli porte që nuk provon asgjë. Hap një lidhje kontrolli TCP në portën 1723 dhe më pas transporton të dhënat e tunelit përmes GRE, që është protokolli IP 47. Protokolli 47 nuk është porta TCP 47, dhe këta dy numra nuk kanë asgjë të përbashkët përveç ndarjes së shifrave.

Një operator që teston lidhjen me 1723 dhe sheh një shtrëngim duarsh të përfunduar arrin në përfundimin se rruga funksionon. Më pas kanali i të dhënave nuk kalon asnjë paketë të vetme, sepse gateway-i nuk ka asnjë mbështetje GRE për të ofruar. Ky është një interpretim i kërkesave të një protokolli të vjetër, jo një këshillë për të vendosur PPTP, i cili është vjetruar prej vitesh.

I njëjti arsyetim vlen për çdo protokoll, kanali i kontrollit i të cilit është TCP ose UDP, ndërsa rruga e të dhënave e tij nuk është.

IPsec mbijeton vetëm si UDP

IPsec është rasti kur përgjigja është e kushtëzuar dhe jo një jo e prerë. AWS dokumenton kalimin NAT si rregullimin e mbështetur për IPsec përmes një gateway NAT. Me NAT-T të negociuar, ESP kapsulohet brenda UDP dhe gateway-i sheh UDP të zakonshëm në vend të protokollit 50.

Lejimi i UDP 4500 nuk i bën pikat fundore të përdorin kalimin NAT. Ai lejon paketat vetëm nëse ato janë formuar tashmë kështu. Konfirmoni nga dalja e negociimit të vetë klientit se cila kapsulim u zgjodh, dhe konfirmoni në anën marrëse se pala tjetër e pranoi atë. Dy pika fundore të konfiguruara për ESP origjinal do të vazhdojnë të dërgojnë ESP origjinal, çfarëdo që thotë grupi i rregullave.

Një VPN i bazuar në TCP ose UDP përshtatet me grupin e transportit të dokumentuar dhe mund të dështojë gjithsesi për arsye rrugëtimi, filtrimi ose vërtetimi. Përshtatja me grupin është e nevojshme, jo e mjaftueshme.

Kontrolloni rrugën përpara se të zgjeroni politikën

Verifikoni rrugën aktuale të nënrrjetit të ngarkesës së punës dhe identitetin e hop-it të tij të ardhshëm së pari. Një rrugë publike e drejtpërdrejtë, një instancë NAT, një gateway NAT i menaxhuar dhe një rrugë private përmes një gateway tranziti janë katër modele të ndryshme, dhe vetëm njëri prej tyre është shërbimi i menaxhuar i përshkruar këtu.

Më pas regjistroni pikën fundore të provuar, familjen e adresave, protokollin e jashtëm dhe portën ku protokolli ka një të tillë. Përdorni diagnostikimin e klientit dhe vëzhgimet e rrjedhës të pronarit të rrjetit në vend të një kërkese të suksesshme shfletuesi, e cila provon vetëm se TCP dhe UDP funksionojnë. Pas kësaj, rishikoni grupin e sigurisë, ACL-në e nënrrjetit, murin e zjarrit të mysafirit dhe politikën e shërbimit për të dy drejtimet e rrjedhës.

Mos hapni të gjithë trafikun për të kompensuar një transport që shërbimi nuk mund ta mbajë. Ndryshimi i rregullit nuk do ta rregullojë, dhe ai do t'i mbijetojë incidentit.

Kur transporti nuk përshtatet

Nëse protokolli i jashtëm është jashtë grupit të mbështetur, rregullimi është arkitekturor: zgjidhni një transport që rruga mund të mbajë, ose zhvendosni daljen në diçka që mban atë që ju nevojitet. OpenVPN mbi UDP, WireGuard mbi UDP dhe titujt e bazuar në TLS përshtaten të gjithë me grupin e dokumentuar. Një instancë NAT e menaxhuar nga klienti është opsioni kur një protokoll specifik duhet të kalojë dhe kostoja operacionale e mbajtjes së tij është e pranueshme.

Strehimi i një serveri VPN hyrës është një problem i veçantë me një përgjigje të veçantë. Një gateway NAT ofron përkthim dalës dhe asnjë përcjellje të përgjithshme të portave hyrëse, prandaj një server pas tij ka nevojë për hyrjen e vet publike të miratuar, të projektuar sipas kushteve të veta.

Rendi i punës: emërtoni protokollin e jashtëm, konfirmoni hop-in e ardhshëm, krahasoni atë me grupin e dokumentuar, pastaj ndryshoni arkitekturën ose transportin. Një numër tjetër porte nuk mund ta kthejë GRE në TCP, dhe një rregull tjetër lejues nuk mund ta kthejë një shkëmbim kontrolli të përfunduar në një kanal të dhënash funksional.