Rutare pe politici în OpenWrt: lanțul care prinde DNS-ul local

Clienții din LAN rezolvă prin tunel, iar interogările proprii ale routerului, în liniște, nu fac asta. Actualizările de pachete, sincronizarea orei și DNS-ul dinamic ies toate pe uplinkul obișnuit, în timp ce fiecare interogare redirecționată ia VPN-ul, și nimic din interfață nu sugerează că există două căi diferite. Explicația nu este un bug în politică, ci o chestiune de care cârlig vede pachetul. Două fluxuri, o adresă de resolver, și doar unul dintre ele traversează routerul. Separarea lor este toată corectura.

Două fluxuri, o adresă de resolver

Primul flux este cel pe care oamenii îl imaginează. Un client întreabă resolverul routerului, resolverul redirecționează în amonte, iar acel pachet redirecționat trece prin router la ieșire. Acel pachet este vizibil pentru orice observă traficul redirecționat.

Al doilea flux nu sosește niciodată de nicăieri. Routerul îl creează, deci nu există pachet de intrare și nici un pas de redirecționare de potrivit.

Ambele pot viza aceeași adresă de resolver, și exact de aceea diferența este ușor de ratat. Aceeași destinație, altă origine, alt lanț. Odată ce vezi originea, restul diagnosticului urmează.

Pachetele redirecționate și cele generate local intră diferit

Traficul redirecționat este evaluat când sosește de pe altă interfață. Pachetele de rutare pe politici expun asta ca un lanț prerouting, iar o regulă plasată acolo vede fiecare pachet care traversează routerul. De aceea interogările clienților se comportă exact cum descrie politica, și de aceea routerul o ignoră. Regula nu este greșită, este doar atașată de un cârlig la care routerul nu ajunge niciodată. Mut-o, și aceeași potrivire începe să funcționeze.

Traficul generat local este creat de un proces de pe router și intră pe calea de ieșire. Este rutat de decizia routerului însuși și întâlnește politica doar dacă politica acoperă acel lanț. Nu există interfață de intrare de potrivit și nici decizie de redirecționare de observat.

Este o proprietate a locului unde se nasc pachetele, nu a unui pachet anume. O regulă scrisă pentru un lanț pur și simplu nu are părere despre celălalt. Nicio ajustare a regulilor nu schimbă asta.

Alege lanțul de ieșire, apoi îngustează potrivirea

Corectura este să atașezi aceeași intenție și lanțului de ieșire, sau să muți regula acolo când interogările routerului însuși sunt cele care contează. Într-o configurație OpenWrt construită pe un pachet de rutare pe politici, asta înseamnă să alegi output în loc de prerouting în setarea de lanț a regulii. Păstrează ambele reguli dacă ambele populații au nevoie de acoperire.

Apoi îngustează la ce se potrivește regula. Adresele de resolver destinație pe portul pe care resolverul îl folosește cu adevărat sunt o decizie mult mai mică decât trimiterea în tunel a tot ce originează routerul.

Păstrează cele două reguli explicite în loc să încerci să scrii una care acoperă ambele lanțuri. Regulile separate sunt mai ușor de citit și îți permit să dezactivezi calea routerului fără a deranja traficul clienților în timp ce depanezi. De asemenea, fac contoarele semnificative unul câte unul.

Ține transportul propriu al tunelului în afara regulii

Conexiunea exterioară a tunelului este creată tot de router. O regulă care trimite tot traficul generat local în tunel va ruta tunelul prin el însuși, și acesta nu va porni deloc.

Accesul de administrare este a doua victimă. Sesiunile administrative originare din router, sau răspunsurile la ele, pot fi trase în tunel de o regulă locală prea largă și deveni inaccesibile din LAN.

Exclude punctul final al tunelului din potrivire și ține regula limitată la adresele de resolver. Este suficient pentru cerința DNS și destul de mic pentru a raționa asupra lui.

Testează ambele populații, nu una

Urmărește routerul făcându-și propria interogare și notează ce interfață a transportat-o. Repetă căutarea de pe un host din LAN și notează ce cale a luat. Contoarele de pe regulile de politică fac ambele răspunsuri vizibile fără ghicit.

Tratează rezultatele ca două constatări. Un client care rezolvă prin tunel nu spune nimic despre router, iar un router care rezolvă corect nu spune nimic despre un client de pe alt ascultător. Scrie-le ca linii separate în jurnalul modificărilor.

Verifică și portul: o regulă care se potrivește cu portul de destinație 53 ratează un resolver accesat prin DNS over TLS pe 853 sau printr-un punct final HTTPS. Potrivește transportul pe care upstreamul configurat îl folosește cu adevărat, iar scurgerea se închide din motivul corect.