Kāpēc paša maršrutētāja DNS apiet VPN tuneli?

Klientu vaicājumi seko tunelim, bet paša maršrutētāja vaicājumi iziet caur WAN, un ugunsmūra noteikums, kas pārvalda vienu, neietekmē otru. Iemesls nav kļūda: pārsūtīts pieprasījums un pieprasījums, ko maršrutētājs ģenerē pats, ir divas atsevišķas plūsmas, un katrs tiek salīdzināts ar citu konfigurācijas daļu. Ierakstot tikai klienta pusi, iegūst pārliecinātu atbildi par ceļu, ko otrā puse nekad neizmanto. Labojums ir apzināti novirzīt maršrutētāja atrisinātāju un pēc tam pārbaudīt abus ceļus atsevišķi.

Kurai plūsmai paketes ieraksts īstenībā pieder

Viens vaicājums ietver divas apmaiņas. LAN klients nosūta vaicājumu maršrutētāja atrisinātājam, un tas ierodas kā pārsūtīta plūsma LAN saskarnē, tāpēc pārsūtītām paketēm rakstīts politikas maršruts vai NAT noteikums var tam atbilst. Pēc tam maršrutētājs atbild no kešatmiņas vai, ja ieraksta nav, atver savu vaicājumu augšupējam serverim.

Šim otrajam vaicājumam avots ir pats maršrutētājs, un galamērķis arī, un platforma izvēlas tā ceļu citā konfigurācijas blokā. Abām apmaiņām ir viens un tas pats nosaukums, un neviena nav otras kopija. Tāpēc LAN pusē uzņemts ieraksts pierāda, kur aizgāja klienta pakete, un neko nepasaka par izejošo paketi.

Praktiskā pārbaude ir vērot abas puses vienlaikus. Maršrutētājā uzskaitiet atrisinātāja ligzdu, vaicājiet tam lokāli un ierakstiet WAN saskarni:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

Ja ligzdu saraksts rāda klausītāju, kas piesaistīts loopback vai LAN adresei, maršrutētājs atbild lokāli, nevis pārsūta citam resursdatoram. Tad ieraksts rāda, vai izrietošais augšupējais vaicājums iziet pa tuneļa saskarni vai pa WAN, un tā ir atbilde, ko politikas maršruta noteikums nekad nebūtu devis.

Kāpēc politikas maršruts nekad neredz otro vaicājumu

Ugunsmūra noteikumi tiek rakstīti saskarnei, avotam, galamērķim un portam, un tie tiek novērtēti paketēm, kas iet caur ierīci. Vaicājums, ko ģenerē maršrutētājs, neiet caur neko, jo lokāls process to nodod tieši maršrutēšanas tabulai. Politikas maršrutēšana un NAT tāpēc attiecas tikai uz pārsūtīto ceļu, un tieši tāpēc noteikumu kopa var izskatīties pilnīga un tomēr atstāt maršrutētāja DNS ārpus tuneļa.

Šī atšķirība iztur katru programmaparatūras pārrakstīšanu, jo tā izriet no paketes ceļa, nevis no funkcijas. Viss, ko ierīce ģenerē sev, vai tie būtu atrisinātāja vaicājumi, laika sinhronizācija, atjauninājumu pārbaudes vai piekļuve pakešu spoguļiem, ir lokālas izcelsmes un nonāk tajā pašā aklajā punktā. Tāpēc arī tests no portatīvā datora neko nepierāda par maršrutētāju.

Kur pfSense atrisinātājs nosaka savu augšupējo ceļu

pfSense padara šo dalījumu redzamu. Klientu plūsmu var maršrutēt pēc politikas caur VPN vārteju, kamēr pašas ugunsmūra plūsma seko atrisinātāja izejas iestatījumam, nevis LAN noteikumiem. Tīmekļa saskarnē šis iestatījums atrodas zem Services > DNS Resolver > Outgoing Network Interfaces, un tā vērtība ir to saskarņu saraksts, ko atrisinātājs drīkst izmantot augšupējiem vaicājumiem.

Tuneļa saskarnes norādīšana tur, un tikai tās saskarnes, ir tas, kas liek paša maršrutētāja vaicājumiem sekot tunelim. Atstājot noklusējuma vērtību, atrisinātājs izvēlas izeju no maršrutēšanas tabulas, kas resursdatorā ar diviem WAN vai VPN bieži ir WAN.

Cita programmaparatūra to pašu lēmumu atklāj citā nosaukumā: ar avota adresi saistīts augšupējo serveru saraksts, tikai pārsūtīšanas režīms vai dokumentēta maršrutēšanas politika. Iestatījums, kas jāmeklē, vienmēr ir tas, kas izvēlas izeju vai avotu lokāli ģenerētiem vaicājumiem. Atrisinātāja konfigurācijas uzziņa dokumentē šo opciju pfSense un ir vērts izlasīt pirms izmaiņām.

Izvēlieties atteices uzvedību pirms iestatījuma

Kad tunelis krīt, divas uzvedības ir aizstāvamas: apturēt augšupējos vaicājumus, lai nekas nenoplūst, vai atgriezties pie apstiprināta atrisinātāja zināmā ceļā. Abas ir politika, un neviena nav tas, ko iegūst pēc noklusējuma. Izlemiet, kura tīklam vajadzīga, pirms aiztiecat saskarņu sarakstu.

Aizvēršanās atteices laikā ir vieglāk aizstāvama, taču tā tuneļa pārrāvumu pārvērš nosaukumu atrisināšanas pārrāvumā katrai ierīcei aiz maršrutētāja. Atkāpšanās uztur biroju lietojamu, bet par cenu, kas jāmaksā ar augšupēju apmaiņu ārpus tuneļa, un tai jābūt pieņemamai apzināti, nevis nejauši. Pierakstiet izvēli, jo nākamais cilvēks, kas ieraudzīs atrisinātāja adresi ārpus VPN, to lasīs kā noplūdi, ja vien piezīme nepasaka citādi. Tieši šī piezīme atšķir dokumentētu atkāpšanos no neizskaidrota atraduma nākamā ceturkšņa pārskatā.

Divi gadījumi sarežģī lēmumu. Privātiem nosaukumiem var būt vajadzīgs iekšējs atrisinātājs, ko tunelis sasniedz, un pārlūkprogramma vai lietotne ar savu šifrēto DNS var pilnībā apiet maršrutētāju, tāpēc konfigurētais atrisinātājs ne vienmēr ir tas, ko izmanto konkrēta lietotne.

Pārbaudiet abus ceļus un turiet rezultātus atsevišķi

DNS tests pārlūkprogrammā atbild uz šauru jautājumu: kādus atrisinātājus šī pārlūkprogramma izmantoja šā testa apstākļos. Tas neveic tīklā esošo ierīču uzskaiti un nevar redzēt vaicājumu, ko maršrutētājs ģenerēja sev. Uztveriet tā izvadi kā vienu datu punktu, nevis kā auditu.

No LAN klienta palūdziet maršrutētājam publisku nosaukumu un pēc tam privātu, uz kuru atbildēt vajadzētu tikai jūsu iekšējai zonai. Neveiksme tikai otrajā vaicājumā norāda uz nosaukumu pārsūtīšanu, nevis tuneli:

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

Pēc tam nometiet tuneli un atkārtojiet abus vaicājumus. Noraidītas atbildes nozīmē, ka atrisinātājs atteices laikā aizveras; veiksmīga atbilde norāda uz rezerves atrisinātāju un ceļu, ko tas izmantoja. Salīdziniet to ar piezīmi, ko uzrakstījāt, un ar ierakstu WAN saskarnē, kas uzņemts tajā pašā minūtē.

Turiet novērojumus atsevišķi ierakstā: klienta un maršrutētāja apmaiņu, maršrutētāja un augšupējā servera apmaiņu un konfigurāciju, kas noteica otro. Vēlāka maršrutēšanas izmaiņa izmantos šo otro apmaiņu bez brīdinājuma. Atbilde, kas nāk no citas vietas, nevis VPN galapunkta, pati par sevi nav noplūde; tā kļūst par noplūdi tikai tad, kad konfigurācija šo ceļu izvēlējās nejauši.