OpenWrt-policy-ruting: kjeden som fanger lokal DNS

Klienter på LAN løser gjennom tunnelen, og ruterens egne oppslag gjør det stille ikke. Pakkeoppdateringer, tidssynkronisering og dynamisk DNS går alle ut over den vanlige uplinken, mens hver videresendt forespørsel tar VPN-en, og ingenting i grensesnittet antyder at det finnes to forskjellige veier. Forklaringen er ikke en feil i policyen, men et spørsmål om hvilken krok som ser pakken. To flyter, én resolveradresse, og bare én av dem krysser ruteren. Å skille dem er hele rettelsen.

To flyter, én resolveradresse

Den første flyten er den folk forestiller seg. En klient spør ruterens resolver, resolveren videresender oppstrøms, og den videresendte pakken passerer ruteren på vei ut. Den pakken er synlig for alt som overvåker videresendt trafikk.

Den andre flyten ankommer aldri fra noe sted. Ruteren oppretter den, så det finnes ingen innkommende pakke og ingen videresendingstrinn å matche.

Begge kan ha samme resolveradresse som mål, og nettopp derfor er forskjellen lett å overse. Samme mål, annen opprinnelse, annen kjede. Når du ser opprinnelsen, følger resten av diagnosen.

Videresendte og lokalt genererte pakker kommer inn forskjellig

Videresendt trafikk vurderes når den ankommer fra et annet grensesnitt. Policy-ruting-pakker eksponerer det som en prerouting-kjede, og en regel plassert der ser hver pakke som krysser ruteren. Derfor oppfører klientoppslag seg nøyaktig som policyen beskriver, og derfor ignorerer ruteren den. Regelen er ikke feil, den er bare knyttet til en krok ruteren aldri når. Flytt den, og samme treff begynner å virke.

Lokalt generert trafikk opprettes av en prosess på ruteren og går inn i utgangsbanen i stedet. Den rutes av ruterens egen beslutning og møter bare policyen hvis policyen dekker den kjeden. Det er ingen innkommende grensesnitt å matche og ingen videresendingsbeslutning å observere.

Det er en egenskap ved hvor pakker fødes, ikke ved en bestemt pakke. En regel skrevet for én kjede har rett og slett ingen mening om den andre. Ingen mengde regeljustering endrer det.

Velg utgangskjeden, og snevn deretter inn treffet

Rettelsen er å knytte samme hensikt til utgangskjeden også, eller å flytte regelen dit når det er ruterens egne forespørsler du bryr deg om. I et OpenWrt-oppsett bygget på en policy-ruting-pakke betyr det å velge output i stedet for prerouting i regelens kjedeinnstilling. Behold begge reglene hvis begge populasjonene trenger dekning.

Snevn deretter inn hva regelen matcher. Destinasjonsresolveradresser på porten resolveren faktisk bruker er en mye mindre beslutning enn å sende alt ruteren oppretter inn i tunnelen.

Hold de to reglene eksplisitte i stedet for å prøve å skrive én som dekker begge kjedene. Atskilte regler er lettere å lese, og de lar deg deaktivere ruterens vei uten å forstyrre klienttrafikk mens du feilsøker. De gjør også tellerne meningsfulle én om gangen.

Hold tunnelens egen transport utenfor regelen

Tunnelens ytre forbindelse opprettes også av ruteren. En regel som sender all lokalt generert trafikk inn i tunnelen vil rute tunnelen gjennom seg selv, og den vil ikke komme opp i det hele tatt.

Administrasjonstilgang er det andre offeret. Administrative økter som oppstår fra ruteren, eller svar på dem, kan dras inn i tunnelen av en altfor bred lokal regel og bli utilgjengelige fra LAN.

Utelat tunnelens endepunkt fra treffet, og hold regelen begrenset til resolveradressene. Det er nok for DNS-kravet og lite nok til å resonnere om.

Test begge populasjonene, ikke én

Se ruteren gjøre sin egen forespørsel og noter hvilket grensesnitt som bar den. Gjenta oppslaget fra en LAN-vert og noter veien den tok. Tellere på policy-reglene gjør begge svarene synlige uten gjetting.

Behandle resultatene som to funn. En klient som løser gjennom tunnelen sier ingenting om ruteren, og en ruter som løser riktig sier ingenting om en klient på en annen lytter. Skriv dem som separate linjer i endringsloggen.

Sjekk porten også: en regel som matcher destinasjonsport 53 går glipp av en resolver som nås over DNS over TLS på 853 eller et HTTPS-endepunkt. Match transporten den konfigurerte oppstrømsforbindelsen faktisk bruker, og lekkasjen lukkes av riktig grunn.