OpenVPN 53 prievade: trys pokalbiai, kuriuos žmonės painioja
Galinio taško pavadinimo sprendimas, šifruotas perdavimas ir DNS po tunelio yra trys pokalbiai. Nustatykite, kuris etapas žlugo, prieš keisdami prievadą ar sprendiklį.
Ataskaitos, teigiančios, kad VPN užblokuotas 53 prievade, sumaišo tris stebėjimus, kurie žlunga dėl skirtingų priežasčių. Galinio taško pavadinimo sprendimas vyksta dar prieš atsirandant tuneliui, šifruotas perdavimas yra atskiras pokalbis, o vėliau atliekamos DNS užklausos yra trečiasis. Kiekvienas turi savo gedimo parašą, ir tik vienas jų apskritai susijęs su DNS.
Prieš ką nors keisdami, surikiuokite paketus pagal paskirtį, nes sprendimas seka etapą.
Trys pokalbiai, vienas prievado numeris
Pirmasis pokalbis – tai galinio taško pavadinimo paieška: jūsų kompiuteris klausia sukonfigūruoto sprendiklio, kur yra vpn.example.com, ir tas atsakymas atkeliauja įprastu DNS dar prieš klientui išsiunčiant nors vieną tunelio paketą. Antrasis – pats OpenVPN perdavimas, kuris prisijungia prie paieškos gauto adreso tuo protokolu ir prievadu, kuriuos nurodo profilis. Trečiasis vyksta po to, kai tunelis pakeltas, kai programos prašo vardų ir stumiami sprendiklio nustatymai nusprendžia, kas atsakys.
Šie trys gali pavykti arba žlugti nepriklausomai. Klientas gali puikiai išspręsti savo galinį tašką ir vis tiek nepasiekti klausytojo, o taip pat gali užmegzti tunelį, kai kiekviena vidinė vardų paieška žlunga todėl, kad DNS nustatymai niekada neatėjo.
| Conversation | When it happens | What has to be true |
|---|---|---|
| Endpoint lookup | Before the client contacts a hostname | An underlying resolver path can answer for the endpoint name |
| OpenVPN transport | During tunnel establishment | The gateway listens on its configured transport, address and port, and nothing filters it |
| Application DNS | During or after the protected session | A resolver the client can reach, plus routing that carries its queries |
Skaitykite lentelę kaip kontrolinį sąrašą, o ne kaip aprašymą. Jei galinio taško pavadinimas neišsprendžiamas, niekas vėliau negali veikti, ir tunelis niekada neprasideda.
Prievado numeris neįvardija programos
53 prievadas pagal susitarimą neša DNS, o OpenVPN operatorius gali ten patalpinti ir klausytoją, todėl šis numeris yra prastas identifikatorius. OpenVPN sesija UDP 53 prievade vis dar yra OpenVPN sesija, o DNS užklausa serveriui 53 prievade nieko nesako apie tai, ar tunelis leidžiamas. Profilio eilutės proto ir remote apibrėžia išorinį galinį tašką; prievado numeris pats savaime nieko neapibrėžia.
Diagnozuojant tai pjauna į abi puses: bendra UDP patikra į 53 prievadą įrodo, kad prievadas atsako, o ne kad atsako VPN paslauga. Testuokite su tikru klientu ir tikru profiliu, nes tik tai išbando tą rankos paspaudimą, kurio tikisi paslauga.
Įrodykite klausytoją prieš kaltindami tinklą
Serveryje patikrinkite, kas susieta, naudodami ss -lunp | grep 53, ir palyginkite su profilio protokolu bei prievadu. Iš kliento tinklo paleiskite klientą su didesniu detalumu, kad žurnalas parodytų, kurį adresą ir perdavimą jis bandė. Jei serveris klausosi, o kliento paketai neateina, juos atmeta maršrutas arba politika, ir tai pokalbis su tinklo savininku, o ne priežastis keisti prievadą.
Kitas prievadas padeda tik tada, kai paslauga ten tikrai klausosi ir diegimas tai leidžia. Klausytojo perkėlimas norint išvengti valdomo tinklo filtravimo yra politikos sprendimas, o ne trikčių šalinimo žingsnis. Pasiteiraukite tinklo savininko, kas leidžiama, prieš keisdami paslaugą, nes politika pažeidžiantis apėjimas vis tiek vėliau uždaromas. Užrašykite tą atsakymą šalia profilio, kad kitas žmogus nekartotų prašymo.
Patikrinkite DNS po tunelio, atskirai
Kai tunelis pakeltas, apžiūrėkite sprendiklio būseną VPN sąsajoje ir užklauskite vieną vidinį ir vieną viešą vardą. Jei vidiniai vardai žlunga, kol tunelis neša srautą, stumti DNS nustatymai nebuvo pritaikyti, o tai kliento integracijos klausimas, o ne perdavimo. Jei vieši vardai žlunga, o vidiniai veikia, suskaidyto tunelio politika daro tai, kam buvo sukonfigūruota.
DNS pakeitimus palikite sprendiklio savininkui. Valdomos sprendiklio konfigūracijos perrašymas, kad praeitų vienas testas, gali sugadinti privačius vardus viskam kitam kompiuteryje. Jei tunelis stumia sprendiklį, o klientas jo nepaiso, taisykite kliento integraciją, o ne pridėkite statinį įrašą kur nors kitur. Statiniai įrašai slepia gedimą, kol kas nors nepakeičia tinklo. Užrašykite, kuris sprendiklis turėtų atsakyti kiekvienai vardų erdvei.