OpenWrt-policerouting: kæden, der fanger lokal DNS

Klienter på LAN'et slår op gennem tunnelen, og routerens egne opslag gør det stille ikke. Pakkeopdateringer, tidssynkronisering og dynamisk DNS forlader alle det almindelige uplink, mens hver videresendt forespørgsel tager VPN'et, og intet i grænsefladen antyder, at der findes to forskellige veje. Forklaringen er ikke en fejl i politikken, men et spørgsmål om hvilken krog der ser pakken. To flows, én resolveradresse, og kun én af dem krydser routeren. At skille dem ad er hele rettelsen.

To flows, én resolveradresse

Det første flow er det, folk forestiller sig. En klient spørger routerens resolver, resolveren videresender opstrøms, og den videresendte pakke passerer routeren på vej ud. Den pakke er synlig for alt, der overvåger videresendt trafik.

Det andet flow ankommer aldrig fra noget sted. Routeren opretter det, så der er ingen indgående pakke og intet videresendelsestrin at matche.

Begge kan have samme resolveradresse som mål, og netop derfor er forskellen let at overse. Samme destination, forskellig oprindelse, forskellig kæde. Når du ser oprindelsen, følger resten af diagnosen.

Videresendte og lokalt genererede pakker kommer ind forskelligt

Videresendt trafik vurderes, når den ankommer fra en anden grænseflade. Policerouting-pakker blotlægger det som en prerouting-kæde, og en regel anbragt der ser hver pakke, der krydser routeren. Det er derfor, klientopslag opfører sig præcis som politikken beskriver, og derfor ignorerer routeren den. Reglen er ikke forkert, den er blot knyttet til en krog, som routeren aldrig når. Flyt den, og den samme match begynder at virke.

Lokalt genereret trafik oprettes af en proces på routeren og går i stedet ind i output-stien. Den routes af routerens egen beslutning og møder kun politikken, hvis politikken dækker den kæde. Der er ingen indgående grænseflade at matche og ingen videresendelsesbeslutning at observere.

Det er en egenskab ved, hvor pakker fødes, snarere end ved en bestemt pakke. En regel skrevet til én kæde har ganske enkelt ingen mening om den anden. Ingen mængde regeljustering ændrer det.

Vælg output-kæden, og indsnævr derefter matchet

Rettelsen er at knytte den samme hensigt til output-kæden også, eller at flytte reglen derhen, når det er routerens egne forespørgsler, du bekymrer dig om. I en OpenWrt-opsætning bygget på en policerouting-pakke betyder det at vælge output i stedet for prerouting i reglens kædeindstilling. Behold begge regler, hvis begge populationer skal dækkes.

Indsnævr derefter, hvad reglen matcher. Destinationsresolveradresser på den port, resolveren faktisk bruger, er en meget mindre beslutning end at sende alt, hvad routeren opretter, i tunnelen.

Hold de to regler eksplicitte i stedet for at forsøge at skrive én, der dækker begge kæder. Adskilte regler er lettere at læse, og de lader dig deaktivere routerens vej uden at forstyrre klienttrafik, når du fejlfinder. De gør også tællerne meningsfulde én ad gangen.

Hold tunnelens egen transport ude af reglen

Tunnelens ydre forbindelse oprettes også af routeren. En regel, der sender al lokalt genereret trafik i tunnelen, vil route tunnelen gennem sig selv, og den vil slet ikke komme op.

Administrationsadgang er det andet offer. Administrative sessioner, der stammer fra routeren, eller svar på dem, kan trækkes i tunnelen af en alt for bred lokal regel og blive utilgængelige fra LAN'et.

Udeluk tunnelens endepunkt fra matchet, og hold reglen begrænset til resolveradresserne. Det er nok til DNS-kravet og lille nok til at ræsonnere om.

Test begge populationer, ikke én

Se routeren lave sin egen forespørgsel, og noter, hvilken grænseflade der bar den. Gentag opslaget fra en LAN-vært, og noter den vej, den tog. Tællere på politikreglerne gør begge svar synlige uden gætværk.

Behandl resultaterne som to fund. En klient, der slår op gennem tunnelen, siger intet om routeren, og en router, der slår korrekt op, siger intet om en klient på en anden lytter. Skriv dem som separate linjer i ændringsloggen.

Tjek også porten: en regel, der matcher destinationsport 53, overser en resolver, der nås over DNS over TLS på 853 eller et HTTPS-endepunkt. Match den transport, den konfigurerede upstream faktisk bruger, og lækagen lukkes af den rigtige grund.