WireGuard DNS DNAT: tartsa működőképesen a válasz útvonalát

A DNAT a célt írja át, nem a forrást. Döntse el, hogyan tud válaszolni a felsőbb resolver, mielőtt hozzáadja a szabályt, és tartsa szűken minden egyezést.

Ha egy WireGuard-kliens DNS-kérdését másik resolverre irányítja, az egy szabálynak látszik, és három döntésként viselkedik. A célt át kell írni, a csomagot tovább kell küldeni, és a válasznak meg kell találnia az utat visszafelé azon a fordítási állapoton keresztül, amelyet az átjáró létrehozott. Ha kihagyja a harmadikat, a kérdés szépen elmegy, miközben a kliens örökké vár.

Vegyük a 10.77.0.0/24 hálózatban lévő engedélyezett kliensek példáját, akik a wg0 felől érkeznek, a meghirdetett 10.77.0.1 címet kérdezik, és resolverre van szükségük a 203.0.113.53 címen. A felsőbb cím dokumentációs helyőrző, nem működő szolgáltatás.

A kérdés átirányítása csak a célt változtatja meg

A PREROUTING cél-NAT szabálya az útválasztási döntés meghozatala előtt átírja a címet, így a csomag ezután a régi helyett az új cél felé lesz irányítva. A kliens forráscímét ez a művelet nem érinti. Ezért egy teljesnek tűnő szabály mégis csendet eredményezhet: a kérés most olyan resolverhez megy, amely soha nem hallott a kliens privát tartományáról. Az átjáró egy mezőt fordított le, és örökölt egy második problémát.

Mindkét DNS-szállításnak megfelelő szabályokra van szüksége, mert a kliens TCP-re esik vissza, amikor a választ csonkolják.

Az alábbi szabályok egy bejövő interfészt, egy klienssávot és egy eredeti célcímet választanak ki. Az átjárón semmi más nem érintett, és magának az átjárónak a kérdése egyáltalán nem egyezik.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p udp --dport 53 -j DNAT --to-destination 203.0.113.53:53
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p tcp --dport 53 -j DNAT --to-destination 203.0.113.53:53

A válasz útvonala külön döntés

Két elrendezés engedi visszatérni a választ, és az egyik korai kiválasztása megspórol egy hibakeresési munkamenetet. Vagy a felsőbb resolvernek van visszaútja a 10.77.0.0/24 hálózatba ezen az átjárón keresztül, vagy az átjáró a forrást fordítja a kilépésnél, hogy a válasz olyan címre érkezzen, amelyet a felsőbb fél már ismer. Mindkettő működik; csak az egyik felel meg a felsőbb fél feletti irányításának.

Az útválasztás érdemli az első próbát, mert a kliens címét láthatóan tartja a resolver számára, és elkerül egy második fordítási réteget. Ha a felsőbb fél az irányításán kívül esik, a forrás fordítása az adott kilépő interfészen a gyakorlati választás.

Szűkítse ezt a fordítást ugyanolyan szorosan, mint az átirányítást, különben a szabály általános célú NAT-tá válik mindenre, ami véletlenül illeszkedik:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p udp --dport 53 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p tcp --dport 53 -j MASQUERADE

A kapcsolatkövetés párban tartja a leképezést, így a válasz a visszafelé úton visszaíródik a kliens eredeti tuple-jére. A kilépő szabály nélkül a resolver a válaszát egy privát cím felé küldi, amelyet nem ér el, és a kliens hiba helyett időtúllépést lát.

A szabályokat szűkebben írja meg, mint amilyennek a feladat látszik

A továbbítási engedély ugyanahhoz a hatókörhöz tartozik. Engedélyezze a kliens és a resolver közötti folyamot, valamint a visszirányú forgalmat, amelyet a conntrack már felismer, ahelyett hogy a gépen minden DNAT-kapcsolatot elfogadna. A teljes engedélyezés olyan porttovábbításokat is jóváhagy, amelyeknek semmi közük a DNS-hez.

Az átjáró saját resolvere más kódútvonal. A helyben kiadott kérdés az OUTPUT-on halad át, ezért az átjáró shelljéből végzett teszt sem a PREROUTING szabályt, sem a továbbítási szabályzatot nem gyakorolja. Ezért lehet egy helyi teszt sikeres, miközben minden kliens elbukik, és fordítva is ugyanilyen gyakori.

Semmi itt nem fedi le a DNS-t HTTPS felett a 443-as porton vagy a DNS-t TLS felett a 853-as porton, és semmi nem fedi le az IPv6-ot. Az IPv6 resolverrel beállított kliens vígan figyelmen kívül hagyja az egész elrendezést.

Mit bizonyít egy friss kérdés

A kapcsolatkövetés emlékszik a korábbi leképezésekre, ezért egy szabályváltozás előtt elküldött kérdés a régi állapotból is megválaszolható, és az új szabályt töröttnek mutathatja. Kezdjen új forrásporttal, és ahol a kliens gyorsítótárazza a válaszokat, új névvel.

dig @10.77.0.1 example.com A +short
conntrack -L -p udp --dport 53 | head

Az első parancs megmutatja, hogy a kliensútvonal egyáltalán feloldódik-e, a második pedig azt a fordítást, amelyet az átjáró valóban telepített, a tuple mindkét irányával együtt. Egy helyes resolverre mutató, nullán ragadt válaszszámlálójú leképezés visszaúti probléma, nem szűrési probléma.

Erősítse meg, hogy a resolver ismeri azokat a neveket, amelyeket vár, mielőtt bármit átirányítana. A Olyan csere, amely a nyilvános nevekre válaszol, de a privát zónájára nem egy működő keresést olyan NXDOMAINné alakít, amely törött alagútnak látszik. Tesztelje a resolvert közvetlenül, az átjáróról, mielőtt a kliensútvonal bekerül a képbe. A az iptables-bővítmények referenciája pedig dokumentálja a DNAT és a masquerade szemantikáját, amelyre ezek a szabályok támaszkodnak.

Kapcsolódó cikkek