Kodėl paties maršrutizatoriaus DNS apeina VPN tunelį?

Klientų užklausos eina tuneliu, o paties maršrutizatoriaus užklausos išeina per WAN, ir ugniasienės taisyklė, kuri valdo vieną, neturi jokios įtakos kitai. Priežastis ne klaida: persiųsta užklausa ir užklausa, kurią maršrutizatorius sukuria pats, yra du atskiri srautai, ir kiekvienas lyginamas su kita konfigūracijos dalimi. Užfiksavus tik kliento pusę, gaunamas užtikrintas atsakymas apie kelią, kurio antroji pusė niekada nenaudoja. Taisymas – sąmoningai nukreipti maršrutizatoriaus sprendėją ir tada išbandyti abu kelius atskirai.

Kuriam srautui iš tikrųjų priklauso paketų fiksavimas

Viena užklausa apima du mainus. LAN klientas siunčia užklausą maršrutizatoriaus sprendėjui, ir ji atkeliauja kaip persiųstas srautas LAN sąsajoje, todėl persiųstiems paketams parašyta politikos taisyklė ar NAT taisyklė gali ją atitikti. Tada maršrutizatorius atsako iš podėlio arba, jei įrašo nėra, atidaro savo užklausą aukštyn esančiam serveriui.

Toji antroji užklausa turi patį maršrutizatorių kaip šaltinį ir kaip savo paskirties vietą, o platforma parenka jos kelią iš kito konfigūracijos bloko. Abiejų mainų pavadinimas tas pats, ir nė vienas nėra kito kopija. Todėl LAN pusėje užfiksuotas įrašas įrodo, kur nuėjo kliento paketas, ir nieko nesako apie išeinantį paketą.

Praktinė patikra – stebėti abi puses vienu metu. Maršrutizatoriuje išvardykite sprendėjo lizdą, paklauskite jo vietoje ir užfiksuokite WAN sąsają:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

Jei lizdų sąrašas rodo klausytoją, susietą su loopback arba LAN adresu, maršrutizatorius atsako vietoje, o ne persiunčia kitam kompiuteriui. Tada fiksavimas parodo, ar susidariusi užklausa aukštyn išeina per tunelio sąsają, ar per WAN, ir tai yra atsakymas, kurio politikos taisyklė niekada nebūtų davusi.

Kodėl politikos taisyklė niekada nemato antrosios užklausos

Ugniasienės taisyklės rašomos sąsajai, šaltiniui, paskirties vietai ir prievadui, ir jos vertinamos paketams, einantiems per įrenginį. Užklausa, kurią sukuria maršrutizatorius, nieko nepereina, nes vietinis procesas perduoda ją tiesiai maršrutų lentelei. Politikos maršrutizavimas ir NAT todėl galioja tik persiųstam keliui, ir būtent todėl taisyklių rinkinys gali atrodyti išsamus ir vis tiek palikti maršrutizatoriaus DNS už tunelio ribų.

Šis skirtumas išlieka po kiekvieno programinės aparatinės įrangos perrašymo, nes jis kyla iš paketo kelio, o ne iš funkcijos. Viskas, ką įrenginys sukuria sau, ar tai sprendėjo užklausos, laiko sinchronizavimas, atnaujinimų tikrinimas ar prieiga prie paketų veidrodžių, yra vietinės kilmės ir patenka į tą pačią akląją zoną. Todėl ir testas iš nešiojamojo kompiuterio nieko neįrodo apie maršrutizatorių.

Kur pfSense sprendėjas nustato savo kelią aukštyn

pfSense padaro šį atskyrimą matomą. Klientų srautas gali būti nukreiptas politikos maršrutu per VPN tinklų sietuvą, o paties ugniasienės srautas seka sprendėjo išėjimo nustatymą, o ne LAN taisykles. Žiniatinklio sąsajoje tas nustatymas yra po Services > DNS Resolver > Outgoing Network Interfaces, ir jo reikšmė yra sąsajų, kurias sprendėjas gali naudoti užklausoms aukštyn, sąrašas.

Tunelio sąsajos įvardijimas ten, ir tik tos sąsajos, yra tai, kas leidžia paties maršrutizatoriaus užklausoms sekti tuneliu. Palikus numatytąją reikšmę, sprendėjas pasirenka išėjimą iš maršrutų lentelės, o dviejų WAN arba VPN kompiuteryje tai dažnai būna WAN.

Kita programinė aparatinė įranga tą patį sprendimą atskleidžia kitu pavadinimu: prie šaltinio adreso susietas serverių aukštyn sąrašas, tik persiuntimo režimas arba dokumentuota maršrutų politika. Nustatymas, kurio reikia ieškoti, visada yra tas, kuris parenka išėjimą arba šaltinį vietoje sukurtoms užklausoms. Sprendėjo konfigūracijos nuoroda dokumentuoja tą parinktį pfSense ir verta perskaityti prieš pakeitimą.

Pasirinkite gedimo elgseną prieš nustatymą

Kai tunelis krenta, dvi elgsenos yra apginamos: sustabdyti užklausas aukštyn, kad niekas neprasiskverbtų, arba grįžti prie patvirtinto sprendėjo žinomu keliu. Abi yra politika, ir nė viena nėra tai, ką gaunate pagal numatytuosius nustatymus. Nuspręskite, kurios reikia tinklui, prieš liesdami sąsajų sąrašą.

Užsidarymas gedimo metu yra lengviau apginamas, bet jis tunelio nutrūkimą paverčia vardų sprendimo nutrūkimu kiekvienam įrenginiui už maršrutizatoriaus. Atsarginis kelias išlaiko biurą tinkamą naudoti, bet už mainų aukštyn už tunelio ribų, kurie turi būti priimtini sąmoningai, o ne atsitiktinai. Užsirašykite pasirinkimą, nes kitas žmogus, pamatęs sprendėjo adresą už VPN ribų, perskaitys tai kaip nuotėkį, nebent pastaba sako kitaip. Būtent ta pastaba atskiria dokumentuotą atsarginį kelią nuo nepaaiškinto radinio kito ketvirčio apžvalgoje.

Du atvejai apsunkina sprendimą. Privatiems vardams gali prireikti vidinio sprendėjo, kurį tunelis pasiekia, o naršyklė ar programėlė su savo šifruotu DNS gali visiškai apeiti maršrutizatorių, todėl sukonfigūruotas sprendėjas ne visada yra tas, kurį naudoja konkreti programėlė.

Išbandykite abu kelius ir laikykite rezultatus atskirai

Naršyklės DNS testas atsako į siaurą klausimą: kokius sprendėjus naudojo ta naršyklė tomis testo sąlygomis. Jis nesudaro tinkle esančių įrenginių inventorizacijos ir negali pamatyti užklausos, kurią maršrutizatorius sukūrė sau. Traktuokite jo išvestį kaip vieną duomenų tašką, o ne kaip auditą.

Iš LAN kliento paprašykite maršrutizatoriaus viešo vardo, o paskui privataus, į kurį turėtų atsakyti tik jūsų vidinė zona. Nepavykimas tik antrojoje užklausoje rodo vardų persiuntimą, o ne tunelį:

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

Tada numeskite tunelį ir pakartokite abi užklausas. Atmesti atsakymai reiškia, kad sprendėjas užsidaro gedimo metu; sėkmingas atsakymas rodo atsarginį sprendėją ir kelią, kuriuo jis naudojosi. Palyginkite tai su pastaba, kurią parašėte, ir su fiksavimu WAN sąsajoje, atliktu tą pačią minutę.

Stebėjimus laikykite atskirai įraše: kliento ir maršrutizatoriaus mainus, maršrutizatoriaus ir serverio aukštyn mainus ir konfigūraciją, kuri nulėmė antruosius. Vėlesnis maršrutizavimo pakeitimas tuos antruosius mainus išbandys be įspėjimo. Atsakymas, atėjęs ne iš VPN galinio taško, pats savaime nėra nuotėkis; jis tampa nuotėkiu tik tada, kai konfigūracija tą kelią pasirinko atsitiktinai.