☰

¿Cómo redirigir la solicitud de DNS a un sistema remoto resuelto?

tag-icon • tag-icon linux-networking nat nftables
¿Cómo redirigir la solicitud de DNS a un sistema remoto resuelto?

Estaba intentando resolver el sistema como un servidor de almacenamiento en caché DNS remoto (sé que no está destinado a hacerlo). Agregué el cambio net.ipv4.conf.br0.route_localnet a 1 y agregué las siguientes reglas nftable:

table ip nat {
    chain prerouting {
        type nat hook prerouting priority 100; policy accept;
        iif "br0" udp dport 53 counter packets 6 bytes 366 dnat to 127.0.0.53
    }

    chain postrouting {
        type nat hook postrouting priority -100; policy accept;
        ip saddr 127.0.0.53 oif "br0" counter packets 0 bytes 0 snat to 192.168.1.2
    }
}

La regla de preenrutamiento parece funcionar ya que hay paquetes que coinciden con las reglas. Sin embargo, no sale ningún paquete del host, ¿cuál es el problema?

¿Cómo puedo redirigir la solicitud de DNS desde 192.168.1.0/24 a systemd-resolved alojado en el dispositivo lo de 192.168.1.2 con IP 127.0.0.53?

Respuesta1

systemd-resolvedse une a la lointerfaz:

# ss -aunp src == 127.0.0.53 sport == 53
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port 
UNCONN 0      0      127.0.0.53%lo:53         0.0.0.0:*     users:(("systemd-resolve",pid=44157,fd=17))

Esto limita las rutas disponibles incluso una vez que net.ipv4.conf.br0.route_localnet=1se aplica a las configuradas en la lointerfaz:

$ ip -4 route show table all dev lo
broadcast 127.0.0.0 table local proto kernel scope link src 127.0.0.1 
local 127.0.0.0/8 table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 table local proto kernel scope link src 127.0.0.1

Ninguno coincidirá.

Sería necesario cambiar la dirección de origen. Si bien el tipo de cadena rara vez utilizado type nat hook inputpermitiría cambiar la dirección de origen antes de que la aplicación la recibiera, ya es demasiado tarde: esto sucede después de que se realizó el enrutamiento y el paquete ya se descartó. Por lo tanto, la NAT con estado no puede manejar este caso.

En su lugar, se podría utilizar un proxy para esto (después de eliminar todas las configuraciones nat específicas). He aquí un ejemplo usandosocat. socatAl no ser una aplicación dedicada, existen advertencias especialmente para UDP.

  • Manejo de TCP (OP olvidó que DNS también usa TCP)

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

    No se puede vincular IN_ADDR_ANYporque 127.0.0.53:53 ya está vinculado, así que vincúlese a la dirección proporcionada por OP (por motivos incorrectos): 192.168.1.2. Además de esto, es bastante simple.

  • Manejo de UDP

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

    El tiempo de espera de 20 segundos está aquí porque socatno se le puede ordenar que cese inmediatamente después de recibir la respuesta del paquete UDP único y mantendría todos los socatcomandos bifurcados acumulándose con el tiempo.

    Si bien UDP no tiene que vincularse a una dirección en este caso, vincularse a una dirección mediante UDP evita la advertencia relacionada con el alojamiento múltiple y la necesidad de usar elIP_PKTINFOopción de enchufe.

información relacionada