OpenWrt-beleidsroutering: de keten die lokaal DNS vangt

Clients op de LAN lossen op via de tunnel en de eigen opzoekingen van de router doen dat stilletjes niet. Pakketupdates, tijdsynchronisatie en dynamische DNS verlaten allemaal de gewone uplink, terwijl elke doorgestuurde query de VPN neemt, en niets in de interface suggereert dat er twee verschillende paden bestaan. De verklaring is geen bug in het beleid maar een kwestie van welke haak het pakket ziet. Twee stromen, één resolveradres, en slechts één ervan steekt de router over. Ze scheiden is de hele oplossing.

Twee stromen, één resolveradres

De eerste stroom is degene die mensen zich voorstellen. Een client vraagt de resolver van de router, de resolver stuurt stroomopwaarts door, en dat doorgestuurde pakket passeert de router op weg naar buiten. Dat pakket is zichtbaar voor alles wat doorgestuurd verkeer waarneemt.

De tweede stroom komt nooit ergens vandaan. De router maakt hem, dus er is geen inkomend pakket en geen doorstuurstap om te matchen.

Beide kunnen hetzelfde resolveradres als doel hebben, en juist daarom is het verschil makkelijk te missen. Zelfde bestemming, andere oorsprong, andere keten. Zodra je de oorsprong ziet, volgt de rest van de diagnose.

Doorgestuurde en lokaal gegenereerde pakketten komen anders binnen

Doorgestuurd verkeer wordt beoordeeld wanneer het van een andere interface komt. Beleidsrouteringspakketten leggen dat bloot als een prerouting-keten, en een regel die daar staat ziet elk pakket dat de router oversteekt. Daarom gedragen clientverzoeken zich precies zoals het beleid beschrijft, en daarom negeert de router het. De regel is niet fout, hij hangt alleen aan een haak die de router nooit bereikt. Verplaats hem, en dezelfde match begint te werken.

Lokaal gegenereerd verkeer wordt door een proces op de router gemaakt en komt in het uitvoerpad terecht. Het wordt gerouteerd door de beslissing van de router zelf en komt alleen met beleid in aanraking als het beleid die keten dekt. Er is geen inkomende interface om te matchen en geen doorstuurbeslissing om te observeren.

Dat is een eigenschap van waar pakketten geboren worden, niet van een bepaald pakket. Een regel die voor de ene keten is geschreven heeft simpelweg geen mening over de andere. Geen enkele regelafstelling verandert dat.

Kies de uitvoerketen en vernauw dan de match

De oplossing is dezelfde bedoeling ook aan de uitvoerketen te hangen, of de regel daarheen te verplaatsen wanneer het de eigen verzoeken van de router zijn die je aangaan. In een OpenWrt-opstelling gebouwd op een beleidsrouteringspakket betekent dat output kiezen in plaats van prerouting in de keteninstelling van de regel. Houd beide regels als beide populaties dekking nodig hebben.

Vernauw dan wat de regel matcht. Bestemmingsresolveradressen op de poort die de resolver echt gebruikt zijn een veel kleinere beslissing dan alles wat de router maakt de tunnel in sturen.

Houd de twee regels expliciet in plaats van één proberen te schrijven die beide ketens dekt. Aparte regels zijn makkelijker te lezen, en ze laten je het pad van de router uitschakelen zonder clientverkeer te storen terwijl je debugt. Ze maken ook de tellers één voor één zinvol.

Houd het eigen transport van de tunnel buiten de regel

De buitenste verbinding van de tunnel wordt ook door de router gemaakt. Een regel die al het lokaal gegenereerde verkeer de tunnel in stuurt, routeert de tunnel door zichzelf, en hij komt helemaal niet omhoog.

Beheerstoegang is het tweede slachtoffer. Administratieve sessies die van de router afkomstig zijn, of antwoorden daarop, kunnen door een te brede lokale regel de tunnel in worden getrokken en onbereikbaar worden vanaf de LAN.

Sluit het eindpunt van de tunnel uit van de match, en houd de regel beperkt tot de resolveradressen. Dat is genoeg voor de DNS-eis en klein genoeg om over na te denken.

Test beide populaties, niet één

Kijk hoe de router zijn eigen query doet en noteer welke interface die droeg. Herhaal de opzoeking vanaf een LAN-host en noteer welk pad die nam. Tellers op de beleidsregels maken beide antwoorden zichtbaar zonder te gissen.

Behandel de resultaten als twee bevindingen. Een client die via de tunnel oplost zegt niets over de router, en een router die correct oplost zegt niets over een client op een andere listener. Schrijf ze als afzonderlijke regels in het wijzigingslog.

Controleer ook de poort: een regel die bestemmingspoort 53 matcht mist een resolver die via DNS over TLS op 853 of een HTTPS-eindpunt wordt bereikt. Match het transport dat de geconfigureerde upstream echt gebruikt, en het lek sluit om de juiste reden.