OpenVPN-ek bultzatutako DNSa ezikusiarena egiten zaio: zein osagaik aplikatzen duen

Erregistroak erakusten du zerbitzariak bultzatutako aukera, tunela martxan dago, eta barne-izenek huts egiten dute oraindik. Ebazleari zuzenean egindako kontsultak erantzuten du, beraz zerbitzaria ondo dago, baina aplikazio bakoitzak tokiko bideratzaileari galdetzen dio oraindik. Bezerora iritsi zena eskaintza bat da, ez ebazlearen aldaketa, eta izen-ebazpenaren jabe den osagaia desberdina da Linux, Windows eta macOS sistemetan. Aukera bere jabetzatik bereizten duzunean, lau hutsek ia txosten guztiak estaltzen dituzte: hookik ez, elkar lehiatzen duten bi hook, DNS zatitua diseinatu bezala funtzionatzen duena, edo atzizki bat behar duen izen laburra, zerbitzari bat beharrean.

Bultzatutako aukera eskaintza bat da, ez instalazio bat

Zerbitzarian, bi direktibak asmoa deskribatzen dute, ez efektua:

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

Bezeroak ez du ebazle konfiguraturik jasotzen. Ingurune-aldagaiak jasotzen ditu, foreign_option_1 eta hurrengoak, bultzatutako lerro bakoitzeko bat, eta zerbait lokalak irakurri eta sistema eragilearen ebazlearen egoera berridatzi behar du. Linuxen ez du ezerk egiten lehenespenez, horregatik zerbitzari zuzen batek eta konektatutako bezero batek LAN bidez ebatz dezakete oraindik.

Bi muturren artean hiru etapa daude: pushak bidaiatu behar du, bezeroak agerian utzi behar du eta hook batek aplikatu behar du. Irakurri tarteko etapa bezeroaren erregistroan eta azkena ebazlearen egoeran, inoiz ez alderantziz, erregistro-lerro batek lehen biak soilik frogatzen baititu.

Egiazta ezazu pusha iritsi dela eta aurkitu jabea

Hasi abiarazleari izena ematen: komando openvpn soil bat, systemd instantzia bat, NetworkManager edo hornitzaile-bezero bat. Horrek erabakitzen du non bizi daitekeen hook bat. systemd-resolved duen ostalari batean, resolvectl status estekak zerrendatzen ditu benetan erabiltzen dituen DNS zerbitzariekin eta bilaketa-domeinuekin, eta tuneleko estekak ez du beti izena tun0.

Bultzatutako helbidea erregistroan agertzen bada baina esteka batean ez, integrazioa falta da. Estekan agertzen bada eta kontsultak beste nonbaitetik irteten badira, arazoa honakoa da: zein kontsultak hautatzen duten esteka hori. NetworkManager dns=dnsmasq fitxategian /etc/NetworkManager/NetworkManager.conf tokiko birbidaltzaile bat exekutatzen du, DNS zatitua nahita aplikatzen duena: VPN domeinuko izenak VPN ebazlera doaz, gainerako guztiak aurreko bidea mantentzen du. Jokabide horrek huts bat dirudi trafiko guztia mugitzea espero zenuenean; berrikusi konexio bakoitzeko ezarpenak honekin nmcli connection show "My VPN", non ipv4.dns eta ipv4.dns-search gailuak jakinarazten duenaren atzeko balioak gordetzen dituzten, hondatuta deitu aurretik. Kontsulta guztiek benetan VPN ebazlera iritsi behar badute, kendu dns=dnsmasq hemendik NetworkManager.conf eta berrabiarazi NetworkManager, ebazpena konexioaren ezarpenei itzultzen diena; bestela mantendu DNS zatitua eta zuzendu bultzatutako domeinu-zerrenda.

Linux: eman aukerak ebazleari

Banaketa-paketeek hook bat dakarte honetarako, eta bezeroari baimendu behar zaio exekutatzea. Ostalari batean systemd-resolved gabe ohiko antolaketa:

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

systemd-resolvedekin, resolv.conf script zaharrenak baliteke ezer garrantzitsurik ez aldatzea, stub ebazleak esteka bakoitzeko egoera gordetzen baitu. update-systemd-resolved laguntzaileak erabiltzen duen hook forma dokumentatzen du up-restart eta down-pre erabiltzen dituena, garrantzitsua denean interfaze batek konexio-saiakera bakarra baino gehiago irauten duenean. Edozer aukeratuta ere, osagai batek eduki behar du egoeraren jabetza. NetworkManagerren ondoan hook arrotz bat gehitzeak esteka berari bi idazle ematen dizkio, eta emaitza orduan ordenaren araberakoa da, ez zure konfigurazioaren araberakoa.

Badago kasua non NetworkManagerek bultzatutako aukera erabat ezikusi egin zuen harik eta zerbitzariaren helbidea konexioaren IPv4 ezarpenetan sartu zen arte, eta orduan ebazlearen egoerak erabilia zela erakutsi zuen. Merezi du scriptak berridatzi aurretik probatzeak, arazoa shell hook batetik tuneleko profilerako lekualdatzen baitu, tunela dagoeneko daraman profilerako.

Windowsek eta macOSek zati desberdinak aplikatzen dituzte

Windows bezeroak bai ezartzen ditu VPN egokigailuaren DNS zerbitzariak, baina Windowsek oraindik metrikaren arabera aukeratzen du interfazea eta oraindik atzizki bat behar du izen laburra hedatzeko. Egiazta ezazu egokigailuaren egoera, ez profila:

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

Helbidea falta bada, ezarri honekin Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, gero gehitu atzizkia egokigailuaren IPv4 propietateei, fileserver bihur dadin fileserver.corp.example. Balio bat SearchList makina osoan honen azpian Tcpip\Parameters gauza bera egiten du. Izen luzea ebazten denean eta soila ez, ebazlea jada zuzena da eta bilaketa-zerrenda da erruduna. Konponketak, hurrenez hurren: bultza ezazu DOMAIN bezeroak atzizkia ikas dezan, gehitu atzizki hori egokigailuaren edo konexioaren bilaketa-zerrendan, eta behin-behineko neurri gisa finkatu izena hosts n, edo LMHOSTS Windowsen; NetBIOS arakatzeak ez du bideratzailea gurutzatzen, beraz bulegoko LANean izen laburra aurkitzen duen difusioak ez dio inoiz tuneleko bezeroari heltzen.

block-outside-dns block-outside-dns Windows bezeroaren jokabidea da, ez profileko lerro eramangarria, eta Linux edo macOS profil batera kopiatzeak ez du han birsortzen. Izen publikoak funtzionatzen badute eta barnekoek huts egiten badute Windowsen, konparatu egokigailuen ordena Ezarpen aurreratuetan honekin ipconfig /all. macOSen zerbitzu bakoitzeko ebazlearen ordena sistemarena da, beraz erabili scutil --dns zein ebazleri galdetzen zaion zein domeinurentzat ikusteko, eta hartu jakinarazitako profil-konponketa bakar bat bezeroaren menpeko gisa, ez orokor gisa.

Era berean, ordenagailu bereko makina birtual batek ez du honetatik ezer heredatzen. Eman gonbidatuari barne-domeinurako bere ebazle-sarrera, edo utzi hiperbisorearen NATari bere kontsultak ostalariaren bidez birbidaltzen, eta hori zuzena da ostalariaren tunela martxan dagoen bitartean soilik.

Historia da hirugarren kausa. Aurreko profileko DNS zerbitzariek edo atzizki-ezarpenek konexio berriak gaindi ditzakete, beraz egokigailua zuzena dirudienean eta bilaketek huts egiten dutenean, konparatu egokigailu bizia Get-VpnConnection rekin eta ezabatu edo gainidatzi sarrera zaharkitua zerbitzaria ukitu aurretik.

Froga ezazu nora joan zen kontsulta

Bilaketa batean zehar egindako harrapaketa batek argitzen du eztabaida: tcpdump -ni eth0 port 53 kontsultak interfaze fisikoan erakusten ditu, hau da, tuneletik kanpora irteten direla eta ebazlea ez zela inoiz aldatu. dig @10.8.0.1 name.corp.example gero gainerako bi kasuak bereizten ditu. Kontsulta zuzenak erantzuten badu, ebazlea funtzionatzen du eta bezeroak ez du erabiltzen; denbora-muga gainditzen badu, ebazlea tuneletik harrapaezina da eta inolako tokiko aldaketak ez du lagunduko.

Oraindik erabiltzen den ebazlea hornitzaileak banatutakoa bada, tunelek trafikoa zifratzen du izenak hornitzaile horrentzat ikusgai mantentzen diren bitartean. Ihes-kontua da, ez funtzionala, eta harrapaketa berak erantzuten du: interfaze fisikoko kontsulta tuneletik kanpoko norbaitengana doa.

Erabilgarritasunak VPN ostalariaren suhesia barne hartzen du, eta horrek UDP eta TCP 53 baimendu behar ditu pooletik. Itxitako ate batek push hautsi baten itxura du zehazki, eta baita tunel sarearen barrualdetik soilik erantzuten duen ebazle batek ere. Errepikatu harrapaketa behin deskonektatu eta berriz konektatu ondoren, lehen konexioan agertu eta bigarrenean desagertzen diren ezarpenak hookaren bizi-zikloko hutsa baitira, ez falta den aukera bat.

Mantendu jabe bakarra eta egiaztatu hurrenez hurren

Tunelaren ustezko egoeran oinarrituta egokigailuaren DNSa berridazten duen script batek profilean dagoeneko dagoen konfigurazioa bikoizten du, eta isilean huts egiten du ustea okerra den lehen aldian. Hobe konexioaren beraren DNS ezarpenak edo hook dokumentatu bakarra, eta idatzi zein aukeratu duzun hurrengo pertsonak bigarren bat ez dezan gehitu.

Itxi begizta lau egiaztapenekin: bultzatutako helbidea tuneleko estekan dago, barne-izena erabat kualifikatutako izen gisa ebazten da, izen bera atzizkirik gabe ebazten da, eta biak egia dira berriz konektatu ondoren ere. Harrapaketa batek esaten dizu lauetatik zeinek huts egin duen. OpenVPN 2.6 eskuliburua zerrendatzen ditu dhcp-option eta script direktibak beren plataforma-oharrekin.