Kodėl DNS atsakymas nepavyksta bevalstybėje VPN krašto užkardoje

Tunelis veikia, klientai pasiekia VPN mazgą, tačiau mazgas nieko negali išspręsti. Jo paties išeinančios užklausos švariai palieka sąsają, todėl gedimas yra grįžimo kelyje: aukštesniame krašte, kuris filtruoja įeinančią eismą neprisimindamas, ką mazgas ką tik nusiuntė. Tunelio prievado leidimas visiškai neapibūdina to mainų. Atsakymas į DNS užklausą yra atskiras srautas, o jei kraštas bevalstybis, niekas nesuteikė jam leidimo grįžti.

Du mainai nėra tie patys mainai

Užrašykite kortelius ir klaida taps akivaizdi. Užklausos paskirties prievadas tampa atsakymo šaltinio prievadu, o tai yra priešingybė tam, ką dauguma įsivaizduoja pridėdami įeinančią taisyklę 53 prievadui:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

Įeinanti taisyklė, reikalaujanti paskirties prievado 53, apibūdina eismą, adresuotą DNS klausytojui, veikiančiam mazge, o tai yra visiškai kita paslauga. Tie adresai yra dokumentacijos pavyzdžiai, o šaltinio prievadą klientas pasirenka kiekvienai užklausai, todėl tai nėra reikšmė, kurią galima nukopijuoti į taisyklę ir tikėtis, kad ji toliau veiks.

Bevalstybis kraštas prieš valstybinę mazgo užkardą

Bevalstybis krašto filtras vertina kiekvieną įeinantį paketą pagal savo taisyklių sąrašą be jokios jungčių lentelės už jo. Sėkmingai išėjusi išeinanti užklausa nesukuria jokio leidimo savo įeinančiam atsakymui, nes įrenginys neturi įrašo, kad užklausa kada nors įvyko. Valstybinė mazgo užkarda yra priešingybė: jos jungčių sekimas atpažįsta leistos mainų grįžtančią eismą ir praleidžia ją be taisyklės atsakymui. Abi ribos egzistuoja tipiniame kelyje, ir abi turi leisti numatytą paketą.

Palyginimas svarbus, nes du įrenginiai nepavyksta skirtingai. Valstybinė užkarda, kuri atmeta atsakymą, registruoja numetimą; bevalstybis kraštas atmeta jį tyliai, todėl mazgas tiesiog sulaukia laiko pabaigos.

Leidimą kurkite aplink protokolą, o ne prievado numerį

Susiaurinkite taisyklę iki tikrųjų sprendėjo adresų, paskirties mazgo ir produkto palaikomos priėmimo prievado politikos. Turėkite omenyje ir DNS TCP kelią, nes didelis atsakymas arba atsarginis kelias dėl sutrumpinimo perkelia mainus į TCP, o taisyklė, skirta tik UDP, jo neapims. Jei kraštas palaiko valstybinę patikrą apibrėžtam srautui, teikite jai pirmenybę prieš ranka rašytą atsakymo taisyklę, nes valstybinis kelias automatiškai seka kliento pasirinktus prievadus.

Tada patvirtinkite, kuris produktas kelyje iš tikrųjų filtruoja eismą. Dokumentuota IPv4 krašto apimtis nenustato IPv6 politikos, o tiekėjo vidinis eismas gali niekada nepereiti per tą patį filtrą.

Kodėl bet kurio šaltinio prievado 53 leidimas nėra pataisymas

Taisyklė, kuri priima viską, kas teigia turinti šaltinio prievadą 53, yra taisyklė, kuri priima tai, ką siuntėjas įrašo antraštės lauke. Prievado numeris neautentifikuoja siuntėjo ir neįrodo, kad naudinga apkrova yra galiojantis atsakymas, todėl taisyklė padidina mazgo ekspoziciją nesumažindama sprendimo patikimumo. Išsaugokite šaltinio apribojimus ir paties kliento atsakymo patikras, įskaitant šaltinio prievado atsitiktinumą, o ne išjunkite jas, kad supaprastintumėte prieigos sąrašą.

Jei sprendėjas yra jūsų kontroliuojama paslauga, apribojimas jo adresais yra pakankamas. Jei tai viešas sprendėjas, apribokite patvirtintais adresais ir užrašykite juos taisyklės komentare.

Tikrinkite ties tinkama riba, tinkama kryptimi

Užfiksuokite mazge ir krašte tą pačią užklausą ir lyginkite kortelius, o ne paketų skaičių. Užklausa, matoma abiejose pusėse be atsakymo mazgo pusėje, rodo į įeinantį filtrą; užklausa, matoma tik mazgo pusėje, rodo į maršrutizavimą arba patį sprendėją. Pakartokite su TCP užklausa, jei turite leidimą tik UDP, nes tai yra spraga, kurios pirmasis testas negali pamatyti.

Tai sutaisius, užbaigiama DNS mainų, kurių mazgui tikrai reikia. Tai nepaverčia mazgo viešu sprendėju, neleidžia persiųstų VPN srautų ir neįrodo, kad DNS buvo kokios nors nesusijusios tunelio problemos priežastis.