Ping gjennom en VPN: hvorfor regler for ekko-svar bommer på returveien

Ping en vert gjennom en VPN, og forespørselen går ut med én ICMP-type og kommer tilbake med en annen, noe som er nok til å forvirre enhver regel skrevet i porttermer. Det finnes ingen destinasjonstjenesteport i en ekkoutveksling å kopiere inn i returregelen, og et filter som forventer symmetri vil droppe svaret mens forespørselen passerer uhindret. Rettelsen begynner med å lese pakken slik den faktisk er, og deretter avgjøre hvilken grense på veien som tar beslutningen. Vanligvis jobber to lag mens det tredje lydløst dropper svaret. Avsnittene nedenfor skiller dem i den rekkefølgen en pakke møter dem.

Pakken bytter type, ikke port

En ekkoforespørsel er ICMP-type 8, kode 0, og bærer en identifikator og et sekvensnummer. Svaret er type 0, kode 0, med samme identifikator og sekvens, og IP-endepunktene byttet om. RFC 792 definerer disse feltene, og identifikatoren er det som lar en avsender matche svar med sine egne forespørsler.

Det som mangler er like viktig: det finnes ingen TCP- eller UDP-header, så det finnes ingen port å tillate. En regel som navngir en port for et ekko-svar beskriver en pakke som aldri vil eksistere. Dette er den vanligste feilen i VPN-ping-saker. Regelen ser spesifikk ut, gjelder ingenting, og lar feilen bli nøyaktig der den var.

Tre kontekster avgjør pakken

Hvis pinget retter seg mot en vert på det fjerne LAN-et, må forespørselen videresendes av gatewayen. Hvis det retter seg mot en adresse som tilhører gatewayen selv, avsluttes det i den lokale inngangsveien i stedet. Hvis gatewayen selv starter pinget, begynner pakken i dens egen utgangsvei og krysser ikke videresendingsbeslutningen i det hele tatt.

Disse tre kontekstene har ulike regelkjeder og ulike tellere, og å behandle dem som én er grunnen til at «brannmuren tillater ICMP» likevel kan gi et mislykket ping. Den ytre tunnelen er en fjerde kontekst: å tillate VPN-lytteren tillater ikke automatisk den dekapsulerte indre forespørselen, og en indre tillatelse sier ingenting om hvorvidt den ytre tunnelen er oppe.

Stateful og stateless filtre håndterer svaret ulikt

En stateful brannmur som så forespørselen gå ut, kan knytte svaret til den strømmen og slippe det inn uten en andre regel. Et stateless filter har ingen slik hukommelse, så returretningen trenger sin egen uttrykkelige tillatelse, med kilde og destinasjon byttet om.

Sjekk hvilken modell produktet faktisk implementerer før du skriver noe. En regel for ekkoforespørsel dekker ikke nødvendigvis ekko-svar, og et produkt som følger ICMP-spørringer kan fortsatt bruke en annen policy på svar som ankommer på et annet grensesnitt.

Begrens det du tillater. Å tillate hvert ekko-svar fra hvor som helst er ikke det samme som å fullføre en stateful assosiasjon, og et typenummer autentiserer ikke avsenderen.

Oversettelse endrer også identifikatoren

Hvis kildeoversettelse er tilsiktet, passer ikke tuppelen i den fjerne enden den klienten sendte. En NAT kan oversette ICMP-spørringsidentifikatoren sammen med adressene, så å insistere på at samme nummer vises på begge sider gir en falsk avvik.

Korreler i stedet mappingen som oversetteren rapporterer. En oversetter som skriver om identifikatoren, bevarer ikke nummeret klienten din loggførte, så behandle mappingen som identiteten og ikke nummeret. Følg deretter én identifiserbar forespørsel gjennom veien: bekreft at den når destinasjonen med forventet kilde, bekreft at destinasjonen sendte et svar, følg ruten til det svaret tilbake, og bekreft at klienten mottok det i stedet for bare å se en gateway-teller stige.

Ikke brett ICMP-feil inn i ekkopolitikken

«Fragmentering nødvendig»-meldingen som path-MTU-oppdagelse bruker, er ikke et ekko-svar, og nyttelasten siterer pakken som utløste den. En tillatelse kun for ekko som lydløst forkaster disse feilene, gjør et størrelsesproblem om til en hengende forbindelse, som er det motsatte av nyttig.

Samme forsiktighet gjelder adressefamilier. ICMPv6 bruker andre meldingstyper og bærer vesentlige funksjoner som IPv4 ikke har, så å kopiere disse numrene inn i en IPv6-regel er rett og slett feil.

Når ekkoutvekslingen virker, test den virkelige applikasjonen separat. Et vellykket ping beviser én protokolls rundtur ved én størrelse til én destinasjon, og det er ikke en lisens til å anta at HTTPS, SMB eller enhver annen strøm er tillatt.