Ping kroz VPN: zašto pravila za eho odgovor promašuju povratni put

Pošaljete ping na host kroz VPN i zahtjev izlazi s jednim ICMP tipom, a vraća se s drugim, što je dovoljno da zbuni svako pravilo napisano u terminima portova. U eho razmjeni nema odredišnog servisnog porta koji bi se kopirao u povratno pravilo, a filter koji očekuje simetriju odbacit će odgovor dok zahtjev prolazi glatko. Popravka počinje čitanjem paketa onakvim kakav jest, a zatim odlukom koja granica na putu donosi odluku. Obično rade dva sloja dok treći tiho odbacuje odgovor. Odjeljci u nastavku razdvajaju ih redom kojim paket na njih nailazi.

Paket mijenja tip, ne port

Eho zahtjev je ICMP tip 8, kod 0, i nosi identifikator i redni broj. Odgovor je tip 0, kod 0, s istim identifikatorom i rednim brojem, a IP krajnje točke su zamijenjene. RFC 792 definira ta polja, a identifikator je ono što pošiljatelju omogućuje da odgovore upari sa svojim zahtjevima.

Odsutnost je jednako važna: nema TCP ili UDP zaglavlja, pa nema ni porta koji treba dopustiti. Pravilo koje imenuje port za eho odgovor opisuje paket koji nikada neće postojati. To je najčešća greška u VPN ping tiketima. Pravilo izgleda specifično, ne primjenjuje se ni na šta i ostavlja kvar točno tamo gdje je bio.

Tri konteksta odlučuju o paketu

Ako ping cilja host na udaljenom LAN-u, zahtjev mora proslijediti gateway. Ako cilja adresu koja pripada samom gatewayu, završava u lokalnoj ulaznoj putanji. Ako gateway sam inicira ping, paket počinje u njegovoj vlastitoj izlaznoj putanji i uopće ne prelazi odluku o prosljeđivanju.

Ta tri konteksta imaju različite lance pravila i različite brojače, i upravo njihovo tretiranje kao jednoga razlog je zašto „firewall dopušta ICMP“ ipak može dati neuspješan ping. Vanjski tunel je četvrti kontekst: dopuštanje VPN listenera ne dopušta automatski dekapsulirani unutrašnji zahtjev, a unutrašnje dopuštenje ne govori ništa o tome je li vanjski tunel podignut.

Stateful i stateless filteri različito obrađuju odgovor

Stateful firewall koji je vidio da zahtjev izlazi može odgovor povezati s tim tokom i propustiti ga bez drugog pravila. Stateless filter nema takvo pamćenje, pa povratni smjer treba vlastito izričito dopuštenje, sa zamijenjenim izvorom i odredištem.

Provjerite koji model proizvod zapravo primjenjuje prije nego što bilo šta napišete. Pravilo za eho zahtjev ne pokriva nužno eho odgovor, a proizvod koji prati ICMP upite može ipak primijeniti drugačiju politiku na odgovore koji stignu na drugo sučelje.

Ograničite šta dopuštate. Dopuštanje svakog eho odgovora s bilo kojeg mjesta nije isto što i dovršavanje stateful asocijacije, a broj tipa ne autentificira pošiljatelja.

Prijevod mijenja i identifikator

Ako je prevođenje izvora namjerno, torka na udaljenom kraju ne odgovara onoj koju je poslao klijent. NAT može prevesti identifikator ICMP upita zajedno s adresama, pa insistiranje da se isti broj pojavi na obje strane stvara lažnu neusklađenost.

Umjesto toga povežite mapiranje koje prevoditelj prijavljuje. Prevoditelj koji prepisuje identifikator neće sačuvati broj koji je vaš klijent zabilježio, pa mapiranje tretirajte kao identitet, a ne broj. Zatim pratite jedan prepoznatljiv zahtjev kroz put: potvrdite da stiže na odredište s očekivanim izvorom, potvrdite da je odredište poslalo odgovor, pratite put tog odgovora natrag, i potvrdite da ga je klijent primio, a ne da ste samo gledali kako brojač gatewaya raste.

Ne stapajte ICMP greške u eho politiku

Poruka „potrebna fragmentacija“ koju koristi otkrivanje MTU puta nije eho odgovor, a njen sadržaj citira paket koji ju je izazvao. Dopuštenje samo za eho koje tiho odbacuje te greške pretvara problem veličine u visjeću vezu, što je suprotno od korisnoga.

Isto vrijedi i za porodice adresa. ICMPv6 koristi druge tipove poruka i nosi bitne funkcije koje IPv4 nema, pa je kopiranje ovih brojeva u IPv6 pravilo jednostavno pogrešno.

Kada eho razmjena radi, testirajte stvarnu aplikaciju odvojeno. Uspješan ping dokazuje povratno putovanje jednog protokola, jedne veličine, do jednog odredišta, i nije licenca za pretpostavku da su HTTPS, SMB ili svaki drugi tok dopušteni.