Ping per VPN: kodėl aido atsakymo taisyklės nepataiko į grįžimo kelią

Paleiskite ping į hostą per VPN: užklausa išeina su vienu ICMP tipu, o grįžta su kitu, ir to pakanka supainioti bet kurią taisyklę, parašytą portų terminais. Aido mainuose nėra paskirties paslaugos porto, kurį būtų galima nukopijuoti į grįžimo taisyklę, o filtras, kuris tikisi simetrijos, numes atsakymą, kol užklausa praeis be kliūčių. Taisymas prasideda nuo paketo skaitymo tokio, koks jis iš tikrųjų yra, o paskui nuo sprendimo, kuri kelio riba priima sprendimą. Paprastai dirba du sluoksniai, o trečiasis tyliai numeta atsakymą. Toliau pateikti skyriai juos atskiria tokia tvarka, kokia paketas juos sutinka.

Paketas keičia tipą, o ne portą

Aido užklausa yra ICMP 8 tipas, 0 kodas, ir neša identifikatorių bei sekos numerį. Atsakymas yra 0 tipas, 0 kodas, su tuo pačiu identifikatoriumi ir seka, o IP galai sukeisti. Šiuos laukus apibrėžia RFC 792, ir būtent identifikatorius leidžia siuntėjui susieti atsakymus su savo užklausomis.

To, ko nėra, taip pat svarbu: nėra TCP ar UDP antraštės, tad nėra ir porto, kurį reikėtų leisti. Taisyklė, kuri aido atsakymui nurodo portą, aprašo paketą, kurio niekada nebus. Tai dažniausia klaida VPN ping bilietuose. Taisyklė atrodo konkreti, netaikoma niekam ir palieka gedimą lygiai ten, kur jis buvo.

Paketą nusprendžia trys kontekstai

Jei ping taikosi į tolimo LAN hostą, užklausą turi persiųsti šliuzas. Jei jis taikosi į adresą, priklausantį pačiam šliuzui, jis baigiasi vietiniame įvesties kelyje. Jei ping pradeda pats šliuzas, paketas prasideda jo paties išvesties kelyje ir visiškai neperžengia persiuntimo sprendimo.

Šie trys kontekstai turi skirtingas taisyklių grandines ir skirtingus skaitiklius, ir būtent jų laikymas vienu yra priežastis, kodėl „ugniazė perleidžia ICMP“ vis tiek gali duoti nepavykusį ping. Išorinis tunelis yra ketvirtas kontekstas: VPN klausytojo leidimas automatiškai neleidžia dekapsuliuotos vidinės užklausos, o vidinis leidimas nieko nesako apie tai, ar išorinis tunelis veikia.

Būsenos ir bebūseniai filtrai atsakymą apdoroja skirtingai

Būsenos ugniazė, mačiusi užklausą išeinant, gali susieti atsakymą su tuo srautu ir įleisti jį be antros taisyklės. Bebūsenis filtras tokios atminties neturi, todėl grįžimo kryptis turi savo aiškų leidimą, su sukeistais šaltiniu ir paskirties vieta.

Prieš ką nors rašydami patikrinkite, kurį modelį produktas iš tikrųjų įgyvendina. Aido užklausos taisyklė nebūtinai apima aido atsakymą, o produktas, kuris seka ICMP užklausas, vis tiek gali taikyti kitokią politiką atsakymams, atvykstantiems kitu sąsaju.

Apribokite, ką leidžiate. Leisti kiekvieną aido atsakymą iš bet kur nėra tas pats, kas užbaigti būsenos susiejimą, o tipo numeris neautentifikuoja siuntėjo.

Vertimas keičia ir identifikatorių

Jei šaltinio vertimas yra tyčinis, tolimojo galo kortizė neatitinka tos, kurią siuntė klientas. NAT gali išversti ICMP užklausos identifikatorių kartu su adresais, todėl reikalavimas, kad abiejose pusėse būtų tas pats numeris, sukuria klaidingą neatitikimą.

Užuot tai, susiekite su atvaizdžiu, kurį praneša vertėjas. Vertėjas, kuris perrašo identifikatorių, neišsaugos numerio, kurį užrašė jūsų klientas, todėl tapatybe laikykite atvaizdį, o ne numerį. Tada sekite vieną atpažįstamą užklausą keliu: patvirtinkite, kad ji pasiekia paskirties vietą su laukiamu šaltiniu, patvirtinkite, kad paskirties vieta išsiuntė atsakymą, sekite to atsakymo maršrutą atgal, ir patvirtinkite, kad klientas jį gavo, o ne tik stebėjote kylantį šliuzo skaitiklį.

Nesuliekite ICMP klaidų į aido politiką

Pranešimas „reikia fragmentavimo“, kurį naudoja kelio MTU aptikimas, nėra aido atsakymas, o jo turinys cituoja paketą, kuris jį sukėlė. Leidimas tik aidui, kuris tyliai išmeta šias klaidas, paverčia dydžio problemą pakibusiu ryšiu, o tai yra priešingybė naudingumui.

Tas pats atsargumas galioja adresų šeimoms. ICMPv6 naudoja kitus pranešimų tipus ir neša esmines funkcijas, kurių IPv4 neturi, todėl šių numerių kopijavimas į IPv6 taisyklę yra tiesiog klaida.

Kai aido mainai veikia, atskirai išbandykite tikrąją programą. Sėkmingas ping įrodo vieno protokolo kelią pirmyn ir atgal vienu dydžiu į vieną paskirties vietą, ir tai nėra licencija manyti, kad HTTPS, SMB ar bet kuris kitas srautas yra leidžiamas.