OpenWrt-policy-routing: kedjan som fångar lokal DNS

Klienter på LAN löser genom tunneln och routerns egna uppslag gör det tyst inte. Paketuppdateringar, tidssynkronisering och dynamisk DNS går alla ut över den vanliga uplinken, medan varje vidarebefordrad fråga tar VPN:en, och ingenting i gränssnittet antyder att det finns två olika vägar. Förklaringen är inte en bugg i policyn utan en fråga om vilken krok som ser paketet. Två flöden, en resolveradress, och bara ett av dem korsar routern. Att skilja dem åt är hela rättelsen.

Två flöden, en resolveradress

Det första flödet är det folk föreställer sig. En klient frågar routerns resolver, resolvern vidarebefordrar uppströms, och det vidarebefordrade paketet passerar routern på väg ut. Det paketet är synligt för allt som övervakar vidarebefordrad trafik.

Det andra flödet anländer aldrig från någonstans. Routern skapar det, så det finns inget inkommande paket och inget vidarebefordringssteg att matcha.

Båda kan rikta in sig på samma resolveradress, och just därför är skillnaden lätt att missa. Samma mål, annat ursprung, annan kedja. När du ser ursprunget följer resten av diagnostiken.

Vidarebefordrade och lokalt skapade paket kommer in olika

Vidarebefordrad trafik utvärderas när den anländer från ett annat gränssnitt. Policy-routing-paket exponerar det som en prerouting-kedja, och en regel placerad där ser varje paket som korsar routern. Därför beter sig klientuppslag precis som policyn beskriver, och därför ignorerar routern den. Regeln är inte fel, den är bara fäst vid en krok som routern aldrig når. Flytta den, och samma matchning börjar fungera.

Lokalt skapad trafik skapas av en process på routern och går in i utgångsvägen. Den routas av routerns eget beslut och möter bara policyn om policyn täcker den kedjan. Det finns inget inkommande gränssnitt att matcha och inget vidarebefordringsbeslut att observera.

Det är en egenskap hos var paket föds, inte hos ett visst paket. En regel skriven för en kedja har helt enkelt ingen åsikt om den andra. Ingen mängd regeljustering ändrar det.

Välj utgångskedjan och smalna sedan av matchningen

Rättelsen är att knyta samma avsikt till utgångskedjan också, eller att flytta regeln dit när det är routerns egna frågor du bryr dig om. I en OpenWrt-installation byggd på ett policy-routing-paket betyder det att välja output i stället för prerouting i regelns kedjeinställning. Behåll båda reglerna om båda populationerna behöver täckning.

Smalna sedan av vad regeln matchar. Destinationsresolveradresser på den port som resolvern faktiskt använder är ett mycket mindre beslut än att skicka allt routern skapar in i tunneln.

Håll de två reglerna explicita i stället för att försöka skriva en som täcker båda kedjorna. Separata regler är lättare att läsa, och de låter dig inaktivera routerns väg utan att störa klienttrafik medan du felsöker. De gör också räknarna meningsfulla en i taget.

Håll tunnelns egen transport utanför regeln

Tunnelns yttre anslutning skapas också av routern. En regel som skickar all lokalt skapad trafik in i tunneln kommer att routa tunneln genom sig själv, och den kommer inte upp alls.

Administrationsåtkomst är det andra offret. Administrativa sessioner som uppstår från routern, eller svar på dem, kan dras in i tunneln av en alltför bred lokal regel och bli oåtkomliga från LAN.

Uteslut tunnelns slutpunkt från matchningen och håll regeln begränsad till resolveradresserna. Det räcker för DNS-kravet och är litet nog att resonera om.

Testa båda populationerna, inte en

Se hur routern gör sin egen fråga och notera vilket gränssnitt som bar den. Upprepa uppslaget från en LAN-värd och notera vilken väg den tog. Räknare på policyreglerna gör båda svaren synliga utan gissningar.

Behandla resultaten som två fynd. En klient som löser genom tunneln säger ingenting om routern, och en router som löser korrekt säger ingenting om en klient på en annan lyssnare. Skriv dem som separata rader i ändringsloggen.

Kontrollera porten också: en regel som matchar destinationsport 53 missar en resolver som nås över DNS over TLS på 853 eller en HTTPS-slutpunkt. Matcha den transport som den konfigurerade uppströmsförbindelsen faktiskt använder, och läckan stängs av rätt anledning.