Kial GRE kaj ESP malsukcesas tra AWS NAT-pordego

La tunelo malsukcesas, la sekureca grupo jam permesas la tutan trafikon, kaj la konkludo estas, ke AWS blokas la VPN-on. Ĝi blokas nenion. Administrata NAT-pordego plusendas dokumentitan aron de eksteraj protokoloj, kaj denaskaj GRE aŭ denaskaj ESP ne estas en ĝi, do neniu regulo, kiun vi aldonas, igos la pordegon porti ilin. La permesa regulo kaj la transportkapablo estas du malsamaj aferoj, kaj nur unu el ili estas via por ŝanĝi.

La regulsaro ne estas la protokolsaro

Sekureca grupo decidas, kiu trafiko rajtas forlasi la instancon. La NAT-pordego decidas, kion ĝi kapablas traduki kaj plusendi. Kiam validas la dua limo, permesa regulo produktas ĝuste la simptomon, kiun homoj mislegas kiel fajroŝirma problemo: pakaĵoj forlasas la instancon, la kontrola interŝanĝo eĉ povas finiĝi, kaj nenio alvenas al la kunulo.

La protokola specifiko de NAT-pordego de AWS listigas TCP, UDP kaj ICMP por la administrata servo. Tio estas la tuta subtenata aro. Permesa regulo por alia IP-protokolo ne povas etendi ĝin, ĉar la regulo estas taksata longe antaŭ ol la plusenda vojo de la pordego estas atingita.

La distingo gravas, ĉar la du fiaskoj aspektas identaj de la kliento kaj havas tute malsamajn korektojn.

PPTP montras, kial porda testo mensogas

PPTP estas la plej klara malnova ekzemplo de porda kontrolo, kiu pruvas nenion. Ĝi malfermas TCP-kontrolan konekton sur pordo 1723 kaj poste portas la tunelajn datumojn tra GRE, kiu estas IP-protokolo 47. Protokolo 47 ne estas TCP-pordo 47, kaj la du nombroj havas nenion komunan krom dividi ciferojn.

Operatoro, kiu testas konekteblecon al 1723 kaj vidas finitan manpremon, konkludas, ke la vojo funkcias. Poste la datuma kanalo neniam pasigas eĉ unu pakaĵon, ĉar la pordego ne havas GRE-subtenon por proponi. Tio estas interpreto de la postuloj de malnova protokolo, ne konsilo uzi PPTP, kiu estas eksmoda de jaroj.

La sama rezonado validas por ĉiu protokolo, kies kontrola kanalo estas TCP aŭ UDP, dum ĝia datuma vojo ne estas.

IPsec postvivas nur kiel UDP

IPsec estas la kazo, kie la respondo estas kondiĉa anstataŭ firma ne. AWS dokumentas NAT-traversal kiel la subtenatan aranĝon por IPsec tra NAT-pordego. Kun interkonsentita NAT-T, ESP estas enkapsuligita en UDP kaj la pordego vidas ordinaran UDP anstataŭ protokolo 50.

Permesi UDP 4500 ne igas finpunktojn uzi NAT-traversal. Ĝi nur permesas la pakaĵojn, se ili jam estas tiel formitaj. Konfirmu el la propra interkonsenta eligo de la kliento, kiu enkapsuligo estis elektita, kaj konfirmu ĉe la ricevanta flanko, ke la kunulo akceptis ĝin. Du finpunktoj agorditaj por denaska ESP daŭre sendos denaskan ESP, kion ajn diras la regulsaro.

TCP- aŭ UDP-bazita VPN konformas al la dokumentita transportaro kaj tamen povas malsukcesi pro enkursigado, filtrado aŭ aŭtentikigo. Konformi al la aro estas necesa, ne sufiĉa.

Kontrolu la vojon antaŭ ol larĝigi la politikon

Kontrolu la faktan itineron de la laborŝarĝa subreto kaj la identecon de ĝia sekva salto unue. Rekta publika vojo, NAT-instance, administrata NAT-pordego kaj privata vojo tra transita pordego estas kvar malsamaj dezajnoj, kaj nur unu el ili estas la administrata servo priskribita ĉi tie.

Poste registru la provitan finpunkton, la adresan familion, la eksteran protokolon kaj la pordon, kie la protokolo havas unu. Uzu la diagnozon de la kliento kaj la fluobservojn de la retposedanto anstataŭ sukcesa retumila peto, kiu pruvas nur, ke TCP kaj UDP funkcias. Post tio, revizuu la sekurecan grupon, la subretan ACL, la gastan fajroŝirmon kaj la servan politikon por ambaŭ direktoj de la fluo.

Ne malfermu la tutan trafikon por kompensi transporton, kiun la servo ne povas porti. La regula ŝanĝo ne riparos ĝin, kaj ĝi postvivos la incidenton.

Kiam la transporto ne konformas

Se la ekstera protokolo estas ekster la subtenata aro, la solvo estas arkitektura: elektu transporton, kiun la vojo povas porti, aŭ movu la eliron al io, kio portas la bezonatan. OpenVPN super UDP, WireGuard super UDP kaj TLS-bazitaj tuneloj ĉiuj konformas al la dokumentita aro. Klient-administrata NAT-instance estas la opcio, kiam specifa protokolo devas pasi kaj la operacia kosto de ĝia funkciigado estas akceptebla.

Gastigi envenantan VPN-servilon estas aparta problemo kun aparta respondo. NAT-pordego provizas eliran tradukadon kaj neniun ĝeneralan envenantan pordplusendadon, do servilo malantaŭ ĝi bezonas sian aprobitan publikan eniron desegnitan laŭ propraj kondiĉoj.

Ordo de laboro: nomu la eksteran protokolon, konfirmu la sekvan salton, komparu ĝin kun la dokumentita aro, poste ŝanĝu arkitekturon aŭ transporton. Alia porda numero ne povas ŝanĝi GRE en TCP, kaj pli permesa regulo ne povas ŝanĝi finitan kontrolan interŝanĝon en funkciantan datuman kanalon.