Ping skozi VPN: zakaj pravila za odgovor odmeva zgrešijo povratno pot

Pošljite ping na gostitelja skozi VPN in zahteva odide z enim tipom ICMP ter se vrne z drugim, kar je dovolj, da zmede vsako pravilo, napisano v izrazih vrat. V izmenjavi odmeva ni ciljnih storitvenih vrat, ki bi jih bilo mogoče kopirati v povratno pravilo, in filter, ki pričakuje simetrijo, bo odgovor zavrgel, medtem ko zahteva nemoteno prehaja. Popravek se začne s branjem paketa takega, kot v resnici je, nato pa z odločitvijo, katera meja na poti sprejema odločitev. Običajno delujeta dva sloja, medtem ko tretji tiho zavrže odgovor. Razdelki spodaj jih ločijo v vrstnem redu, v katerem jih paket sreča.

Paket spremeni tip, ne vrat

Zahteva odmeva je ICMP tipa 8, kode 0, in nosi identifikator ter zaporedno številko. Odgovor je tipa 0, kode 0, z istim identifikatorjem in zaporedjem, IP konca pa sta zamenjana. Ta polja določa RFC 792, in prav identifikator pošiljatelju omogoča, da odgovore uskladi z lastnimi zahtevami.

Česar ni, je enako pomembno: ni glave TCP ali UDP, zato ni vrat, ki bi jih bilo treba dovoliti. Pravilo, ki za odgovor odmeva navede vrata, opisuje paket, ki ne bo nikoli obstajal. To je najpogostejša napaka v zahtevkih za ping skozi VPN. Pravilo je videti natančno, ne velja za nič in pusti okvaro točno tam, kjer je bila.

O paketu odločajo trije konteksti

Če ping cilja gostitelja v oddaljenem LAN, mora zahtevo posredovati prehod. Če cilja naslov, ki pripada samemu prehodu, se namesto tega konča na lokalni vhodni poti. Če ping sproži sam prehod, se paket začne na njegovi lastni izhodni poti in odločitve o posredovanju sploh ne prečka.

Ti trije konteksti imajo različne verige pravil in različne števce, in prav njihovo obravnavanje kot enega je razlog, da lahko »požarni zid dovoli ICMP« še vedno da neuspešen ping. Zunanji tunel je četrti kontekst: dovoljenje za poslušalca VPN ne dovoli samodejno dekapsulirane notranje zahteve, notranje dovoljenje pa ne pove ničesar o tem, ali je zunanji tunel vzpostavljen.

Filtri s stanjem in brez stanja obravnavajo odgovor različno

Požarni zid s stanjem, ki je videl zahtevo odhajati, lahko odgovor poveže s tem tokom in ga spusti brez drugega pravila. Filter brez stanja nima takega spomina, zato povratna smer potrebuje lastno izrecno dovoljenje, z zamenjanim virom in ciljem.

Preden karkoli napišete, preverite, kateri model izdelek v resnici izvaja. Pravilo za zahtevo odmeva ne pokriva nujno odgovora odmeva, in izdelek, ki sledi poizvedbam ICMP, lahko še vedno uporabi drugačno politiko za odgovore, ki pridejo na drug vmesnik.

Omejite, kar dovolite. Dovoliti vsak odgovor odmeva od koderkoli ni isto kot dokončati povezavo s stanjem, in številka tipa ne overi pošiljatelja.

Prevajanje spremeni tudi identifikator

Če je prevajanje vira namerno, se tuple na oddaljenem koncu ne ujema s tistim, ki ga je poslal odjemalec. NAT lahko prevede identifikator poizvedbe ICMP skupaj z naslovi, zato vztrajanje, da se isto število pojavi na obeh straneh, ustvari lažno neskladje.

Namesto tega povežite preslikavo, ki jo poroča prevajalnik. Prevajalnik, ki prepiše identifikator, ne bo ohranil številke, ki jo je zabeležil vaš odjemalec, zato obravnavajte preslikavo kot identiteto in ne številko. Nato sledite eni prepoznavni zahtevi po poti: potrdite, da doseže cilj s pričakovanim virom, potrdite, da je cilj poslal odgovor, sledite poti tega odgovora nazaj, in potrdite, da ga je odjemalec prejel, namesto da bi le gledali, kako števec prehoda raste.

Napak ICMP ne vključujte v politiko odmeva

Sporočilo »potrebna je razdrobljenost«, ki ga uporablja odkrivanje MTU poti, ni odgovor odmeva, in njegov tovor navaja paket, ki ga je sprožil. Dovoljenje samo za odmev, ki te napake tiho zavrže, spremeni težavo z velikostjo v visečo povezavo, kar je nasprotje koristnega.

Enaka previdnost velja za družine naslovov. ICMPv6 uporablja druge tipe sporočil in nosi bistvene funkcije, ki jih IPv4 nima, zato je kopiranje teh številk v pravilo IPv6 preprosto napačno.

Ko izmenjava odmeva deluje, preizkusite resnično aplikacijo ločeno. Uspešen ping dokazuje pot tja in nazaj enega protokola pri eni velikosti do enega cilja, in ni licenca za domnevo, da so HTTPS, SMB ali kateri koli drug tok dovoljeni.