☰

Wie leite ich eine DNS-Anfrage an ein Remote-System mit Auflösung um?

tag-icon • tag-icon linux-networking nat nftables
Wie leite ich eine DNS-Anfrage an ein Remote-System mit Auflösung um?

Ich habe versucht, systemaufgelöste DNS-Caching-Server als Remote-DNS-Caching-Server einzurichten (ich weiß, dass dies nicht beabsichtigt ist). Ich habe net.ipv4.conf.br0.route_localnet auf 1 geändert und die folgenden nftable-Regeln hinzugefügt:

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
    }
}

Die Prerouting-Regel scheint zu funktionieren, da es Pakete gibt, die den Regeln entsprechen. Es kommt jedoch kein Paket vom Host. Wo liegt das Problem?

Wie kann ich eine DNS-Anfrage von 192.168.1.0/24 an eine systemd-aufgelöste Adresse umleiten, die auf dem lo-Gerät von 192.168.1.2 mit der IP 127.0.0.53 gehostet wird?

Antwort1

systemd-resolvedbindet an die loSchnittstelle:

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

Dies begrenzt die verfügbaren Routen, auch wenn net.ipv4.conf.br0.route_localnet=1es auf die in der Schnittstelle festgelegten Routen angewendet wird lo:

$ 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

Keiner wird passen.

Die Quelladresse müsste geändert werden. Während der selten verwendete type nat hook inputKettentyp es erlauben würde, die Quelladresse zu ändern, bevor die Anwendung sie erhält, ist es bereits zu spät: Dies geschieht, nachdem das Routing abgeschlossen ist und das Paket bereits gelöscht wurde. Stateful NAT kann diesen Fall also nicht verarbeiten.

Stattdessen könnte hierfür ein Proxy verwendet werden (nachdem alle spezifischen NAT-Einstellungen entfernt wurden). Hier ist ein Beispiel mitsocat. socatda es sich nicht um eine dedizierte Anwendung handelt, gibt es Einschränkungen, insbesondere für UDP.

  • TCP-Behandlung (OP hat vergessen, dass DNS auch TCP verwendet)

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

    Kann nicht gebunden werden, IN_ADDR_ANYda 127.0.0.53:53 bereits gebunden ist, also binde an die vom OP bereitgestellte Adresse (aus den falschen Gründen): 192.168.1.2. Abgesehen davon ist es ganz einfach.

  • UDP-Behandlung

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

    Das 20-Sekunden-Timeout ist hier, weil socatnicht angewiesen werden kann, direkt nach dem Empfang der einzelnen UDP-Paketantwort aufzuhören, und sich sonst alle gegabelten socatBefehle mit der Zeit ansammeln würden.

    Während UDP in diesem Fall nicht an eine Adresse gebunden sein muss, vermeidet die Bindung an eine Adresse mit UDP die Einschränkung im Zusammenhang mit Multihoming und die Notwendigkeit, dieIP_PKTINFOSocket-Option.

verwandte Informationen