☰

ワイヤレスホットスポット経由の「バックパス」が機能しない

tag-icon • tag-icon linux networking iptables wifi routing
ワイヤレスホットスポット経由の「バックパス」が機能しない

ワイヤレスホットスポットを実行するLinuxデバイスがあります。

my laptop (LAN only: 192.168.1.100)
  |
 LAN
  |
wireless hotspot laptop (LAN: 192.168.1.101, wireless hotspot: 10.42.0.1, VMs: 10.254.2.x)
  |
wireless printer (wifi: 10.42.0.67)

私のラップトップでは、LAN IP（192.168.1.101）を使用してワイヤレスホットスポットノートブックにping /接続できます。

私のラップトップに次のルートを追加した後、ワイヤレスホットスポットIP（10.42.0.1）にping/接続することもできました。

ip route add to 10.42.0.0/24 via 192.168.1.101

次のルーティングルールを追加すると、ラップトップのVMにping/接続することもできます。

ip route add to 10.254.2.0/24 via 192.168.1.101

ただし、ワイヤレスネットワーク（10.42.0.0/24）内のすべてのデバイスのping / connection - サイコロがないため、「ターゲットポートに接続できません」と表示されます。

# ping 10.42.0.67
PING 10.42.0.67 (10.42.0.67) 56(84) bytes of data.
From 192.168.1.101 icmp_seq=1 Destination Port Unreachable
From 192.168.1.101 icmp_seq=2 Destination Port Unreachable
^C
--- 10.42.0.67 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1001ms

ワイヤレスホットスポットノートブックに次のMASQUERADEルールを追加すると、ノートブックは8.8.8.8と通信できます。

iptables -t nat -A POSTROUTING -s 192.168.1.100 -j MASQUERADE

ワイヤレスホットスポットノートブックのtcpdumpは、私のラップトップから8.8.8.8へのトラフィックがそれを通過していることを示しています。

# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=44.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=46.9 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 44.425/45.668/46.912/1.243 ms

それでも10.42.0.67（ワイヤレスホットスポットの背後にあるワイヤレスプリンタ）に接続 - サイコロなし（以下はワイヤレスホットスポットのtcpdumpです）：

01:25:20.901823 enp1s0 In  IP (tos 0x0, ttl 64, id 37541, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.1.100 > 10.42.0.67: ICMP echo request, id 216, seq 16, length 64
01:25:20.902038 enp1s0 Out IP (tos 0xc0, ttl 64, id 11555, offset 0, flags [none], proto ICMP (1), length 112)
    192.168.1.101 > 192.168.1.100: ICMP 10.42.0.67 protocol 1 port 12067 unreachable, length 92
        IP (tos 0x0, ttl 63, id 37541, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.1.100 > 10.42.0.67: ICMP echo request, id 216, seq 16, length 64

LinuxがルーティングしたりNATしたくないWi-Fiに特別なものはありますか？

現在のnftablesルールは次のとおりです。lxd一部はnm-shared-wlp2s0ワイヤレスホットスポットに関連しており、iptablesルールはありません（上記の例ではMASQUERADEはありません）。

table inet lxd {
        chain pstrt.lxdbr0 {
                type nat hook postrouting priority srcnat; policy accept;
                ip saddr 10.254.2.0/24 ip daddr != 10.254.2.0/24 masquerade
        }

        chain fwd.lxdbr0 {
                type filter hook forward priority filter; policy accept;
                ip version 4 oifname "lxdbr0" accept
                ip version 4 iifname "lxdbr0" accept
        }

        chain in.lxdbr0 {
                type filter hook input priority filter; policy accept;
                iifname "lxdbr0" tcp dport 53 accept
                iifname "lxdbr0" udp dport 53 accept
                iifname "lxdbr0" icmp type { destination-unreachable, time-exceeded, parameter-problem } accept
                iifname "lxdbr0" udp dport 67 accept
        }

        chain out.lxdbr0 {
                type filter hook output priority filter; policy accept;
                oifname "lxdbr0" tcp sport 53 accept
                oifname "lxdbr0" udp sport 53 accept
                oifname "lxdbr0" icmp type { destination-unreachable, time-exceeded, parameter-problem } accept
                oifname "lxdbr0" udp sport 67 accept
        }
}
table ip nm-shared-wlp2s0 {
        chain nat_postrouting {
                type nat hook postrouting priority srcnat; policy accept;
                ip saddr 10.42.0.0/24 ip daddr != 10.42.0.0/24 masquerade
        }

        chain filter_forward {
                type filter hook forward priority filter; policy accept;
                ip daddr 10.42.0.0/24 oifname "wlp2s0" ct state { established, related } accept
                ip saddr 10.42.0.0/24 iifname "wlp2s0" accept
                iifname "wlp2s0" oifname "wlp2s0" accept
                iifname "wlp2s0" reject
                oifname "wlp2s0" reject
        }
}

ベストアンサー1

名前で判断すると、システムにはファイアウォールルールを適用する2つのツールがあります。 LXD（邪魔しない：何も削除または拒否されません）と選択した名前から見つける必要があるもう1つのツールですnm-shared-wlp2s0。

これがどのツールであるかを特定し、他のLANからプリンタネットワークにアクセスできるように例外を追加するようにツールを設定する必要があります。

一方、これに対応する多くのオプションのうち、これを手動で実行することもできます。たとえば、別のLANからこのLANに着信パケットを有効にするには、次の手順を実行します。

nft insert rule nm-shared-wlp2s0 filter_forward ip saddr 192.168.1.0/24 ip daddr 10.42.0.0/24 oifname "wlp2s0" ct state new accept

ツールがファイアウォールルールを再設定するたびにこれを行う必要があります（ルールが「積極的に」削除されないことを願っています）。

さらに、テーブル（およびそれを生成したツール）は、間違ったパケットを拒否する前に破棄するベストプラクティスに従いません。無効なパケットを拒否（削除する代わりに）すると問題が発生する可能性があり、特にパケットの順序が変わると問題が発生する可能性があります。この引用の後の説明を参照してください。iptables（しかし、それも影響を与えます。nftables）詳細：

警告：接続状態がINVALIDとして分類されたパケットには、REJECT宛先を無分別に適用しないでください。代わりに、それらを削除する必要があります。

（オプション）前のコマンドの後に次のものを追加する必要があります。

nft insert rule nm-shared-wlp2s0 filter_forward index 2 ct state invalid drop

パケットが並べ替えられたときに発生する可能性があるトラフィックの中断を防ぐために（Wi-Fiが原因で発生する可能性があります）

テーブルごとですので参考にしてくださいnftablesパケットに影響を与える可能性があるジャムが発生する機会を提供します。パケットがテーブル内のリンクによって承認されても、同じ場所にリンクされている別のチェーンに引き続き破棄される可能性があります。以下は、Netfilterのフィルタ/配信に接続された2つのリンクです。inet lxd fwd.lxdbr0とip nm-shared-wlp2s0 filter_forward: 各リンクにはパケットをドロップする機会があります。

おすすめ記事