ローカルで生成されたトラフィックに対して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範囲でパケットが受信されました」と報告されます。
私はこの質問が関連していると思います。
- https://github.com/kubernetes/kubernetes/issues/66067
- https://github.com/kontena/pharos-cluster/issues/482
これら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がありますが、個人的には気にしません。