OpenVPN DNS atebidean: dnsmasq eta suebakiaren irismena

Exekutatu dnsmasq tunelaren helbidean, baimendu DNS bezeroen multzotik bakarrik, bultzatu ebazgailua, eta gero probatu kontsulta zuzenak eta aplikazioaren beraren bilaketa.

Tunelaren bezeroek atebidea harrapa dezakete, eta atebideak barneko ebazgailua harrapa dezake, beraz DNSek funtzionatu beharko luke. Ez du funtzionatzen, bi baimen desberdin direlako eta funtzionatzen duen DNS zerbitzua hirugarren gauza delako. Entzuleak bezeroek harrapa dezaketen helbide batean egon behar du, suebakiak helbide horretako kontsultak baimendu behar ditu, eta bezeroari erabili behar duela esan behar zaio. Tunela bi noranzkoetan irekitzeak lehen biak ustekabean konpontzen ditu eta hirugarrena amaitu gabe uzten du.

Entzulea bi noranzkodun tokiko zerbitzua da

Barrurako noranzkoan, bezero batek kontsulta bat bidaltzen dio atebidearen tunel helbideari 53 portuan. Kanporako noranzkoan, deabruak kontsulta hori bere konfiguratutako goi-korronteko zerbitzarira birbidaltzen du. Bi erdiek funtzionatu behar dute, eta modu desberdinetan huts egiten dute.

Bezeroak jakinarazitako denbora-muga eta atebidean ikusitako denbora-muga ez dira akats bera.

Lotu tunelaren helbidea, ez helbide guztiak

Lan honetarako dnsmasq instantzia dedikatu batek entzuteko helbide esplizitua, abiatu ondoren tunela agertzea onartzen duen lotze-modua eta goi-korronte argi bat behar ditu. Hau da erabiltzen dudan bertsiorik txikiena:

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

bind-dynamic helbide indibidualak lotzen ditu eta ongi konpontzen da tun0 geroago agertzen denean, VPN zerbitzua berrabiarazten den ostalari batean garrantzitsua dena. loopback zerrendatzeak tokiko tresnak martxan mantentzen ditu entzule publiko bat gehitu gabe. no-resolv deabruak ostalariaren ebazgailu konfiguraziotik goi-korronteak hereda ez ditzan eragozten du, eta no-hosts instantzia honek atebidearen hosts fitxategia argitaratu ez dezan eragozten du. Aukera horietako batek ere ez dio inori zerbitzua kontsultatzeko baimenik ematen.

Egiaztatu ea badagoen 53 portuan lehendik dagoen entzulerik bigarren deabru bat abiatu aurretik, eta erabili banaketaren konfigurazio-jabea direktorio okerreko fitxategi galdu baten ordez.

Baimendu DNS sarrera, ez tunelaren trafikoa

Hau funtzionarazten duten suebaki arauak tokiko sarrera arauak dira, tunelaren interfazera, bezeroen multzora, atebidearen helbidera eta 53 portura mugatuta. Bi arau, protokolo bakoitzeko bat, nahikoa dira:

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

DNSek TCP zein UDP bidez funtzionatzen du, beraz UDP soilik adierazten duen arau batek erantzun handiak huts egiten uzten ditu tartekakoa dirudien moduan. Hauek ez dira ufw route baimenak, eta ez dira bihurtu behar tun0 helbidean baimen zabal. Ordenak edukiak adina balio du: tun0 helbidetik sarrera guztia botatzen duen aurreko arauak irabazten jarraitzen du, eta amaierako bazterketa baten azpian baimena gehitzeak ez du ezer sortzen.

Atebidearen DNS orain diseinuaren parte bada, berrikusi aurretikako politika hori berariaz eta idatzi zergatik.

Goi-korrontearen erdia bide bereizia da

Kontsultei atebidetik irteten dute bere helbidetik goi-korronteko ebazgailurantz, beraz atebidearen ibilbideak eta ebazgailu horrekiko irteera-politikak trukea baimendu behar dute. Hau entzulera bezeroak iristea uzten duen arauaren desberdina da, eta sintoma desberdinarekin huts egiten du.

Ez gehitu tunelaren irteera mugagabea erantzunek funtziona dezaten; jarraitutako erantzunek ez dute behar.

Bultzatu aukera, eta gero egiaztatu entregatzea

Zerbitzariak ebazgailua jakinarazi diezaieke bezeroei bultzatutako aukera batekin. Hau aukera bat da, ez sistema eragileak bete behar duen agindua:

push "dhcp-option DNS 10.90.0.1"

Linux komando-lerroko bezero batek bere konexio-kudeatzailearen ebazgailu integrazioa behar lezake, eta kudeatutako gailu batek kudeatze-profila eguneratu behar lezake. Konektatu ondoren, egiaztatu bezeroan aktibo dagoen ebazgailua, bultzada aplikatu zela suposatu beharrean. Bi mekanismok aldi berean DNS ezartzen saiatzen direnean, lasterketa bat lortzen duzu ebazpen dardarti gisa agertzen dena.

Helburua bezeroaren ebazgailu konfigurazioaren jabe bakarra da, eta bultzada jabe hori izan ohi da bezeroaren plataformak ados dagoenean soilik.

Probatu benetan eraiki duzuna

Kontsultatu izen pribatu guztiz kualifikatu bat eta kanpoko izen baimendu bat zuzenean tunelaren helbidearen aurka, UDP eta TCP bidez. Gero errepikatu aplikazioaren ohiko bilaketa-bidearen bidez.

Kontsulta zuzenek funtzionatzen badute eta aplikazioak oraindik huts egiten badu, akatsa entregatzean dago, ez zerbitzarian:

  • Bezeroak ez zuen inoiz bultzatutako aukera aplikatu.
  • Beste ebazgailu bat ezarri zen geroago eta lasterketa irabazi zuen.
  • Aplikazioak bere ebazgailu liburutegia edo cachean gordetako erantzun bat erabiltzen du.

Amaitu baieztatuz onartutako VPN bidearen kanpoko iturri batek ezin duela entzulea erabili. Ebazpen arrakastatsuak ez du itzuli duen helbidea baimentzen, beraz mantendu bi galdera horiek bereizita.

Erlazionatutako artikuluak