OpenWrt-politiikkareititys: ketju, joka nappaa paikallisen DNS:n

LAN:n asiakkaat ratkaisevat tunnelin kautta, eivätkä reitittimen omat haut hiljaa tee niin. Pakettipäivitykset, aikasynkronointi ja dynaaminen DNS lähtevät kaikki tavallista uplinkia pitkin, kun taas jokainen välitetty kysely ottaa VPN:n, eikä mikään käyttöliittymässä vihjaa, että kaksi eri polkua on olemassa. Selitys ei ole käytännön bugi vaan kysymys siitä, mikä koukku näkee paketin. Kaksi virtaa, yksi ratkaisijan osoite, ja vain toinen niistä ylittää reitittimen. Niiden erottaminen on koko korjaus.

Kaksi virtaa, yksi ratkaisijan osoite

Ensimmäinen virta on se, jonka ihmiset kuvittelevat. Asiakas kysyy reitittimen ratkaisijalta, ratkaisija välittää ylöspäin, ja tuo välitetty paketti kulkee reitittimen läpi lähtiessään ulos. Tuo paketti on näkyvissä kaikelle, mikä tarkkailee välitettyä liikennettä.

Toinen virta ei koskaan saavu mistään. Reititin luo sen, joten sisääntulevaa pakettia ei ole eikä sovitettavaa välitysaskelta.

Molemmat voivat kohdistaa samaan ratkaisijan osoitteeseen, ja juuri siksi ero on helppo jättää huomaamatta. Sama kohde, eri alkuperä, eri ketju. Kun näet alkuperän, loput diagnoosista seuraa.

Välitetyt ja paikallisesti luodut paketit tulevat sisään eri tavalla

Välitetty liikenne arvioidaan, kun se saapuu toisesta liittymästä. Politiikkareitityspaketit paljastavat sen prerouting-ketjuna, ja sinne sijoitettu sääntö näkee jokaisen reitittimen ylittävän paketin. Siksi asiakkaiden haut käyttäytyvät täsmälleen kuten käytäntö kuvaa, ja siksi reititin jättää sen huomiotta. Sääntö ei ole väärä, se on vain kiinnitetty koukkuun, johon reititin ei koskaan pääse. Siirrä se, ja sama osuma alkaa toimia.

Paikallisesti luodun liikenteen luo reitittimen prosessi, ja se tulee lähtöpolulle. Reitittimen oma päätös reitittää sen, ja se kohtaa käytännön vain, jos käytäntö kattaa tuon ketjun. Ei ole saapuvaa liittymää sovitettavaksi eikä välityspäätöstä tarkkailtavaksi.

Se on ominaisuus siitä, missä paketit syntyvät, ei mistään tietystä paketista. Yhdelle ketjulle kirjoitetulla säännöllä ei yksinkertaisesti ole mielipidettä toisesta. Mikään sääntöjen viritys ei muuta sitä.

Valitse lähtöketju ja kavenna sitten osumaa

Korjaus on kiinnittää sama aikomus myös lähtöketjuun tai siirtää sääntö sinne, kun reitittimen omat kyselyt ovat se, mikä sinua kiinnostaa. Politiikkareitityspaketille rakennetussa OpenWrt-asennuksessa se tarkoittaa outputin valitsemista preroutingin sijaan säännön ketjuasetuksessa. Pidä molemmat säännöt, jos molemmat populaatiot tarvitsevat kattavuutta.

Kavenna sitten sitä, mihin sääntö osuu. Kohderatkaisijan osoitteet portilla, jota ratkaisija todella käyttää, on paljon pienempi päätös kuin lähettää kaikki reitittimen luoma tunneliin.

Pidä kaksi sääntöä selkeinä sen sijaan, että yrittäisit kirjoittaa yhden, joka kattaa molemmat ketjut. Erilliset säännöt ovat helpompia lukea, ja niiden avulla voit poistaa reitittimen polun käytöstä häiritsemättä asiakasliikennettä, kun teet vianetsintää. Ne tekevät myös laskureista merkityksellisiä yksi kerrallaan.

Pidä tunnelin oma kuljetus säännön ulkopuolella

Tunnelin ulomman yhteyden luo myös reititin. Sääntö, joka lähettää kaiken paikallisesti luodun liikenteen tunneliin, reitittää tunnelin itsensä kautta, eikä se nouse lainkaan.

Hallintayhteys on toinen uhri. Reitittimestä alkavat hallinnolliset istunnot tai niiden vastaukset voivat joutua tunneliin liian laajan paikallisen säännön vuoksi ja muuttua LAN:sta tavoittamattomiksi.

Jätä tunnelin päätepiste osuman ulkopuolelle ja pidä sääntö rajattuna ratkaisijan osoitteisiin. Se riittää DNS-vaatimukseen ja on tarpeeksi pieni pohdittavaksi.

Testaa molempia populaatioita, älä yhtä

Seuraa, miten reititin tekee oman kyselynsä, ja merkitse, mikä liittymä sen vei. Toista haku LAN-isännästä ja merkitse polku, jonka se otti. Politiikkasääntöjen laskurit tekevät molemmat vastaukset näkyviksi ilman arvailua.

Käsittele tuloksia kahtena löydöksenä. Tunnelin kautta ratkaiseva asiakas ei kerro mitään reitittimestä, eikä oikein ratkaiseva reititin kerro mitään toisella kuuntelijalla olevasta asiakkaasta. Kirjoita ne erillisiksi riveiksi muutoslokiin.

Tarkista myös portti: sääntö, joka osuu kohdeporttiin 53, ohittaa ratkaisijan, johon päästään DNS over TLS:n kautta portilla 853 tai HTTPS-päätepisteen kautta. Sovita kuljetus, jota määritetty ylävirta todella käyttää, ja vuoto sulkeutuu oikeasta syystä.