OpenWrt politikas maršrutēšana: ķēde, kas notver vietējo DNS

LAN klienti risina caur tuneli, un paša maršrutētāja meklējumi klusi to nedara. Pakotņu atjauninājumi, laika sinhronizācija un dinamiskais DNS visi iziet pa parasto uplink, kamēr katrs pārsūtītais vaicājums izmanto VPN, un saskarnē nekas neliecina, ka pastāv divi atšķirīgi ceļi. Izskaidrojums nav politikas kļūda, bet jautājums, kurš āķis redz paketi. Divas plūsmas, viena atrisinātāja adrese, un tikai viena no tām šķērso maršrutētāju. To atdalīšana ir viss labojums.

Divas plūsmas, viena atrisinātāja adrese

Pirmā plūsma ir tā, ko cilvēki iedomājas. Klients jautā maršrutētāja atrisinātājam, atrisinātājs pārsūta augšup, un šī pārsūtītā pakete izejot šķērso maršrutētāju. Šī pakete ir redzama visam, kas novēro pārsūtīto satiksmi.

Otrā plūsma nekad nenāk no nekurienes. To rada maršrutētājs, tāpēc nav ienākošas paketes un nav saskaņojama pārsūtīšanas soļa.

Abas var mērķēt uz vienu un to pašu atrisinātāja adresi, un tieši tāpēc atšķirību ir viegli palaist garām. Tas pats galamērķis, cita izcelsme, cita ķēde. Kad ieraugi izcelsmi, pārējā diagnostika seko.

Pārsūtītās un lokāli radītās paketes nāk iekšā citādi

Pārsūtītā satiksme tiek novērtēta, kad tā nāk no citas saskarnes. Politikas maršrutēšanas pakotnes to atklāj kā prerouting ķēdi, un tur ievietots noteikums redz katru paketi, kas šķērso maršrutētāju. Tāpēc klientu meklējumi uzvedas tieši tā, kā apraksta politika, un tāpēc maršrutētājs to ignorē. Noteikums nav nepareizs, tas vienkārši ir pievienots āķim, kuru maršrutētājs nekad nesasniedz. Pārvieto to, un tā pati atbilstība sāk darboties.

Lokāli radīto satiksmi rada process maršrutētājā, un tā nonāk izejas ceļā. To maršrutē paša maršrutētāja lēmums, un tā sastop politiku tikai tad, ja politika aptver šo ķēdi. Nav ienākošas saskarnes, ko saskaņot, un nav pārsūtīšanas lēmuma, ko novērot.

Tā ir īpašība tam, kur paketes dzimst, nevis kādai konkrētai paketei. Vienai ķēdei rakstītam noteikumam vienkārši nav viedokļa par otru. Nekāda noteikumu regulēšana to nemaina.

Izvēlies izejas ķēdi, tad sašaurini atbilstību

Labojums ir pievienot to pašu nodomu arī izejas ķēdei, vai pārvietot noteikumu tur, kad tev rūp paša maršrutētāja vaicājumi. OpenWrt uzstādījumā, kas būvēts uz politikas maršrutēšanas pakotnes, tas nozīmē noteikuma ķēdes iestatījumā izvēlēties output, nevis prerouting. Paturi abus noteikumus, ja abām populācijām vajadzīgs pārklājums.

Tad sašaurini, kam noteikums atbilst. Galamērķa atrisinātāja adreses tai ostai, kuru atrisinātājs patiešām izmanto, ir daudz mazāks lēmums nekā sūtīt tunelī visu, ko maršrutētājs rada.

Paturi abus noteikumus skaidrus, nevis mēģini uzrakstīt vienu, kas aptver abas ķēdes. Atsevišķi noteikumi ir vieglāk lasāmi, un tie ļauj atslēgt maršrutētāja ceļu, netraucējot klientu satiksmei, kamēr atkļūdo. Tie arī padara skaitītājus jēgpilnus pa vienam.

Paturi paša tuneļa transportu ārpus noteikuma

Tuneļa ārējo savienojumu arī rada maršrutētājs. Noteikums, kas visu lokāli radīto satiksmi sūta tunelī, maršrutēs tuneli caur sevi, un tas nemaz neieslēgsies.

Pārvaldības piekļuve ir otrais upuris. Administratīvās sesijas, kas radušās maršrutētājā, vai atbildes uz tām, var tikt ievilktas tunelī ar pārāk plašu lokālu noteikumu un kļūt nesasniedzamas no LAN.

Izslēdz tuneļa galapunktu no atbilstības un turi noteikumu ierobežotu ar atrisinātāja adresēm. Tas ir pietiekami DNS prasībai un pietiekami mazs, lai par to domātu.

Pārbaudi abas populācijas, nevis vienu

Vēro, kā maršrutētājs veic savu vaicājumu, un pieraksti, kura saskarne to nesa. Atkārto meklējumu no LAN resursdatora un pieraksti, kādu ceļu tas izvēlējās. Politikas noteikumu skaitītāji padara abas atbildes redzamas bez minējumiem.

Uzlūko rezultātus kā divus atradumus. Klients, kas risina caur tuneli, neko nepasaka par maršrutētāju, un maršrutētājs, kas risina pareizi, neko nepasaka par klientu citā klausītājā. Ieraksti tos kā atsevišķas rindas izmaiņu žurnālā.

Pārbaudi arī ostu: noteikums, kas atbilst galamērķa ostai 53, palaiž garām atrisinātāju, kas sasniedzams pa DNS over TLS uz 853 vai HTTPS galapunktu. Saskaņo transportu, ko konfigurētais upstream patiešām izmanto, un noplūde aizveras pareizā iemesla dēļ.