Ping přes VPN: proč pravidla pro odpověď echa míjí zpáteční cestu

Pošlete ping na hostitele přes VPN a požadavek odchází s jedním typem ICMP a vrací se s jiným, což stačí k zmatení každého pravidla napsaného v pojmech portů. V echové výměně není žádný cílový servisní port, který by se dal zkopírovat do zpátečního pravidla, a filtr, který očekává symetrii, odpověď zahodí, zatímco požadavek proplouvá. Oprava začíná čtením paketu takového, jaký skutečně je, a pak rozhodnutím, která hranice na cestě rozhodnutí dělá. Obvykle pracují dvě vrstvy, zatímco třetí odpověď tiše zahazuje. Následující oddíly je oddělují v pořadí, v jakém je paket potkává.

Paket mění typ, ne port

Echový požadavek je ICMP typu 8, kódu 0, a nese identifikátor a pořadové číslo. Odpověď je typu 0, kódu 0, se stejným identifikátorem a pořadovým číslem a s prohozenými koncovými body IP. Tyto položky definuje RFC 792 a právě identifikátor umožňuje odesílateli párovat odpovědi s vlastními požadavky.

To, co chybí, je stejně důležité: neexistuje hlavička TCP ani UDP, takže není žádný port, který by se měl povolit. Pravidlo, které pro odpověď echa pojmenovává port, popisuje paket, který nikdy nevznikne. To je nejčastější chyba ve VPN ping tiketech. Pravidlo vypadá konkrétně, nevztahuje se na nic a nechává závadu přesně tam, kde byla.

O paketu rozhodují tři kontexty

Pokud ping cílí na hostitele ve vzdálené LAN, musí požadavek přeposlat brána. Pokud cílí na adresu, která patří samotné bráně, končí v lokální vstupní cestě. Pokud ping iniciuje brána, paket začíná ve vlastní výstupní cestě a rozhodnutí o přeposílání vůbec neprochází.

Tyto tři kontexty mají různé řetězce pravidel a různé čítače a právě jejich slévání v jeden je důvod, proč „firewall povoluje ICMP“ může stále dávat neúspěšný ping. Vnější tunel je čtvrtý kontext: povolení VPN listeneru automaticky nepovolí dekapsulovaný vnitřní požadavek a vnitřní povolení nic neříká o tom, zda je vnější tunel nahoře.

Stateful a stateless filtry zpracovávají odpověď odlišně

Stateful firewall, který viděl požadavek odcházet, může odpověď přiřadit k tomu toku a pustit ji bez druhého pravidla. Stateless filtr takovou paměť nemá, takže zpětný směr potřebuje vlastní výslovné povolení, s prohozeným zdrojem a cílem.

Než něco napíšete, ověřte, který model produkt skutečně implementuje. Pravidlo pro echový požadavek nemusí nutně pokrývat odpověď echa a produkt, který sleduje ICMP dotazy, může na odpovědi přicházející jiným rozhraním uplatňovat jinou politiku.

Omezte, co povolujete. Povolit každou odpověď echa odkoliv není totéž jako dokončit stavové přiřazení a číslo typu neověřuje odesílatele.

Překlad mění i identifikátor

Pokud je překlad zdroje záměrný, tuple na vzdáleném konci neodpovídá tomu, které poslal klient. NAT může přeložit identifikátor ICMP dotazu spolu s adresami, takže trvání na tom, aby se stejné číslo objevilo na obou stranách, vytváří falešný nesoulad.

Sledujte místo toho mapování, které hlásí překladač. Překladač, který přepisuje identifikátor, nezachová číslo, které váš klient zaznamenal, takže za identitu považujte mapování, nikoli číslo. Potom sledujte jeden identifikovatelný požadavek celou cestou: ověřte, že dorazí do cíle s očekávaným zdrojem, ověřte, že cíl vyslal odpověď, sledujte trasu této odpovědi zpět, a ověřte, že ji klient obdržel, místo abyste jen sledovali, jak roste čítač brány.

Neslévejte chyby ICMP do politiky echa

Zpráva „nutná fragmentace“, kterou používá zjišťování MTU cesty, není odpověď echa a její obsah cituje paket, který ji vyvolal. Povolení pouze pro echo, které tyto chyby tiše zahazuje, mění problém velikosti v visící spojení, což je opakem užitečnosti.

Stejná opatrnost platí pro rodiny adres. ICMPv6 používá jiné typy zpráv a nese podstatné funkce, které IPv4 nemá, takže kopírovat tato čísla do pravidla IPv6 je prostě chyba.

Když echová výměna funguje, otestujte skutečnou aplikaci zvlášť. Úspěšný ping dokazuje cestu tam a zpět jednoho protokolu, jedné velikosti a do jednoho cíle, a není licencí předpokládat, že HTTPS, SMB nebo jakýkoli jiný tok je povolen.