☰

Como redirecionar a solicitação de DNS para um sistema remoto resolvido?

tag-icon • tag-icon linux-networking nat nftables
Como redirecionar a solicitação de DNS para um sistema remoto resolvido?

Eu estava tentando resolver o sistema como um servidor de cache DNS remoto (sei que não é essa a intenção). Adicionei alterei net.ipv4.conf.br0.route_localnet para 1 e adicionei as seguintes regras 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
    }
}

A regra de pré-roteamento parece funcionar porque há pacotes que correspondem às regras. Porém não há nenhum pacote saindo do host, qual é o problema?

Como posso redirecionar a solicitação de DNS de 192.168.1.0/24 para resolvido pelo systemd hospedado no dispositivo lo de 192.168.1.2 com IP 127.0.0.53?

Responder1

systemd-resolvedliga-se à lointerface:

# 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))

Isso limita as rotas disponíveis mesmo depois de net.ipv4.conf.br0.route_localnet=1aplicado àquelas definidas na lointerface:

$ 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

Nenhum irá corresponder.

O endereço de origem precisaria ser alterado. Embora o tipo de cadeia raramente usado type nat hook inputpermita alterar o endereço de origem antes que o aplicativo o receba, já é tarde demais: isso acontece depois que o roteamento foi concluído e o pacote já foi descartado. Portanto, o NAT com estado não pode lidar com esse caso.

Em vez disso, um proxy poderia ser usado para isso (depois de remover todas as configurações de nat específicas). Aqui está um exemplo usandosocat. socatnão sendo um aplicativo dedicado, há ressalvas especialmente para o UDP.

  • Manipulação de TCP (OP esqueceu que o DNS também usa TCP)

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

    Não é possível vincular IN_ADDR_ANYporque 127.0.0.53:53 já está vinculado, portanto, vincule ao endereço fornecido pelo OP (pelos motivos errados): 192.168.1.2. Além disso, é bastante simples.

  • Tratamento UDP

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

    O tempo limite de 20 anos está aqui porque socatnão é possível interromper logo após receber a resposta do pacote UDP único e manteria todos os socatcomandos bifurcados se acumulando ao longo do tempo.

    Embora o UDP não precise se vincular a um endereço neste caso, a vinculação a um endereço usando UDP evita a ressalva relacionada ao multi-homing e à necessidade de usar oIP_PKTINFOopção de soquete.

informação relacionada