Cum se redirecționează cererea DNS către un sistem de la distanță rezolvat?

Încercam să rezolv sistemul ca server de cache DNS la distanță (știu că nu este destinat să facă acest lucru). Am adăugat modificarea net.ipv4.conf.br0.route_localnet la 1 și am adăugat următoarele reguli nftable:

table ip nat {
    preroutare în lanț {
        tip nat hook prerouting prioritate 100; acceptarea politicii;
        iif "br0" udp dport 53 contor pachete 6 octeți 366 dnat la 127.0.0.53
    }

    postrouting în lanț {
        tip nat hook postrouting prioritate -100; acceptarea politicii;
        ip saddr 127.0.0.53 oif pachete de contor „br0” 0 octeți 0 snat la 192.168.1.2
    }
}

Regula de preroutare pare să funcționeze, deoarece există pachete care se potrivesc cu regulile. Cu toate acestea, nu există niciun pachet din gazdă, care este problema?

Cum pot redirecționa cererea DNS de la 192.168.1.0/24 la găzduit de sistem rezolvat pe dispozitivul lo al lui 192.168.1.2 cu IP 127.0.0.53?

systemd-rezolvat se leagă de uite interfata:

# ss -aunp src == 127.0.0.53 sport == 53
State Recv-Q Trimitere-Q Adresă locală:Port Adresă peer:Port 
UNCONN 0 0 127.0.0.53%lo:53 0.0.0.0:* utilizatori:(("systemd-resolve",pid=44157,fd=17))

Acest lucru limitează rutele disponibile chiar și o singură dată net.ipv4.conf.br0.route_localnet=1 se aplica celor stabilite pe uite interfata:

$ ip -4 route show table all dev lo
Broadcast 127.0.0.0 tabel local protokernel scope link src 127.0.0.1 
local 127.0.0.0/8 tabel local proto kernel domeniu gazdă src 127.0.0.1 
local 127.0.0.1 tabel local proto kernel domeniu gazdă src 127.0.0.1 
difuzare 127.255.255.255 tabel local proto kernel scope link src 127.0.0.1 

Niciuna nu se va potrivi.

Adresa sursă ar trebui schimbată. În timp ce cel rar folosit tip de intrare nat hook tipul de lanț ar permite modificarea adresei sursei înainte ca aplicația să o primească, este deja prea târziu: acest lucru se întâmplă după ce rutarea a fost finalizată și pachetul este deja abandonat. Deci, NAT cu stare de stat nu poate gestiona acest caz.

În schimb, un proxy ar putea fi folosit pentru aceasta (după eliminarea tuturor setărilor nat specifice). Iată un exemplu de utilizare socat. socat nefiind o aplicație dedicată, există avertismente în special pentru UDP.

• Gestionarea TCP (OP a uitat că și DNS folosește TCP)

  socat TCP4-LISTEN:53,bind=192.168.1.2,reuseaddr,furk TCP4:127.0.0.53:53
  

  Nu se poate lega de IN_ADDR_ANY deoarece 127.0.0.53:53 este deja legat, deci legați la adresa furnizată de OP (din motive greșite): 192.168.1.2. Pe lângă asta, este destul de simplu.

• Manevrarea UDP

  socat -T 20 UDP4-LISTEN:53,bind=192.168.1.2,reuseaddr,furk UDP4:127.0.0.53:53
  

  Timeout-ul anilor 20 este aici pentru că socat nu i se poate spune să înceteze imediat după primirea unui singur răspuns la pachetul UDP și ar păstra toate bifurcate socat comenzi care se acumulează în timp.

  În timp ce UDP nu trebuie să se lege la o adresă în acest caz, legarea la o adresă folosind UDP evită avertismentul legat de multi-homing și necesitatea de a utiliza IP_PKTINFO optiunea priza.