Pritunl privatusis DNS neveikia? Pridėkite siaurą resolverio maršrutą

Privatūs vardai išsprendžiami visiems įmonės tinkle ir baigiasi pagal laiką visiems VPN tinkle. Resolveris atsako šliuzui, maršrutas iki jo egzistuoja, o užklausa vis tiek niekada negauna atsakymo. Trūksta ne kito viešo resolverio ar platesnio maršruto: trūksta šaltinio adreso, kuriam privatusis DNS serveris sutinka atsakyti.

Patvirtinkite, kad resolveris atmeta jūsų klientų baseiną

Pradėkite įrodydami, kad gedimas susijęs su šaltiniu, o ne su pasiekiamumu. Iš prisijungusio kliento tiesiogiai užklauskite privatųjį resolverį ir stebėkite, ar užklausa baigiasi pagal laiką, ar grįžta kaip atmetimas. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 baigiantis pagal laiką, kai ta pati užklausa iš šliuzo pavyksta, rodo prieigos politiką resolveryje. SERVFAIL atsakymas rodo visai kitą vietą, paprastai zoną arba viršutinį persiuntėją.

Prieš testuodami užsirašykite kliento adresą. ip -4 addr show tun0 kliente arba konsolėje rodoma nuoma pasako, kurį baseiną mato resolveris.

Tada patvirtinkite, kad kelias apskritai egzistuoja. Maršrutas, siunčiantis resolverio adresą į tunelį, yra išankstinė sąlyga, o ne sprendimas; jei paketai niekada neateina, šaltinio politika net neperžiūrima. Patikrinkite tai kliente su ip route get 10.40.0.53.

Pridėkite vieną prieglobos maršrutą, o ne verskite viską

Pritunl privataus DNS gairės aprašo siaurą sprendimą: /32 maršrutas su NAT resolverio adresui, o tas adresas pasirenkamas kaip klientų DNS serveris. Maršrutas keičia šaltinį, kurį mato resolveris, tik DNS srautui. Programų srautas išlaiko jūsų pasirinktą šaltinį išsaugantį dizainą.

Sukonfigūruokite jį per serverio palaikomą maršrutų savininką, prieš tai patikrinę esamus maršrutus dėl persidengimo. Aukščiau pateiktame pavyzdyje paskirties vieta yra 10.40.0.53/32 su įjungtu NAT, o klientų baseinas lieka 10.90.0.0/24. Neverskite viso privataus diapazono, kad sutvarkytumėte vieną paslaugą, nes kiekviena pasroviui esanti politika, kuri remiasi tikruoju kliento adresu, pradės matyti vietoj jo šliuzą. Patvirtinkite adresą, kurį resolveris iš tikrųjų gauna, stebėdami jo užklausų žurnalą bandomojoje paieškoje. Vien maršrutas į prieglobą nieko neįrodo apie vertimą ar leidimą.

Resolveris vis tiek turi leisti išverstą šaltinį per UDP ir TCP, o jo atsakymai turi galėti grįžti. Šaltinio pakeitimas negali sukurti trūkstamos zonos ar įrašo.

Nuspręskite, ar užklausą siunčia serveris, ar klientas

Pritunl taip pat dokumentuoja DNS tarpinio serverio sąranką, susietą su VPN Client DNS Mapping, kai serveris persiunčia viršutines užklausas klientų vardu. Pagal tą modelį viršutinis šaltinis priklauso paties serverio tinklo kontekstui, o išimtis kliento pusėje yra netinkamas sprendimas.

Prieš ką nors pridėdami nustatykite, kuris modelis aktyvus. Trys persidengiantys taisymai, tarpinis serveris, resolverio pakeitimas kliente ir rankinis NAT scenarijus paprastai reiškia, kad niekas nenustatė: kuris komponentas turėtų siųsti užklausą. Patikrinkite ir bootstrap: vien privatusis resolveris negali būti vienintelis būdas rasti galinį tašką iki tunelio atsiradimo, o nuolatinis resolverio pakeitimas neturėtų pergyventi ryšio.

Išbandykite privatų užklausimą, o ne viešą tinklalapį

Pritaikę pakeitimą ir vėl prisijungę, patikrinkite veiksmingą kliento resolverio konfigūraciją, tada išspręskite vardą, kuris, kaip žinote, egzistuoja tik privačioje zonoje. dig intranet.example.net be aiškaus serverio parodo, ką klientas iš tikrųjų naudoja. Tada nusiųskite užklausą adresu, kurį grąžino ta paieška, nes sprendimas ir prieiga prie paslaugos yra atskiri žingsniai. Naršyklė, kuri įkelia viešas svetaines per DNS-over-HTTPS, nieko neįrodo apie operacinės sistemos privatųjį resolverio kelią. Viešas antrinis resolveris taip pat nėra vidinės zonos autoritetas.

Užrašykite resolverio adresą, /32 maršrutą ir kliento DNS nuostatą kartu serverio pastabose. Pusė šios konfigūracijos, atkurta atskirai, atkartoja pirminį gedimą.

Galiausiai patvirtinkite, kad tunelis vis dar maršrutizuoja programos paskirties vietą po to, kai DNS pavyksta. Maršrutas, prieiga prie paslaugos ir autentifikavimas lieka nepriklausomi nuo vardų sprendimo, o veikianti paieška nieko nesako apie pralaidumą. Jei privatusis puslapis lėtas, bet išsprendžiamas, resolveris atliko savo darbą, o problema persikėlė į kelią.