Kāpēc dnsmasq vaicājumi izkļūst ārpus VPN pēc DNS pārvirzīšanas

LAN klients pareizi sasniedz savu VPN, un tomēr tā DNS vaicājumi parādās nepareizajā augšupējā kanālā. Tā nav noplūde parastajā nozīmē; tas notiek tad, kad maršrutētājs pārstāj pārsūtīt vaicājumu un pats uz to atbild. Pārtveršana pārraksta galamērķi uz vietējo ligzdu, un tad atrisinātājs atver otru, nesaistītu sarunu ar savu paša avota adresi un savu paša maršrutēšanas lēmumu. Klienta plūsmai pievienotās atzīmes apraksta pirmo sarunu un pilnīgi neko par otro.

Atzīme neceļo kopā ar vaicājumu

Paketes atzīmes dzīvo uz conntrack ieraksta un uz lidojošās paketes. REDIRECT noteikums izbeidz šo lidojumu: lietderīgā krava tiek nodota vietējai ligzdai, un sākotnējais ieraksts jau ir izdarījis savu darbu. Tas, kas pēc tam iziet no maršrutētāja, ir jauna ligzda, ko izveidojis atrisinātāja process, un tās avots ir paša maršrutētāja adrese.

Tāpēc politikas maršruts, kas piesaistīts LAN klienta adresei, nekad nesakrīt ar augšupstraumes vaicājumu. Jaunā ligzda pieder dnsmasq, nevis klientam, un kodols maršrutu vērtē paša maršrutētāja plūsmai. Avota noteikumi, saskarnes noteikumi un atzīmju noteikumi visi redz citu kortežu. Pieņēmums, ka atzīme izplatās, ir visbiežākā kļūda šajā iestatījumā, un tas nav redzams klienta puses ierakstā.

Abas sarunas gan dala vārdu un laiku, un tieši tas liek tām izskatīties kā vienai plūsmai, kad ātri pārskatāt ierakstu.

Kur pārsūtīšana pārvēršas vietējā atrisināšanā

Sāciet ar noskaidrošanu, vai 53. ports tiek pārvirzīts, tulkots uz citu resursdatoru vai atstāts mierā, jo trīs gadījumi uzvedas atšķirīgi. Pārvirzīšana uz vietējo portu izbeidz pārsūtīšanu, savukārt tulkošana uz citu mašīnu uztur paketi kustībā un saglabā klienta kortežu jēgpilnu.

Apskatiet abus protokolus. Atrisinātājs, kas sasniedzams pa UDP un TCP, tiks pārbaudīts abos, un noteikumu kopums, kas aptver tikai UDP, atstāj klusu caurumu lielām atbildēm. Noteikumi, ko ģenerē paša maršrutētāja konfigurācijas pārvaldnieks, arī skaitās, un ģenerēta faila rediģēšana parasti zaudē nākamajai pārlādei.

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

Šie izvadi pēc kārtas atbild uz trim jautājumiem: kas pārraksta vaicājumu, kas to saņem un kurš process pārvalda klausošos ligzdu. Kad īpašnieks ir zināms, augšupstraumes politikai ir kur dzīvot.

Dodiet atrisinātājam savu izejas politiku

Domēnam raksturīga augšupstraume ir vistīrākais rīks, kad tuneļa vajadzība ir tikai dažiem vārdiem. dnsmasq pieņem ar domēnu ierobežotu server rindu, ar neobligātu saskarni vai avota adresi, kas vaicājumu izvada no izvēlētas ierīces. Tieši šī virzīšana liek otrajai sarunai sekot VPN.

server=/corp.example/10.30.0.53@tun_work
log-queries

Iepriekš minētais domēns, adrese un saskarne ir vietturi jūsu pašu vērtībām. Domēna izvēle un izejas kontrole paliek atsevišķi lēmumi: maršrutam jāpastāv, avota adresei jābūt atļautai no augšupstraumes atrisinātāja, un ugunsmūrim jāatļauj atbilde. Vien saskarnes virzīšana nav fail-closed, jo pazudis tunelis var atstāt atrisinātāju krītam uz citu ceļu. Turiet jebkuru publisku rezerves ceļu tālu no vārdtelpas, kurai jāpaliek privātai.

Ielieciet rindu pie tā konfigurācijas īpašnieka, ko atbalsta maršrutētājs, nevis ģenerētā failā, citādi nākamā pārlāde izdzēsīs labojumu.

Ko koplietota kešatmiņa nevar saglabāt

Viens pārsūtītājs ar vienu kešatmiņu apkalpo katru LAN klientu, un tas sagrauj atšķirību, kas dažiem tīkliem ir vajadzīga. Ja diviem klientiem viens un tas pats vārds jāatrisina atšķirīgi, koplietotajai ligzdai nav veida, kā atgūt, kurš klients jautāja. Politikai katram klientam jādzīvo atsevišķos atrisinātāja eksemplāros vai pārsūtīšanas funkcijā, kas saglabā identitāti.

Kešota atbilde arī nav pierādījums par jauno ceļu. Atbilde var nākt no atmiņas, kamēr augšupstraumes maršruts paliek salauzts.

53. porta noteikumi neko nesaka par lietotnēm, kas runā DNS pa HTTPS vai pa TLS. Šie vaicājumi nekad nesasniedz pārvirzīšanu, tāpēc politika, kas balstīta tikai uz 53. portu, apraksta datplūsmas apakškopu un tā būtu jādokumentē kā apakškopa.

Pārbaudiet otro sarunu, ne pirmo

Pārbaudiet ar vienu vārdu, ko kontrolējat, un vērojiet abas puses. Ieraksts klienta pusē pierāda, ka vaicājums atstāja LAN; tikai maršrutētāja puse pierāda, kur tas devās tālāk.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

Notīriet kešatmiņu pirms katra mēģinājuma, jo silta atbilde slēpj salauztu augšupstraumi. Atkārtojiet pa TCP, pēc tam atkārtojiet ar izslēgtu tuneli, lai redzētu, ko atrisinātājs dara, kad tā vēlamais ceļš ir pazudis. Tieši šī pēdējā uzvedība izšķir, vai dizains ir fail-closed vai vienkārši laimīgs.