Ping tra VPN: kial reguloj por eĥo-respondo maltrafas la revenan vojon

Sendu ping al gastiganto tra VPN kaj la peto eliras kiel unu ICMP-tipo kaj revenas kiel alia, kio sufiĉas por konfuzi ĉiun regulon skribitan laŭ pordoj. En eĥa interŝanĝo mankas cela serva pordo kopiebla en la revenan regulon, kaj filtrilo, kiu atendas simetrion, forĵetos la respondon dum la peto pasas senĝene. La korekto komenciĝas per legado de la paketo tia, kia ĝi vere estas, kaj poste per decido, kiu limo sur la vojo faras la decidon. Kutime du tavoloj laboras dum la tria silenteme forĵetas la respondon. La sekvaj sekcioj apartigas ilin laŭ la ordo, en kiu paketo renkontas ilin.

La paketo ŝanĝas tipon, ne pordon

Eĥa peto estas ICMP tipo 8, kodo 0, kaj portas identigilon kaj sekvencan numeron. La respondo estas tipo 0, kodo 0, kun la sama identigilo kaj sekvenco, kaj la IP-finpunktoj interŝanĝitaj. RFC 792 difinas tiujn kampojn, kaj ĝuste la identigilo ebligas al sendinto parigi respondojn kun siaj propraj petoj.

Tio, kio mankas, estas same grava: ne ekzistas TCP aŭ UDP kaplinio, do ne ekzistas pordo por permesi. Regulo, kiu nomas pordon por eĥo-respondo, priskribas paketon, kiu neniam ekzistos. Ĉi tio estas la plej ofta eraro en VPN-ping-biletoj. La regulo aspektas specifa, aplikas al nenio kaj lasas la malsukceson ĝuste tie, kie ĝi estis.

Tri kuntekstoj decidas pri la paketo

Se la ping celas gastiganton en la fora LAN, la peto devas esti plusendita de la kluzo. Se ĝi celas adreson, kiu apartenas al la kluzo mem, ĝi finiĝas en la loka eniga vojo anstataŭe. Se la kluzo mem originas la ping, la paketo komenciĝas en sia propra eliga vojo kaj tute ne trapasas la plusendan decidon.

Tiuj tri kuntekstoj havas malsamajn regulĉenojn kaj malsamajn nombrilojn, kaj trakti ilin kiel unu estas la kialo, kial «la fajroŝirmilo permesas ICMP» ankoraŭ povas doni malsukcesan ping. La ekstera tunelo estas kvara kunteksto: permesi la VPN-auskultanton ne aŭtomate permesas la malĉifritan internan peton, kaj interna permeso diras nenion pri tio, ĉu la ekstera tunelo estas supre.

Statecaj kaj senstatecaj filtriloj traktas la respondon malsame

Stateca fajroŝirmilo, kiu vidis la peton eliri, povas ligi la respondon al tiu fluo kaj enlasi ĝin sen dua regulo. Senstateca filtrilo ne havas tian memoron, do la revena direkto bezonas sian propran eksplicitan permeson, kun fonto kaj celo interŝanĝitaj.

Kontrolu, kiun modelon la produkto efektive realigas, antaŭ ol skribi ion ajn. Regulo por eĥa peto ne nepre kovras eĥo-respondon, kaj produkto, kiu spuras ICMP-demandojn, povas ankoraŭ apliki alian politikon al respondoj alvenantaj sur alia interfaco.

Limigu tion, kion vi permesas. Permesi ĉiun eĥo-respondon de ie ajn ne samas al kompletigo de stateca asociiĝo, kaj tipa numero ne aŭtentikigas la sendinton.

Traduko ŝanĝas ankaŭ la identigilon

Se fonta traduko estas intenca, la opo ĉe la fora fino ne kongruas kun tiu, kiun la kliento sendis. NAT povas traduki la identigilon de la ICMP-demando kune kun la adresoj, do insisti, ke la sama numero aperu ĉe ambaŭ flankoj, kreas falsan malkongruon.

Anstataŭe korelaciu la mapadon, kiun raportas la tradukilo. Tradukilo, kiu reverkas la identigilon, ne konservos la numeron, kiun via kliento registris, do traktu la mapadon kiel la identecon, ne la numeron. Poste spuru unu identigeblan peton laŭ la vojo: konfirmu, ke ĝi atingas la celon kun la atendata fonto, konfirmu, ke la celo elsendis respondon, spuru la vojon de tiu respondo reen, kaj konfirmu, ke la kliento ricevis ĝin anstataŭ simple rigardi kluzan nombrilon kreski.

Ne enmetu ICMP-erarojn en la eĥan politikon

La mesaĝo «fragmentado necesa», kiun uzas malkovro de voja MTU, ne estas eĥo-respondo, kaj ĝia utileco citas la paketon, kiu ĝin kaŭzis. Permeso nur por eĥo, kiu silenteme forĵetas tiujn erarojn, ŝanĝas grandecan problemon en pendantan konekton, kio estas la malo de helpe.

La sama singardo validas por adresaj familioj. ICMPv6 uzas malsamajn mesaĝtipojn kaj portas esencajn funkciojn, kiujn IPv4 ne havas, do kopii ĉi tiujn numerojn en IPv6-regulon estas simple malĝuste.

Kiam la eĥa interŝanĝo funkcias, testu la realan aplikaĵon aparte. Sukcesa ping pruvas la ir-revenan vojon de unu protokolo, je unu grandeco, al unu celo, kaj ĝi ne estas permesilo supozi, ke HTTPS, SMB aŭ iu ajn alia fluo estas permesita.