OpenVPN-DNS sur la pordego: dnsmasq kaj fajroŝirma amplekso

Rulu dnsmasq sur la tunela adreso, permesu DNS nur el la klienta aro, puŝu la solvilon, poste testu rektajn demandojn kaj la propran serĉon de la aplikaĵo.

Klientoj en la tunelo povas atingi la pordegon, kaj la pordego povas atingi la internan solvilon, do DNS devus funkcii. Ĝi ne funkcias, ĉar tiuj estas du malsamaj permesoj, kaj funkcianta DNS-servo estas tria afero. La aŭskultanto devas ekzisti sur adreso, kiun la klientoj povas atingi, la fajroŝirmilo devas permesi demandojn al tiu adreso, kaj oni devas diri al la kliento, ke ĝi uzu ĝin. Malfermi la tunelon en ambaŭ direktoj hazarde solvas la unuajn du kaj lasas la trian nefarita.

La aŭskultanto estas loka servo kun du direktoj

Enen, kliento sendas demandon al la tunela adreso de la pordego sur haveno 53. Eksteren, la demono plusendas tiun demandon al sia agordita supra servilo. Ambaŭ duonoj devas funkcii, kaj ili malsukcesas laŭ diversaj manieroj.

Tempo-limigo raportita de la kliento kaj tempo-limigo vidata sur la pordego ne estas la sama fuŝo.

Ligu la tunelan adreson, ne ĉiun adreson

Dediĉita dnsmasq-kazo por ĉi tiu tasko bezonas eksplicitan aŭskultan adreson, ligreĝimon, kiu toleras la aperon de la tunelo post starto, kaj unu klaran supran servilon. Ĉi tio estas la plej malgranda versio, kiun mi uzas:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic ligas la unuopajn adresojn kaj eltenas, kiam tun0 aperas pli poste, kio gravas sur gastiganto, kie la VPN-servo restartiĝas. Listigi loopback tenas lokajn ilojn funkciantaj sen aldoni publikan aŭskultanton. no-resolv malhelpas la demonon heredi suprajn servilojn el la solvila agordo de la gastiganto, kaj no-hosts malhelpas ĉi tiun kazon eldoni la hosts-dosieron de la pordego. Neniu el tiuj opcioj donas al iu permeson demandi la servon.

Kontrolu ĉu ekzistas jam ekzistanta aŭskultanto sur haveno 53 antaŭ ol startigi duan demonon, kaj uzu la agordan posedanton de la distribuaĵo anstataŭ vaganta dosiero en la malĝusta dosierujo.

Permesu DNS-enigon, ne tunelan trairon

La fajroŝirmilaj reguloj, kiuj ebligas ĉi tion, estas lokaj enigreguloj limigitaj al la tunela interfaco, la klienta aro, la pordega adreso kaj haveno 53. Du reguloj, unu por protokolo, sufiĉas:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS funkcias super TCP same kiel super UDP, do regulo nur por UDP lasas grandajn respondojn malsukcesi tiel, ke ĝi aspektas intermita. Ĉi tiuj ne estas ufw route permesoj, kaj ili ne devas fariĝi larĝa permeso sur tun0. La ordo gravas same kiel la enhavo: pli frua regulo, kiu forĵetas ĉiun enigon de tun0 ankoraŭ venkas, kaj aldoni permeson sub fina forĵeto kreas nenion.

Se pordega DNS nun estas parto de la dezajno, reviziu tiun pli fruan politikon intence kaj notu kial.

La supra duono estas aparta vojo

Demandoj forlasas la pordegon de ĝia propra adreso al la supra solvilo, do la itinero de la pordego kaj la eliga politiko al tiu solvilo devas permesi la interŝanĝon. Tio estas alia regulo ol tiu, kiu lasas klientojn atingi la aŭskultanton, kaj ĝi malsukcesas kun alia simptomo.

Ne aldonu senliman tunelan eligon por igi respondojn funkcii; spuritaj respondoj ne bezonas ĝin.

Puŝu la opcion, poste kontrolu la transdonon

La servilo povas anonci la solvilon al klientoj per puŝita opcio. Tio estas opcio, ne instrukcio, kiun la operaciumo devas obei:

push "dhcp-option DNS 10.90.0.1"

Linux-komandlinia kliento eble bezonas la solvilan integriĝon de sia konekta administrilo, kaj administrata aparato eble bezonas ĝisdatigitan administran profilon. Post konektiĝo, konfirmu la aktivan solvilon sur la kliento anstataŭ supozi, ke la puŝo aplikiĝis. Kiam du mekanismoj samtempe provas agordi DNS, vi ricevas vetkuron, kiu prezentiĝas kiel flagranta solvado.

Unu posedanto por la solvila agordo de la kliento estas la celo, kaj la puŝo kutime estas tiu posedanto nur kiam la klienta platformo konsentas.

Testu tion, kion vi efektive konstruis

Demandu unu privatan plene kvalifikitan nomon kaj unu permesitan eksteran nomon rekte kontraŭ la tunela adreso, super UDP kaj TCP. Poste ripetu tra la ordinara serĉvojo de la aplikaĵo.

Se la rektaj demandoj funkcias kaj la aplikaĵo ankoraŭ malsukcesas, la fuŝo estas en la transdono, ne sur la servilo:

  • La kliento neniam aplikis la puŝitan opcion.
  • Alia solvilo estis agordita pli poste kaj venkis la vetkuron.
  • La aplikaĵo uzas sian propran solvilan bibliotekon aŭ kaŝmemorigitan respondon.

Finu konfirmante, ke fonto ekster la aprobita VPN-vojo tute ne povas uzi la aŭskultanton. Sukcesa solvado ne rajtigas la adreson, kiun ĝi redonis, do tenu tiujn du demandojn aparte.

Rilataj artikoloj