DNS inayosukumwa na OpenVPN inapuuzwa: ni kipengele kipi kinachoitumia

Kumbukumbu inaonyesha chaguo lililosukumwa na seva, handaki liko hai, na majina ya ndani bado yanashindikana. Swali la moja kwa moja kwa kitatuzi hujibu, kwa hiyo seva ni sawa, lakini kila programu inaendelea kumuuliza kipanga njia cha ndani. Kilichofika kwa mteja ni toleo, si mabadiliko kwenye kitatuzi, na kipengele kinachomiliki utatuzi wa majina hutofautiana kwenye Linux, Windows na macOS. Ukitenganisha chaguo na mmiliki wake, hitilafu nne hufunika karibu kila ripoti: hakuna hook, hook mbili zinazoshindana, DNS iliyogawanywa inafanya kazi kama ilivyoundwa, au jina fupi linalohitaji kiambishi na si seva.

Chaguo lililosukumwa ni toleo, si usakinishaji

Kwenye seva, maagizo mawili hueleza nia, si athari:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

Mteja hapokei kitatuzi kilichosanidiwa. Anapokea vigeu vya mazingira, foreign_option_1 na vinavyofuata, kimoja kwa kila mstari uliosukumwa, na kitu cha ndani lazima kivisome na kuandika upya hali ya kitatuzi cha mfumo wa uendeshaji. Kwenye Linux hakuna kinachofanya hivyo kwa chaguo-msingi, ndiyo sababu seva sahihi na mteja aliyeunganishwa bado wanaweza kutatuwa majina kupitia LAN.

Kati ya ncha mbili kuna hatua tatu: usukumaji lazima ufike, mteja lazima auonyeshe, na hook lazima uitumie. Soma hatua ya kati kwenye kumbukumbu ya mteja na ya mwisho kwenye hali ya kitatuzi, kamwe si kinyume chake, kwa sababu mstari mmoja wa kumbukumbu unathibitisha mbili za kwanza tu.

Hakikisha usukumaji umefika na upate mmiliki

Anza kwa kutaja kianzishi: amri openvpn tupu, mfano wa systemd, NetworkManager au mteja wa msambazaji. Hiyo huamua hook inaweza kuishi wapi. Kwenye mwenyeji mwenye systemd-resolved, resolvectl status huorodhesha kila kiungo pamoja na seva za DNS na vikoa vya utafutaji ambavyo hutumia kweli, na kiungo cha handaki si lazima kiitwe tun0.

Kama anwani iliyosukumwa inaonekana kwenye kumbukumbu lakini si kwenye kiungo chochote, muunganisho haupo. Kama inaonekana kwenye kiungo na maswali bado yanatoka mahali pengine, tatizo ni maswali yapi huchagua kiungo hicho. NetworkManager dns=dnsmasq kwenye faili /etc/NetworkManager/NetworkManager.conf huendesha kipitishaji cha ndani kinachotumia DNS iliyogawanywa kwa makusudi: majina ndani ya kikoa cha VPN huenda kwa kitatuzi cha VPN, na mengine yote huhifadhi njia yake ya awali. Tabia hii huonekana kama hitilafu wakati ulitarajia trafiki yote ihame; angalia mipangilio kwa kila muunganisho kwa nmcli connection show "My VPN", ambapo ipv4.dns na ipv4.dns-search hushikilia thamani zilizo nyuma ya kile kifaa kinaripoti, kabla ya kukiita kimevunjika. Kama kila swali kwa kweli linapaswa kufika kwa kitatuzi cha VPN, ondoa dns=dnsmasq kutoka NetworkManager.conf na uanzishe NetworkManager upya, ambayo hurudisha utatuzi wa majina kwenye mipangilio ya muunganisho; vinginevyo baki na DNS iliyogawanywa na urekebishe orodha ya vikoa iliyosukumwa.

Linux: kabidhi chaguo kwa kitatuzi

Vifurushi vya usambazaji hutoa hook kwa hili, na mteja lazima aruhusiwe kuiendesha. Mpangilio wa kawaida kwenye mwenyeji asiye na systemd-resolved:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Pamoja na systemd-resolved skripti ya zamani ya resolv.conf huenda isibadilishe kitu chochote muhimu, kwa sababu kitatuzi cha stub hushikilia hali kwa kila kiungo. update-systemd-resolved msaidizi huandika aina ya hook inayotumia up-restart na down-pre, jambo ambalo ni muhimu wakati kiolesura kinaishi zaidi ya jaribio moja la muunganisho. Chochote utakachochagua, kipengele kimoja lazima kimiliki hali. Kuongeza hook isiyohusiana kando ya NetworkManager huwapa waandishi wawili kiungo kimoja, na matokeo hutegemea mpangilio na si usanidi wako.

Pia kuna kisa ambapo NetworkManager ilipuuza kabisa chaguo lililosukumwa hadi anwani ya seva ilipoingizwa kwenye mipangilio ya IPv4 ya muunganisho, na kisha hali ya kitatuzi ikaonyesha inatumika. Inafaa kujaribu kabla ya kuandika upya skripti, kwa sababu huhamisha tatizo kutoka hook ya shell kwenda wasifu wa muunganisho ambao tayari hubeba handaki.

Windows na macOS hutumia sehemu tofauti

Mteja wa Windows hupanga kweli seva za DNS za adaptara ya VPN, lakini Windows bado huchagua kiolesura kwa metrika na bado inahitaji kiambishi ili kupanua jina fupi. Hakikisha hali ya adaptara na si wasifu:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Kama anwani haipo, ipange kwa Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, kisha ongeza kiambishi kwenye sifa za IPv4 za adaptara ili fileserver kuwe fileserver.corp.example. Thamani SearchList ya mashine nzima chini ya Tcpip\Parameters hufanya vivyo hivyo. Ambapo jina refu hutatuliwa na tupu haitatuliwi, kitatuzi tayari ni sahihi na orodha ya utafutaji ndiyo yenye kosa. Marekebisho, kwa mpangilio: sukuma DOMAIN ili mteja ajifunze kiambishi, ongeza kiambishi hicho kwenye orodha ya utafutaji ya adaptara au muunganisho, na kama hatua ya muda bandika jina kwenye hosts, au LMHOSTS kwenye Windows; uvinjari wa NetBIOS hauvuki kipanga njia, kwa hiyo matangazo yanayopata jina fupi kwenye LAN ya ofisi hayafiki kamwe mteja wa handaki.

block-outside-dns block-outside-dns ni tabia ya mteja wa Windows, si mstari wa wasifu unaobebeka, na kuinakili kwenye wasifu wa Linux au macOS hakuiunda tena huko. Kama majina ya umma yanafanya kazi na ya ndani yanashindikana kwenye Windows, linganisha mpangilio wa adaptara chini ya Mipangilio ya kina na ipconfig /all. Kwenye macOS mpangilio wa vitatuzi kwa kila huduma ni wa mfumo, kwa hiyo tumia scutil --dns kuona kitatuzi kipi huulizwa kwa kikoa kipi, na chukulia kila marekebisho moja ya wasifu yaliyoripotiwa kama yanayotegemea mteja na si ya jumla.

Mashine pepe kwenye kompyuta mpito hiyo hiyo hairithi chochote kutoka hivi. Mpe mgeni kuingizwa kwake kwa kitatuzi kwa kikoa cha ndani, au acha NAT ya hypervisor ipitishe maswali yake kupitia mwenyeji, jambo ambalo ni sahihi tu wakati handaki la mwenyeji liko hai.

Historia ni sababu ya tatu. Seva za DNS au mipangilio ya kiambishi kutoka wasifu wa awali zinaweza kustahimili muunganisho upya, kwa hiyo wakati adaptara inaonekana sahihi na utafutaji bado unashindikana, linganisha adaptara hai na Get-VpnConnection na futa au andika juu ya kuingizwa kusikotumika kabla ya kugusa seva.

Thibitisha swali lilienda wapi

Nasa wakati wa utafutaji mmoja hutatua mzozo: tcpdump -ni eth0 port 53 huonyesha maswali kwenye kiolesura halisi, kumaanisha yanatoka nje ya handaki na kitatuzi hakikubadilishwa kamwe. dig @10.8.0.1 name.corp.example kisha hutenganisha visa viwili vilivyobaki. Kama swali la moja kwa moja hujibu, kitatuzi kinafanya kazi na mteja hakikitumii; kama muda unaisha, kitatuzi hakiwezi kufikiwa kupitia handaki na hakuna mabadiliko ya ndani yatakayosaidia.

Kama kitatuzi kinachotumika bado ni kile kilichotolewa na mtoa huduma, handaki husimba trafiki wakati majina yanabaki kuonekana kwa mtoa huduma huyo. Hili ni suala la uvujaji na si la utendaji, na nasa hiyo hiyo hulijibu: swali kwenye kiolesura halisi huenda kwa mtu nje ya handaki.

Ufikiaji unajumuisha firewall kwenye mwenyeji wa VPN, ambayo lazima iruhusu UDP na TCP 53 kutoka kwenye bwawa. Bandari iliyofungwa huonekana kama usukumaji uliovunjika, na vivyo hivyo kitatuzi kinachojibu tu kutoka ndani ya mtandao wa handaki. Rudia nasa baada ya kukatisha na kuunganisha upya mara moja, kwa sababu mipangilio inayoonekana kwenye muunganisho wa kwanza na kutoweka kwenye wa pili ni hitilafu ya mzunguko wa maisha ndani ya hook, si chaguo lililokosekana.

Shikilia mmiliki mmoja na uthibitishe kwa mpangilio

Skripti inayoandika upya DNS ya adaptara kwa kuzingatia hali ya handaki iliyodhaniwa hurudia usanidi ambao wasifu tayari hubeba, na hushindwa kimya mara ya kwanza dhana ikiwa si sahihi. Pendelea mipangilio ya DNS ya muunganisho wenyewe au hook moja iliyoandikwa, na uandike ipi uliyochagua ili mtu anayefuata asiongeze ya pili.

Funga mzunguko kwa ukaguzi nne: anwani iliyosukumwa ipo kwenye kiungo cha handaki, jina la ndani linatatuliwa kama jina lililostahiki kikamilifu, jina hilo hilo linatatuliwa bila kiambishi, na yote mawili bado ni kweli baada ya muunganisho mmoja upya. Nasa moja hukuambia ipi kati ya nne ilishindikana. Mwongozo wa OpenVPN 2.6 huorodhesha dhcp-option na maagizo ya skripti pamoja na maelezo yao ya jukwaa.