Zergatik huts egiten duten GRE eta ESP-ek AWS NAT atearen bidez

Tunelak huts egiten du, segurtasun taldeak jada trafiko guztia baimentzen du, eta ondorioa AWS-ek VPN-a blokeatzen duela da. Ez du ezer blokeatzen. Kudeatutako NAT ate batek kanpoko protokolo multzo dokumentatu bat birbidaltzen du, eta GRE natiboa edo ESP natiboa ez dago horretan, beraz gehitzen duzun edozein arauk ez du ateak horiek eramatea lortuko. Baimen araua eta garraio gaitasuna bi gauza desberdinak dira, eta horietako bat bakarrik dago zuk aldatzerik.

Arau multzoa ez da protokolo multzoa

Segurtasun talde batek erabakitzen du zein trafikok utz dezakeen instantzia. NAT ateak erabakitzen du zer itzuli eta birbidali dezakeen. Bigarren muga aplikatzen denean, arau permisibo batek jendeak suebaki arazo gisa gaizki irakurtzen duen sintoma sortzen du: paketeak instantziatik irteten dira, kontrol trukea are osa daiteke, eta ezer ez da iristen parekidera.

AWS-en NAT atearen protokolo zehaztapenak kudeatutako zerbitzurako TCP, UDP eta ICMP zerrendatzen ditu. Hori da onartutako multzo osoa. Beste IP protokolo batentzako baimen arau batek ezingo du handitu, araua atearen birbidaltze bidea iritsi baino askoz lehenago ebaluatzen delako.

Bereizketa garrantzitsua da, bi hutsegiteek bezeroaren ikuspegitik berdinak diruditelako eta konponbide erabat desberdinak dituztelako.

PPTP-k erakusten du zergatik gezurra esaten duen ataka proba batek

PPTP ezer frogatzen ez duen ataka egiaztapen baten adibide zahar argiena da. TCP kontrol konexio bat irekitzen du 1723 atakan eta gero tuneleko datuak GRE bidez eramaten ditu, hau da, IP 47 protokoloa. 47 protokoloa ez da TCP 47 ataka, eta bi zenbakiek ez dute elkarrekin zerikusirik zifrak partekatzeaz gain.

1723ra konektibitatea probatu eta esku-emate oso bat ikusten duen operadoreak bideak funtzionatzen duela ondorioztatzen du. Gero datu kanalak ez du inoiz pakete bakar bat ere pasatzen, ateak ez baitu eskaintzeko GRE euskarririk. Protokolo zahar baten baldintzen interpretazioa da, ez PPTP ezartzeko aholkua, urteak daramatzana zaharkituta.

Arrazoibide bera aplikatzen zaio kontrol kanala TCP edo UDP duen edozein protokolori, bere datu bidea hala ez den bitartean.

IPsec-ek UDP gisa baino ez du bizirauten

IPsec erantzuna baldintzapekoa den kasua da, ez ezezko biribila. AWS-k NAT zeharkatzea dokumentatzen du NAT ate baten bidezko IPsec-rako onartutako konponbidea bezala. NAT-T negoziatuta, ESP UDP barruan kapsulatzen da eta ateak UDP arrunta ikusten du 50 protokoloaren ordez.

UDP 4500 baimentzeak ez du lortzen muturrak NAT zeharkatzea erabiltzea. Paketeak baimentzen ditu soilik jada horrela moldatuta badaude. Egiaztatu bezeroaren negoziazio irteeran zein kapsulatze aukeratu zen, eta egiaztatu hartzailearen aldean parekideak onartu zuela. ESP natiborako konfiguratutako bi muturrek ESP natiboa bidaltzen jarraituko dute, arau multzoak esaten duena edozein delarik ere.

TCP edo UDP oinarritutako VPN bat garraio multzo dokumentatuan sartzen da eta hala ere huts egin dezake bideratze, iragazte edo autentikazio arrazoiengatik. Multzoan sartzea beharrezkoa da, ez nahikoa.

Egiaztatu bidea politika zabaldu aurretik

Egiaztatu lan-kargaren azpisarearen benetako bidea eta hurrengo jauziaren identitatea lehenengo. Bide publiko zuzena, NAT instantzia bat, kudeatutako NAT ate bat eta transit ate baten bidezko bide pribatu bat lau diseinu desberdin dira, eta horietako bat bakarrik da hemen deskribatutako kudeatutako zerbitzua.

Ondoren erregistratu saiatutako muturra, helbide familia, kanpoko protokoloa eta ataka, protokoloak ataka duen tokian. Erabili bezeroaren diagnostikoak eta sarearen jabearen fluxu behaketak, nabigatzaile eskaera arrakastatsuaren ordez, azken horrek TCP eta UDP funtzionatzen dutela soilik frogatzen baitu. Horren ondoren, berrikusi segurtasun taldea, azpisarearen ACL-a, gonbidatuaren suebakia eta zerbitzuaren politika fluxuaren bi noranzkoetarako.

Ez ireki trafiko guztia zerbitzuak eraman ezin duen garraio bat konpentsatzeko. Arau aldaketak ez du konponduko, eta gertaeraren ondoren biziko da.

Garraioa egokitzen ez denean

Kanpoko protokoloa onartutako multzotik kanpo badago, konponbidea arkitektonikoa da: aukeratu bideak eraman dezakeen garraio bat, edo mugitu irteera behar duzuna eramaten duen zerbaitetara. OpenVPN UDP bidez, WireGuard UDP bidez eta TLS oinarritutako tunelak multzo dokumentatuan sartzen dira guztiak. Bezeroak kudeatutako NAT instantzia da aukera protokolo zehatz batek pasa behar duenean eta hura exekutatzeko kostua onargarria denean.

Sarrerako VPN zerbitzari bat ostatatzea erantzun bereizi bat duen arazo bereizia da. NAT ate batek irteerako itzulpena eskaintzen du eta ez du sarrerako ataken birbidalketa orokorrik, beraz atzean dagoen zerbitzariak bere sarbide publiko onartua behar du bere baldintzetan diseinatuta.

Lan ordena: izendatu kanpoko protokoloa, egiaztatu hurrengo jauzia, alderatu multzo dokumentatuarekin, eta gero aldatu arkitektura edo garraioa. Ataka zenbaki desberdin batek ezin du GRE TCP bihurtu, eta arau permisibo batek gehiagok ezin du kontrol truke osoa datu kanal funtzional bihurtu.