DNS i OpenVPN në gateway: dnsmasq dhe shtrirja e murit të zjarrit

Ekzekutoni dnsmasq në adresën e tunelit, lejoni DNS vetëm nga grupi i klientëve, shtyni zgjidhësin, pastaj provoni pyetje të drejtpërdrejta dhe kërkimin e vetë aplikacionit.

Klientët në tunel arrijnë gateway-n, dhe gateway-i arrin zgjidhësin e brendshëm, ndaj DNS duhet të funksionojë. Nuk funksionon, sepse këto janë dy leje të ndryshme dhe një shërbim DNS që funksionon është gjëja e tretë. Dëgjuesi duhet të ekzistojë në një adresë që klientët e arrijnë, muri i zjarrit duhet të lejojë pyetjet drejt asaj adrese, dhe klientit duhet t'i thuhet ta përdorë atë. Hapja e tunelit në të dy drejtimet i zgjidh dy të parat rastësisht dhe e lë të tretën të papërfunduar.

Dëgjuesi është një shërbim lokal me dy drejtime

Nga brenda, një klient dërgon një pyetje në adresën e tunelit të gateway-it në portën 53. Nga jashtë, daemoni e përcjell atë pyetje te serveri i tij i konfiguruar i sipërm. Të dyja gjysmat duhet të funksionojnë, dhe ato dështojnë në mënyra të ndryshme.

Një skadim i raportuar nga klienti dhe një skadim i parë në gateway nuk janë e njëjta defekt.

Lidhni adresën e tunelit, jo çdo adresë

Një instancë e dedikuar dnsmasq për këtë punë ka nevojë për një adresë të qartë dëgjimi, një modalitet lidhjeje që toleron shfaqjen e tunelit pas nisjes, dhe një server të sipërm të qartë. Ky është versioni më i vogël që përdor:

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

bind-dynamic lidh adresat individuale dhe përballon kur tun0 shfaqet më vonë, gjë që ka rëndësi në një host ku shërbimi VPN riniset. Renditja e loopback mban mjetet lokale në punë pa shtuar një dëgjues publik. no-resolv pengon daemonin të trashëgojë serverë të sipërm nga konfigurimi i zgjidhësit të hostit, dhe no-hosts pengon këtë instancë të publikojë skedarin hosts të gateway-it. Asnjë nga këto opsione nuk i jep askujt leje të pyesë shërbimin.

Kontrolloni nëse ka një dëgjues ekzistues në portën 53 përpara se të nisni një daemon të dytë, dhe përdorni pronarin e konfigurimit të shpërndarjes në vend të një skedari të humbur në drejtorinë e gabuar.

Lejoni hyrjen e DNS, jo tranzitin e tunelit

Rregullat e murit të zjarrit që e bëjnë këtë të funksionojë janë rregulla të hyrjes lokale të kufizuara në ndërfaqen e tunelit, grupin e klientëve, adresën e gateway-it dhe portën 53. Dy rregulla, një për protokoll, mjaftojnë:

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 kalon përmes TCP si dhe UDP, ndaj një rregull vetëm për UDP i lë përgjigjet e mëdha të dështojnë në një mënyrë që duket e ndërprerë. Këto nuk janë ufw route leje, dhe nuk duhet të bëhen një leje e gjerë në tun0. Rendi ka po aq rëndësi sa përmbajtja: një rregull i mëparshëm që hedh poshtë të gjithë hyrjen nga tun0 vazhdon të fitojë, dhe shtimi i një leje nën një hedhje përfundimtare nuk krijon asgjë.

Nëse DNS i gateway-it tani është pjesë e projektimit, rishikoni atë politikë të mëparshme me qëllim dhe shënoni pse.

Gjysma e sipërme është një rrugë e veçantë

Pyetjet largohen nga gateway-i nga adresa e tij drejt zgjidhësit të sipërm, ndaj rruga e gateway-it dhe politika e daljes drejt atij zgjidhësi duhet ta lejojnë shkëmbimin. Ky është një rregull i ndryshëm nga ai që i lejon klientët të arrijnë dëgjuesin, dhe dështon me një simptomë tjetër.

Mos shtoni dalje tuneli të pakufizuar për t'i bërë përgjigjet të funksionojnë; përgjigjet e ndjekura nuk kanë nevojë për të.

Shtyni opsionin, pastaj kontrolloni dorëzimin

Serveri mund t'u shpallë zgjidhësin klientëve me një opsion të shtyrë. Ky është një opsion, jo një udhëzim që sistemi operativ duhet të bindet:

push "dhcp-option DNS 10.90.0.1"

Një klient Linux i linjës së komandës mund të ketë nevojë për integrimin e zgjidhësit të menaxherit të lidhjeve, dhe një pajisje e menaxhuar mund të ketë nevojë për një profil menaxhimi të përditësuar. Pas lidhjes konfirmoni zgjidhësin aktiv në klient, në vend që të supozoni se shtytja u zbatua. Kur dy mekanizma përpiqen të vendosin DNS njëkohësisht, ju merrni një garë që shfaqet si zgjidhje dridhëse.

Qëllimi është një pronar i vetëm i konfigurimit të zgjidhësit të klientit, dhe shtytja zakonisht është ai pronar vetëm kur platforma e klientit pajtohet.

Provoni atë që keni ndërtuar në të vërtetë

Pyetni një emër privat plotësisht të kualifikuar dhe një emër të jashtëm të lejuar drejtpërdrejt ndaj adresës së tunelit, përmes UDP dhe TCP. Pastaj përsëriteni përmes rrugës së zakonshme të kërkimit të aplikacionit.

Nëse pyetjet e drejtpërdrejta funksionojnë dhe aplikacioni ende dështon, defekti është në dorëzim dhe jo në server:

  • Klienti nuk e zbatoi kurrë opsionin e shtyrë.
  • Një zgjidhës tjetër u vendos më vonë dhe fitoi garën.
  • Aplikacioni përdor bibliotekën e vet të zgjidhësit ose një përgjigje të ruajtur.

Përfundoni duke konfirmuar se një burim jashtë rrugës së miratuar VPN nuk mund ta përdorë fare dëgjuesin. Një zgjidhje e suksesshme nuk e autorizon adresën që ktheu, ndaj mbani këto dy pyetje të ndara.

Artikuj të ngjashëm