Usmerjanje pravil v OpenWrt: veriga, ki ujame lokalni DNS

Odjemalci v LAN razrešujejo skozi tunel, lastna iskanja usmerjevalnika pa tega tiho ne počnejo. Posodobitve paketov, sinhronizacija časa in dinamični DNS vsi odidejo po običajnem uplinku, medtem ko vsaka posredovana poizvedba vzame VPN, in nič v vmesniku ne nakazuje, da obstajata dve različni poti. Razlaga ni napaka v pravilu, ampak vprašanje katera kljuka vidi paket. Dva toka, en naslov razreševalnika, in le eden od njiju prečka usmerjevalnik. Njuna ločitev je vsa popravek.

Dva toka, en naslov razreševalnika

Prvi tok je tisti, ki si ga ljudje predstavljajo. Odjemalec vpraša razreševalnik usmerjevalnika, razreševalnik posreduje navzgor in ta posredovani paket gre skozi usmerjevalnik na poti ven. Ta paket je viden vsem, ki opazujejo posredovani promet.

Drugi tok nikoli ne prispe od nikoder. Ustvari ga usmerjevalnik, zato ni vhodnega paketa in ni koraka posredovanja za ujemanje.

Oba lahko ciljata isti naslov razreševalnika, in prav zato je razliko lahko spregledati. Ista destinacija, drug izvor, druga veriga. Ko vidite izvor, sledi preostanek diagnoze.

Posredovani in lokalno ustvarjeni paketi vstopajo drugače

Posredovani promet se ocenjuje, ko prispe z drugega vmesnika. Paketi usmerjanja pravil to izpostavijo kot verigo prerouting, pravilo, nameščeno tam, pa vidi vsak paket, ki prečka usmerjevalnik. Zato se poizvedbe odjemalcev obnašajo natanko tako, kot opisuje pravilo, in zato jih usmerjevalnik ignorira. Pravilo ni napačno, le pritrjeno je na kljuko, ki se ji usmerjevalnik nikoli ne približa. Premaknite ga in isto ujemanje začne delovati.

Lokalno ustvarjeni promet ustvari proces na usmerjevalniku in vstopi v izhodno pot. Usmerja ga lastna odločitev usmerjevalnika in pravilo sreča le, če pravilo pokriva to verigo. Ni vhodnega vmesnika za ujemanje niti odločitve o posredovanju za opazovanje.

To je lastnost mesta, kjer se paketi rodijo, ne pa nekega določenega paketa. Pravilo, napisano za eno verigo, preprosto nima mnenja o drugi. Nobeno uglaševanje pravil tega ne spremeni.

Izberite izhodno verigo in nato zožite ujemanje

Popravek je, da isto namero pritrdite tudi na izhodno verigo, ali da pravilo premaknete tja, ko vas zanimajo lastne poizvedbe usmerjevalnika. V namestitvi OpenWrt, zgrajeni na paketu usmerjanja pravil, to pomeni izbrati output namesto prerouting v nastavitvi verige pravila. Obdržite obe pravili, če obe populaciji potrebujeta pokritost.

Nato zožite, čemu se pravilo ujema. Ciljni naslovi razreševalnika na vratih, ki jih razreševalnik dejansko uporablja, so veliko manjša odločitev kot pošiljanje v tunel vsega, kar usmerjevalnik ustvari.

Držite obe pravili izrecni, namesto da bi poskušali napisati eno, ki pokriva obe verigi. Ločena pravila so lažja za branje in vam omogočajo, da onemogočite pot usmerjevalnika, ne da bi motili promet odjemalcev med odpravljanjem napak. Prav tako naredijo števce smiselne enega za drugim.

Držite lastni promet tunela zunaj pravila

Zunanjo povezavo tunela prav tako ustvari usmerjevalnik. Pravilo, ki pošilja ves lokalno ustvarjeni promet v tunel, bo usmerjalo tunel skozi samega sebe in ta se sploh ne bo dvignil.

Druga žrtev je dostop za upravljanje. Upravljalne seje, ki izvirajo iz usmerjevalnika, ali odgovori nanje, lahko preširoko lokalno pravilo potegne v tunel in postanejo nedosegljive iz LAN.

Izključite končno točko tunela iz ujemanja in držite pravilo omejeno na naslove razreševalnika. To zadostuje za zahtevo DNS in je dovolj majhno, da je mogoče razmišljati o njem.

Preizkusite obe populaciji, ne ene

Opazujte, kako usmerjevalnik izvaja lastno poizvedbo, in zabeležite, kateri vmesnik jo je nosil. Ponovite iskanje z gostitelja v LAN in zabeležite, katero pot je ubralo. Števci na pravilih pravil naredijo oba odgovora vidna brez ugibanja.

Rezultate obravnavajte kot dve ugotovitvi. Odjemalec, ki razrešuje skozi tunel, ne pove nič o usmerjevalniku, in usmerjevalnik, ki razrešuje pravilno, ne pove nič o odjemalcu na drugem poslušalcu. Zapišite jih kot ločene vrstice v dnevniku sprememb.

Preverite tudi vrata: pravilo, ki se ujema s ciljnimi vrati 53, zgreši razreševalnik, dosežen prek DNS over TLS na 853 ali končne točke HTTPS. Ujemajte promet, ki ga konfigurirani upstream dejansko uporablja, in puščanje se zapre iz pravega razloga.