iptablesはDNSルックアップを偽装して破壊します。

iptablesはDNSルックアップを偽装して破壊します。

ローカルで生成されたトラフィックに対してIP迷彩を使用してテストしていますが、DNSルックアップが中断されているようです。他のすべてはうまくいきます。 DNSクエリを持たないすべてのIPトラフィックが機能します。

$ iptables -t mangle -A OUTPUT -j MARK --set-mark 2
$ iptables -t nat -A POSTROUTING -m mark --mark 0x2 -j MASQUERADE

これがDNSクエリを除くすべてのIPトラフィックに適用されるのはなぜですか?

要求されたコマンドの結果は次のとおりです。

# ip address

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp2s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 54:21:c6:28:99:1f brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether c1:b2:a1:55:34:d2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.108/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp3s0
       valid_lft 242078sec preferred_lft 242078sec
    inet6 fe80::1dd6:f094:be8d:ef51/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

# ip route

default via 192.168.1.1 dev wlp3s0 proto dhcp metric 600 
169.254.0.0/16 dev wlp3s0 scope link metric 1000 
192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.108 metric 600

驚くべきことに、systemdは127.0.0.53でDNSサーバーとして機能します。


systemctl status systemd-resolved両方のコマンドを有効にすると、「systemd-resolved [3315]:予期しないIP範囲でパケットが受信されました」と報告されます。


私はこの質問が関連していると思います。

これら2つのリンクの関連部分は次のとおりです。

127.0.0.53:53に対するすべてのクエリは、127.0.0.0/8で発生するのではなく、マスカレーディングのためにデフォルトパスを持つインターフェイスで発生し、systemd-resolvedはこれらすべての要求を拒否します。

systemd-resolved[21366]: 予期しない IP 範囲でパケットが受信され、拒否されました。

systemd-resolvedスタブリゾルバーの送信元/宛先アドレスを確認するには追加の努力が必要なので、MASQUERADEルールは次の仮定を破ります。

if (in_addr_is_localhost(p->family, &p->sender) <= 0 ||
            in_addr_is_localhost(p->family, &p->destination) <= 0) {
                log_error("Got packet on unexpected IP range, refusing.");
                dns_stub_send_failure(m, s, p, DNS_RCODE_SERVFAIL, false);
                goto fail;
        }

答え1

これは私にとってうまくいきます。ローカルインターフェイスを除くと、nslookupは正常に動作します。

sudo iptables ! -o lo -t nat -A POSTROUTING -j MASQUERADE

答え2

私にとってsystemdの解析動作に基づいたソリューションは、次の規則を実装することです。

$ iptables -t mangle -A OUTPUT ! -s 127.0.0.1 -j MARK --set-mark 2
$ iptables -t nat -A POSTROUTING -m mark --mark 0x2 -j MASQUERADE

答え3

systemd-resolvedをオフにしましたが、まだDNSリゾルバの問題があるため、あなたのマングルソリューションを使用して解決しました。

おそらく、私たちはファイアウォールとしてsystemd-resolvedではなくiptablesだけを望んでいるので、代替答えを考えてみましょう。

hostname/etc/systemd/resolved.conf.d/00-.conf に StubListener がありません。

不便な点は、私たちがsystemdを解決しただけで実行を停止できず、iptablesからファイアウォールドメインを削除できないことです。

しばらくの間、Google パーサーに従うか、opennic パーサーを使用してこれを防ぐためのオプションがありました。最速のローカルオプションを確認するには、名前銀行を確認してください。

また、dnsmasq または古い djbdns dnscache を使用することもできます。 dnsmasq、dnscache、または組み合わせを使用して、googleおよび/またはopennicまたは他のすべての機能を改善できます。私はdnsmasqとnamebench-ed opennic plus 127.0.0.53 dnscacheを使用しているので、www.bigtube.com SERVFAILには3分もかかりません! /etc/resolvconfとNetworkManagerにdnsmasq 127.0.0.1があります。 Erwin Hoffmannのdjbns dnscacheにはipv6がありますが、個人的には気にしません。

関連情報