OpenWrt-policy-ruting: kjeda som fangar lokal DNS

Klientar på LAN løyser gjennom tunnelen, og rutaren sine eigne oppslag gjer det stille ikkje. Pakkeoppdateringar, tidssynkronisering og dynamisk DNS går alle ut over den vanlege uplinken, medan kvar vidaresend førespurnad tek VPN-en, og ingenting i grensesnittet tyder på at det finst to ulike vegar. Forklaringa er ikkje ein feil i policyen, men eit spørsmål om kva krok som ser pakken. To flytar, éi resolveradresse, og berre éin av dei kryssar rutaren. Å skilja dei er heile rettinga.

To flytar, éi resolveradresse

Den første flyten er den folk førestiller seg. Ein klient spør rutaren sin resolver, resolveren vidaresender oppstraums, og den vidaresende pakken passerer rutaren på veg ut. Den pakken er synleg for alt som overvakar vidaresend trafikk.

Den andre flyten kjem aldri frå noko stad. Rutaren opprettar han, så det finst ingen innkomande pakke og ingen vidaresendingstrinn å matche.

Begge kan ha same resolveradresse som mål, og nettopp difor er skilnaden lett å oversjå. Same mål, annan opphav, anna kjede. Når du ser opphavet, følgjer resten av diagnosen.

Vidaresende og lokalt genererte pakkar kjem inn ulikt

Vidaresend trafikk vert vurdert når han kjem frå eit anna grensesnitt. Policy-ruting-pakkar legg det fram som ei prerouting-kjede, og ei regel plassert der ser kvar pakke som kryssar rutaren. Difor oppfører klientoppslag seg nøyaktig som policyen skildrar, og difor ignorerer rutaren han. Regelen er ikkje feil, han er berre knytt til ein krok rutaren aldri når. Flytt han, og same treff byrjar å verke.

Lokalt generert trafikk vert oppretta av ein prosess på rutaren og går inn i utgangsbanen i staden. Han vert ruta av rutaren si eiga avgjerd og møter berre policyen om policyen dekkjer den kjeda. Det er ingen innkomande grensesnitt å matche og inga vidaresendingsavgjerd å observere.

Det er ein eigenskap ved kvar pakkar vert fødde, ikkje ved ein bestemd pakke. Ein regel skriven for éi kjede har rett og slett inga meining om den andre. Inga mengd regeljustering endrar det.

Vel utgangskjeda, og snevra så inn treffet

Rettinga er å knyte same hensikt til utgangskjeda òg, eller å flytte regelen dit når det er rutaren sine eigne førespurnader du bryr deg om. I eit OpenWrt-oppsett bygt på ein policy-ruting-pakke tyder det å velje output i staden for prerouting i kjedeinnstillinga til regelen. Hald begge reglane om begge populasjonane treng dekning.

Snevra så inn kva regelen matchar. Destinasjonsresolveradresser på porten resolveren faktisk brukar er ei mykje mindre avgjerd enn å sende alt rutaren opprettar inn i tunnelen.

Hald dei to reglane eksplisitte i staden for å prøve å skrive éin som dekkjer begge kjedene. Atskilde reglar er lettare å lese, og dei lèt deg slå av vegen til rutaren utan å forstyrre klienttrafikk medan du feilsøkjer. Dei gjer òg teljarane meiningsfulle éin om gongen.

Hald eigen transport for tunnelen utanfor regelen

Den ytre sambindinga til tunnelen vert òg oppretta av rutaren. Ein regel som sender all lokalt generert trafikk inn i tunnelen vil rute tunnelen gjennom seg sjølv, og han kjem ikkje opp i det heile.

Administrasjonstilgang er det andre offeret. Administrative økter som oppstår frå rutaren, eller svar på dei, kan dragast inn i tunnelen av ein altfor brei lokal regel og bli utilgjengelege frå LAN.

Utelat endepunktet til tunnelen frå treffet, og hald regelen avgrensa til resolveradressene. Det er nok for DNS-kravet og lite nok til å resonnere om.

Test begge populasjonane, ikkje éin

Sjå rutaren gjere sin eigen førespurnad og noter kva grensesnitt som bar han. Gjenta oppslaget frå ein LAN-vert og noter vegen han tok. Teljarar på policy-reglane gjer begge svara synlege utan gissing.

Behandle resultata som to funn. Ein klient som løyser gjennom tunnelen seier ingenting om rutaren, og ein rutar som løyser rett seier ingenting om ein klient på ein annan lyttar. Skriv dei som separate liner i endringsloggen.

Sjekk porten òg: ein regel som matchar destinasjonsport 53 går glipp av ein resolver som ein når over DNS over TLS på 853 eller eit HTTPS-endepunkt. Match transporten den konfigurerte oppstraumsforbindinga faktisk brukar, og lekkasjen vert lukka av rett grunn.