OpenWrt politikos maršrutizavimas: grandinė, pagaunanti vietinį DNS

LAN klientai sprendžia per tunelį, o paties maršrutizatoriaus paieškos tyliai to nedaro. Paketų atnaujinimai, laiko sinchronizavimas ir dinaminis DNS išeina įprastu uplinku, o kiekviena persiųsta užklausa paima VPN, ir sąsajoje niekas nereiškia, kad egzistuoja du skirtingi keliai. Paaiškinimas nėra politikos klaida, o klausimas, kuris kabliukas mato paketą. Du srautai, vienas sprendėjo adresas, ir tik vienas jų kerta maršrutizatorių. Jų atskyrimas yra visas pataisymas.

Du srautai, vienas sprendėjo adresas

Pirmasis srautas yra tas, kurį žmonės įsivaizduoja. Klientas klausia maršrutizatoriaus sprendėjo, sprendėjas persiunčia aukštyn, ir tas persiųstas paketas išeidamas praeina per maršrutizatorių. Tas paketas matomas viskam, kas stebi persiųstą srautą.

Antrasis srautas niekada neateina iš niekur. Jį sukuria maršrutizatorius, todėl nėra nei įeinančio paketo, nei atitinkamo persiuntimo žingsnio.

Abu gali taikytis į tą patį sprendėjo adresą, ir būtent todėl skirtumą lengva praleisti. Ta pati paskirties vieta, kita kilmė, kita grandinė. Kai pamatai kilmę, likusi diagnostika seka.

Persiųsti ir vietoje sukurti paketai patenka skirtingai

Persiųstas srautas vertinamas, kai jis ateina iš kitos sąsajos. Politikos maršrutizavimo paketai tai parodo kaip prerouting grandinę, o ten įdėta taisyklė mato kiekvieną maršrutizatorių kertantį paketą. Todėl klientų paieškos elgiasi tiksliai taip, kaip aprašo politika, ir todėl maršrutizatorius jos nepaiso. Taisyklė nėra neteisinga, ji tiesiog prijungta prie kabliuko, kurio maršrutizatorius niekada nepasiekia. Perkelk ją, ir ta pati atitiktis pradeda veikti.

Vietoje sukurtą srautą sukuria maršrutizatoriaus procesas, ir jis patenka į išvesties kelią. Jį maršrutizuoja paties maršrutizatoriaus sprendimas, ir jis susiduria su politika tik jei politika apima tą grandinę. Nėra įeinančios sąsajos, kurios ieškoti, ir nėra persiuntimo sprendimo, kurį stebėti.

Tai savybė to, kur paketai gimsta, o ne kokio nors konkretaus paketo. Vienai grandinei parašyta taisyklė tiesiog neturi nuomonės apie kitą. Joks taisyklių derinimas to nepakeis.

Pasirink išvesties grandinę, tada susiaurink atitiktį

Pataisymas yra prijungti tą patį ketinimą ir prie išvesties grandinės, arba perkelti taisyklę ten, kai tau rūpi paties maršrutizatoriaus užklausos. OpenWrt sąrankoje, pastatytoje ant politikos maršrutizavimo paketo, tai reiškia taisyklės grandinės nustatyme pasirinkti output, o ne prerouting. Palik abi taisykles, jei abiem populiacijoms reikia aprėpties.

Tada susiaurink, ką taisyklė atitinka. Paskirties sprendėjo adresai tame porte, kurį sprendėjas iš tikrųjų naudoja, yra daug mažesnis sprendimas nei siųsti į tunelį viską, ką maršrutizatorius sukuria.

Laikyk dvi taisykles aiškias, o ne bandyk parašyti vieną, apimančią abi grandines. Atskiros taisyklės yra lengviau skaitomos, ir jos leidžia išjungti maršrutizatoriaus kelią netrukdant klientų srautui, kai derini. Jos taip pat daro skaitiklius prasmingus po vieną.

Laikyk paties tunelio transportą už taisyklės ribų

Išorinį tunelio ryšį taip pat sukuria maršrutizatorius. Taisyklė, siunčianti visą vietoje sukurtą srautą į tunelį, maršrutizuos tunelį per save, ir jis visai neis aukštyn.

Valdymo prieiga yra antroji auka. Administracinės sesijos, kilusios iš maršrutizatoriaus, arba atsakymai į jas, gali būti įtrauktos į tunelį pernelyg plačios vietinės taisyklės ir tapti nepasiekiamos iš LAN.

Išskirk tunelio galinį tašką iš atitikties ir laikyk taisyklę apribotą sprendėjo adresais. To pakanka DNS reikalavimui ir pakankamai maža, kad apie tai būtų galima mąstyti.

Testuok abi populiacijas, ne vieną

Stebėk, kaip maršrutizatorius daro savo užklausą, ir pažymėk, kuri sąsaja ją nešė. Pakartok paiešką iš LAN mazgo ir pažymėk, kokiu keliu ji ėjo. Politikos taisyklių skaitikliai padaro abu atsakymus matomus be spėlionių.

Traktuok rezultatus kaip du radinius. Klientas, sprendžiantis per tunelį, nieko nesako apie maršrutizatorių, o teisingai sprendžiantis maršrutizatorius nieko nesako apie klientą kitame klausytojuje. Užrašyk juos kaip atskiras eilutes pakeitimų įraše.

Patikrink ir portą: taisyklė, atitinkanti paskirties portą 53, praleidžia sprendėją, pasiekiamą per DNS over TLS 853 prievade arba HTTPS galinį tašką. Suderink transportą, kurį sukonfigūruotas upstream iš tikrųjų naudoja, ir nuotėkis užsidaro dėl teisingos priežasties.