Ping gjennom eit VPN: kvifor reglar for ekko-svar bommar på returvegen

Ping ein vert gjennom eit VPN, og førespurnaden går ut med éin ICMP-type og kjem tilbake med ein annan, noko som er nok til å forvirre kvar regel som er skriven i portomgrep. Det finst ingen destinasjonstenesteport i ein ekkoutveksling å kopiere inn i returregelen, og eit filter som ventar symmetri vil sleppe svaret medan førespurnaden passerer uhindra. Rettinga byrjar med å lese pakken slik han faktisk er, og deretter avgjere kva grense på vegen som tek avgjerda. Vanlegvis arbeider to lag medan det tredje lydlaust slepper svaret. Avsnitta nedanfor skil dei i den rekkjefølgja ein pakke møter dei.

Pakken byter type, ikkje port

Ein ekkoførespurnad er ICMP-type 8, kode 0, og ber ein identifikator og eit sekvensnummer. Svaret er type 0, kode 0, med same identifikator og sekvens, og IP-endepunkta bytte om. RFC 792 definerer desse felta, og identifikatoren er det som lèt ein avsendar matche svar med sine eigne førespurnader.

Det som manglar er like viktig: det finst ingen TCP- eller UDP-header, så det finst ingen port å tillate. Ein regel som nemner ein port for eit ekko-svar, skildrar ein pakke som aldri vil finnast. Dette er den vanlegaste feilen i VPN-ping-saker. Regelen ser spesifikk ut, gjeld ingenting, og lèt feilen bli nøyaktig der han var.

Tre kontekstar avgjer pakken

Viss pinget rettar seg mot ein vert på det fjerne LAN-et, må førespurnaden vidaresendast av gatewayen. Viss det rettar seg mot ei adresse som høyrer til gatewayen sjølv, endar det i den lokale inngangsvegen i staden. Viss gatewayen sjølv startar pinget, byrjar pakken i sin eigen utgangsveg og kryssar ikkje vidaresendingsavgjerda i det heile.

Desse tre kontekstane har ulike regelkjeder og ulike teljarar, og å handsame dei som éin er grunnen til at «brannmuren tillèt ICMP» likevel kan gje eit mislukka ping. Den ytre tunnelen er ein fjerde kontekst: å tillate VPN-lyttaren tillèt ikkje automatisk den dekapsulerte indre førespurnaden, og ei indre tillating seier ingenting om den ytre tunnelen er oppe.

Stateful og stateless filter handsamar svaret ulikt

Ein stateful brannmur som såg førespurnaden gå ut, kan knyte svaret til den straumen og sleppe det inn utan ein andre regel. Eit stateless filter har ikkje slik hukommelse, så returretninga treng si eiga uttrykkelege tillating, med kjelde og destinasjon bytte om.

Sjekk kva modell produktet faktisk implementerer før du skriv noko. Ein regel for ekkoførespurnad dekkjer ikkje nødvendigvis ekko-svar, og eit produkt som følgjer ICMP-spørjingar kan framleis bruke ein annan policy på svar som kjem inn på eit anna grensesnitt.

Avgrens det du tillèt. Å tillate kvart ekko-svar frå kvar som helst er ikkje det same som å fullføre ein stateful assosiasjon, og eit typenummer autentiserer ikkje avsendaren.

Omsetjing endrar òg identifikatoren

Viss kjeldeomsetjing er tilsikta, passar ikkje tuppelen i den fjerne enden den klienten sende. Ein NAT kan omsetje ICMP-spørjeidentifikatoren saman med adressene, så å insistere på at same nummer visest på begge sider gjev eit falskt avvik.

Korreler i staden mappinga som omsetjaren rapporterer. Ein omsetjar som skriv om identifikatoren, bevarar ikkje nummeret klienten din loggføyrde, så handsam mappinga som identiteten og ikkje nummeret. Følg deretter éin identifiserbar førespurnad gjennom vegen: stadfest at han når destinasjonen med forventa kjelde, stadfest at destinasjonen sende eit svar, følg ruta til det svaret tilbake, og stadfest at klienten tok imot det i staden for berre å sjå ein gateway-teljar stige.

Ikkje brett ICMP-feil inn i ekkopolitikken

«Fragmentering nødvendig»-meldinga som path-MTU-oppdaging brukar, er ikkje eit ekko-svar, og nyttelasta siterer pakken som utløyste ho. Ei tillating berre for ekko som lydlaust forkastar desse feila, gjer eit storleiksproblem om til ein hengande samband, som er det motsette av nyttig.

Same varsemd gjeld adressefamiliar. ICMPv6 brukar andre meldingstypar og ber vesentlege funksjonar som IPv4 ikkje har, så å kopiere desse numra inn i ein IPv6-regel er rett og slett feil.

Når ekkoutvekslinga verkar, test den verkelege applikasjonen separat. Eit vellukka ping provar éin protokolls rundtur ved éin storleik til éin destinasjon, og det er ikkje ein lisens til å anta at HTTPS, SMB eller kvar annan straum er tillaten.