Ping cez VPN: prečo pravidlá pre odpoveď echa míňajú spiatočnú cestu

Pošlite ping na hostiteľa cez VPN a požiadavka odchádza s jedným typom ICMP a vracia sa s iným, čo stačí na zmätie každého pravidla napísaného v pojmoch portov. V echovej výmene nie je cieľový servisný port, ktorý by sa dal skopírovať do spätného pravidla, a filter, ktorý očakáva symetriu, odpoveď zahodí, kým požiadavka prechádza bez prekážok. Oprava začína čítaním paketu takého, aký skutočne je, a potom rozhodnutím, ktorá hranica na ceste rozhodnutie prijíma. Zvyčajne pracujú dve vrstvy, kým tretia odpoveď ticho zahadzuje. Nasledujúce časti ich oddeľujú v poradí, v akom ich paket stretáva.

Paket mení typ, nie port

Echová požiadavka je ICMP typu 8, kódu 0, a nesie identifikátor a poradové číslo. Odpoveď je typu 0, kódu 0, s rovnakým identifikátorom a poradím, a koncové body IP sú vymenené. Tieto polia definuje RFC 792, a práve identifikátor umožňuje odosielateľovi priradiť odpovede k vlastným požiadavkám.

To, čo chýba, je rovnako dôležité: neexistuje hlavička TCP ani UDP, takže neexistuje port, ktorý by sa mal povoliť. Pravidlo, ktoré pre odpoveď echa pomenúva port, opisuje paket, ktorý nikdy nevznikne. Toto je najčastejšia chyba v lístkoch ping cez VPN. Pravidlo vyzerá konkrétne, nevzťahuje sa na nič a necháva poruchu presne tam, kde bola.

O pakete rozhodujú tri kontexty

Ak ping cieli na hostiteľa vo vzdialenej LAN, požiadavku musí preposlať brána. Ak cieli na adresu, ktorá patrí samotnej bráne, končí v lokálnej vstupnej ceste. Ak ping iniciuje samotná brána, paket začína v jej vlastnej výstupnej ceste a rozhodnutie o preposielaní vôbec neprechádza.

Tieto tri kontexty majú rôzne reťazce pravidiel a rôzne počítadlá, a práve ich zlievanie do jedného je dôvod, prečo „firewall povoľuje ICMP“ môže stále dať neúspešný ping. Vonkajší tunel je štvrtý kontext: povolenie VPN poslucháča automaticky nepovoľuje dekapsulovanú vnútornú požiadavku a vnútorné povolenie nič nehovorí o tom, či je vonkajší tunel hore.

Stavové a bezstavové filtre spracúvajú odpoveď odlišne

Stavový firewall, ktorý videl požiadavku odchádzať, môže odpoveď priradiť k tomu toku a prepustiť ju bez druhého pravidla. Bezstavový filter takú pamäť nemá, preto spätý smer potrebuje vlastné výslovné povolenie, s vymeneným zdrojom a cieľom.

Predtým, než niečo napíšete, overte, ktorý model produkt skutočne implementuje. Pravidlo pre echovú požiadavku nemusí nutne pokrývať odpoveď echa a produkt, ktorý sleduje ICMP dopyty, môže na odpovede prichádzajúce na iné rozhranie stále uplatňovať inú politiku.

Obmedzte, čo povoľujete. Povoliť každú odpoveď echa odkiaľkoľvek nie je to isté ako dokončiť stavové priradenie, a číslo typu neoveruje odosielateľa.

Preklad mení aj identifikátor

Ak je preklad zdroja úmyselný, torka na vzdialenom konci nezodpovedá tej, ktorú poslal klient. NAT môže preložiť identifikátor ICMP dopytu spolu s adresami, takže trvanie na tom, aby sa rovnaké číslo objavilo na oboch stranách, vytvára falošnú nezhodu.

Namiesto toho korelujte mapovanie, ktoré hlási prekladač. Prekladač, ktorý prepisuje identifikátor, nezachová číslo, ktoré váš klient zaznamenal, preto považujte mapovanie za identitu a nie číslo. Potom sledujte jednu identifikovateľnú požiadavku po ceste: potvrďte, že dorazí do cieľa s očakávaným zdrojom, potvrďte, že cieľ vyslal odpoveď, sledujte trasu tej odpovede späť, a potvrďte, že ju klient dostal, namiesto toho, aby ste len sledovali rast počítadla brány.

Nezlučujte chyby ICMP do politiky echa

Správa „potrebná fragmentácia“, ktorú používa zisťovanie MTU cesty, nie je odpoveď echa a jej obsah cituje paket, ktorý ju vyvolal. Povolenie iba pre echo, ktoré tieto chyby ticho zahadzuje, mení problém s veľkosťou na visiace spojenie, čo je opakom užitočnosti.

Rovnaká opatrnosť platí pre rodiny adries. ICMPv6 používa iné typy správ a nesie podstatné funkcie, ktoré IPv4 nemá, takže kopírovať tieto čísla do pravidla IPv6 je jednoducho chyba.

Keď echová výmena funguje, otestujte skutočnú aplikáciu zvlášť. Úspešný ping dokazuje cestu tam a späť jedného protokolu pri jednej veľkosti do jedného cieľa, a nie je licenciou predpokladať, že HTTPS, SMB alebo akýkoľvek iný tok je povolený.