Kwa nini DNS huacha kufanya kazi baada ya OpenVPN kuunganisha kwenye Windows
Resolver bado hujibu ping wakati mlango 53 hauendi popote. Angalia kama block-outside-dns inachuja, kisha toa resolver ambayo tunnel inaweza kufikia.
Ping kwa resolver ya ofisi bado hupata jibu baada ya "OpenVPN" kuunganisha, na bado kila utafutaji wa jina hushindwa. Anwani inafikika wakati mlango haufikiki, mchanganyiko unaoeleweka unapojua kwamba Windows inaweza kuchuja DNS kwa adapta. Ikiwa block-outside-dns iko kwenye profile, kichujio hicho ndicho mtuhumiwa wa kwanza, na jedwali la njia ndilo mahali pasipofaa kuangalia. Vipimo viwili vilivyo hapa chini hutenganisha tabaka kwa sekunde.
Anwani inayofikika, mlango uliokufa
Ping iliyofanikiwa huthibitisha kwamba mwenyeji anaendesha na kwamba njia ipo. Haisemi chochote kuhusu ruhusa ya kufikia mlango 53, kwa sababu kichujio kinachozungumzwa hufanya kazi katika tabaka lingine na hutegemea adapta. Ndiyo sababu mashine hiyo hiyo inaweza kujibu ICMP na kukataa kila swali linalotumwa kwa anwani hiyo hiyo. Endesha vipimo vyote viwili katika kikao kimoja kabla ya kubadilisha usanidi wowote.
ping <resolver-ip>
nslookup <name> <resolver-ip>
Jozi hiyo ndiyo utambuzi. Trafiki ya kawaida kuelekea subneti huendelea wakati utatuzi wa majina unakufa, na watu huhitimisha kwamba seva imeharibika au kwamba DNS haikutumwa kamwe. Maelezo yote mawili ni ghali kuyafuatilia, na ushahidi huelekeza mahali pembamba zaidi. Thibitisha jozi kabla ya kugusa mpangilio wowote.
Chaguo ni kanuni ya jukwaa la uchujaji
Marejeo ya OpenVPN hufafanua block-outside-dns kama kizuizi cha Windows Filtering Platform kinachozuia programu kufikia DNS kwenye adapta zilizo nje ya tunnel. Kinashughulikia TCP na UDP mlango 53. Kwa kuwa kichujio kinaishi ndani ya WFP na si kwenye orodha ya kawaida ya kanuni za firewall, kuongeza kanuni ya kuruhusu mahali pengine hakubadilishi matokeo kwa lazima. Ndiyo sababu ushauri wa kawaida wa kuruhusu DNS unaendelea kushindwa.
Mpangilio unaweza kuja kutoka profile iliyoingizwa au kutoka seva, na faili uliyoihariri mwisho "si ushahidi wa kile mteja alichopakia". Soma usanidi halisi na kumbukumbu ya muunganisho pamoja. Chaguo pia ni mahususi kwa Windows, na kulichukulia kama la kubebeka hutoa ushauri usiotumika.
Tafuta sehemu ya mteja inayomiliki kizuizi badala ya kuongeza kanuni zaidi. Mmiliki ndiye kitu kinachoweza kukiondoa kwa kweli.
Kichujio si resolver
Kuzuia trafiki nje ya tunnel hakuweki resolver inayofanya kazi ndani yake. Chaguo huondoa njia na kuacha usanidi wa DNS wa tunnel kwa aliyeweka profile. Profile ambayo haikutuma resolver kamwe sasa haina hata moja.
Pitia ukaguzi watatu kwa mpangilio. Kwanza, ni resolver gani programu inayoshindwa hutumia kwa kweli. Pili, kama mteja alitumia mipangilio ya DNS ya VPN. Tatu, ni kiolesura gani kinachobeba trafiki kwa resolver huyo.
- Resolver inayotumika: linganisha
Resolve-DnsName -Server <resolver-ip> <name>na seva za DNS ambazoipconfig /allhuorodhesha. - DNS ya VPN imetumika: angalia maingizo ya DNS ya adapta ya tunnel kwenye matokeo hayo ya
ipconfig /all. - Kiolesura kilichotumika:
Find-NetRoute -RemoteIPAddress <resolver-ip>hutaja kiolesura cha kutoka kwa lengo hilo.
Resolver ya LAN inakuwa isiyofikika kwa muundo chini ya sera hii, hata wakati trafiki nyingine ya LAN inafanya kazi. Hicho ndicho chaguo likifanya kazi yake. Ikiwa muundo unahitaji DNS kupitia VPN, rekebisha usajili wa resolver na njia ya tunnel; ikiwa split DNS yenye misamaha ya ndani inahitajika, mmiliki wa usanidi lazima aeleze misamaha hiyo kwa namna inayotumika.
Chaguo halishughulikii nini
Mlango 53 si utatuzi wote wa majina. DNS over HTTPS na DNS over TLS hutumia usafiri tofauti, na programu zingine huendesha mantiki yao ya resolver bila kujali mipangilio ya mfumo. Kwa hiyo kivinjari kinaweza kutatuwa majina wakati mstari wa amri hauwezi.
Chukulia tofauti hiyo kama utambuzi na si kama kinzani. Linganisha vyote viwili kabla ya kuamua kwamba resolver ya mfumo imeharibika.
Weka hitimisho finyu unapoandika. Chaguo hiki huzuia usafiri mmoja kwenye jukwaa moja, na sehemu iliyobaki ya njia ya utatuzi ni swali la muundo tofauti lenye mmiliki wake.
Angalia hali kabla na baada ya kukatwa
Endesha utafutaji huo wakati wa muunganisho na tena baada ya mteja mmiliki kukatika. Wa kwanza unapaswa kushindwa kwa resolver ya nje wakati tunnel iko juu, na wa pili unapaswa kufanikiwa mara kichujio kiondolewe. Ikiwa bado unashindwa baada ya kukatwa, kichujio hakikusafishwa.
ipconfig /displaydns
nslookup <name> <resolver-ip>
Kuwasha upya huduma ya mteja au mashine kwa kawaida husafisha kichujio cha zamani. Hilo huthibitisha utambuzi bila kuthibitisha marekebisho ya kudumu. Andika ulichokiona, kwa sababu kichujio kinachostahimili kukatwa kitafanya hivyo tena, na kumbukumbu hiyo ndiyo inayohalalisha ripoti ya hitilafu.
Ni baada ya ukaguzi huo tu inafaa kubadilisha resolver au kujenga upya sera ya firewall. Yote mawili ni mabadiliko makubwa kuliko ushahidi unavyotegemeza.