Ping genom en VPN: varför regler för eko-svar missar returvägen

Pinga en värd genom en VPN och begäran går ut med en ICMP-typ och kommer tillbaka med en annan, vilket räcker för att förvirra varje regel som skrivs i porttermer. Det finns ingen destinationstjänsteport i ett ekoutbyte att kopiera in i returregeln, och ett filter som förväntar sig symmetri släpper svaret medan begäran passerar obehindrat. Rättelsen börjar med att läsa paketet som det faktiskt är och sedan avgöra vilken gräns på vägen som fattar beslutet. Vanligtvis arbetar två lager medan det tredje tyst släpper svaret. Avsnitten nedan skiljer dem i den ordning ett paket möter dem.

Paketet byter typ, inte port

En ekobegäran är ICMP-typ 8, kod 0, och bär en identifierare och ett sekvensnummer. Svaret är typ 0, kod 0, med samma identifierare och sekvens, och IP-ändpunkterna ombytta. RFC 792 definierar dessa fält, och identifieraren är det som låter en avsändare matcha svar med sina egna begäranden.

Det som saknas är lika viktigt: det finns ingen TCP- eller UDP-rubrik, så det finns ingen port att tillåta. En regel som namnger en port för ett eko-svar beskriver ett paket som aldrig kommer att finnas. Detta är det vanligaste felet i VPN-pingärenden. Regeln ser specifik ut, gäller ingenting och lämnar felet exakt där det var.

Tre sammanhang avgör paketet

Om pinget riktar sig mot en värd på det avlägsna LAN:et måste begäran vidarebefordras av gatewayen. Om det riktar sig mot en adress som tillhör gatewayen själv avslutas det i den lokala ingångsvägen i stället. Om gatewayen själv initierar pinget börjar paketet i dess egen utgångsväg och passerar aldrig vidarebefordringsbeslutet.

Dessa tre sammanhang har olika regelkedjor och olika räknare, och att behandla dem som ett är anledningen till att ”brandväggen tillåter ICMP” ändå kan ge ett misslyckat ping. Den yttre tunneln är ett fjärde sammanhang: att tillåta VPN-lyssnaren tillåter inte automatiskt den avkapslade inre begäran, och ett inre tillstånd säger ingenting om huruvida den yttre tunneln är uppe.

Stateful och stateless filter hanterar svaret olika

En stateful brandvägg som såg begäran gå ut kan koppla svaret till det flödet och släppa in det utan en andra regel. Ett stateless filter har inget sådant minne, så returriktningen behöver sitt eget uttryckliga tillstånd, med källa och destination ombytta.

Kontrollera vilken modell produkten faktiskt implementerar innan du skriver något. En regel för ekobegäran täcker inte nödvändigtvis eko-svar, och en produkt som följer ICMP-frågor kan ändå tillämpa en annan policy på svar som anländer på ett annat gränssnitt.

Begränsa vad du tillåter. Att tillåta varje eko-svar från var som helst är inte samma sak som att slutföra en stateful koppling, och ett typnummer autentiserar inte avsändaren.

Översättning ändrar också identifieraren

Om källöversättning är avsiktlig matchar inte tupeln i den avlägsna änden den som klienten skickade. En NAT kan översätta ICMP-frågans identifierare tillsammans med adresserna, så att insistera på att samma nummer visas på båda sidor ger en falsk avvikelse.

Korrelera i stället den mappning som översättaren rapporterar. En översättare som skriver om identifieraren bevarar inte numret som din klient loggade, så behandla mappningen som identiteten och inte numret. Följ sedan en identifierbar begäran genom vägen: bekräfta att den når destinationen med den förväntade källan, bekräfta att destinationen sände ett svar, följ den svarspaketets väg tillbaka, och bekräfta att klienten tog emot det i stället för att bara se en gateway-räknare stiga.

Blanda inte in ICMP-fel i ekopolicyn

Meddelandet ”fragmentering krävs” som path-MTU-upptäckten använder är inte ett eko-svar, och dess nyttolast citerar paketet som utlöste det. Ett tillstånd enbart för eko som tyst kastar bort dessa fel förvandlar ett storleksproblem till en hängande anslutning, vilket är motsatsen till användbart.

Samma försiktighet gäller adressfamiljer. ICMPv6 använder andra meddelandetyper och bär väsentliga funktioner som IPv4 inte har, så att kopiera dessa nummer till en IPv6-regel är helt enkelt fel.

När ekoutbytet fungerar, testa den verkliga applikationen separat. Ett lyckat ping bevisar en protokolls tur och retur vid en storlek till en destination, och det är ingen licens att anta att HTTPS, SMB eller något annat flöde är tillåtet.