Linux と同等の Macos コマンドを探しています:
sudo iptables -t nat -A POSTROUTING -o en0 -j MASQUERADE
これを実行する理由は、デフォルト ルートを持つ VPN があるものの、特定のアプリを VPN ではなく物理アップリンク経由で実行したいからです。
を使用して、pfctl次の操作を実行しました。
pass out route-to (en0 192.168.4.1) group skipvpn flags any
192.168.4.1私のゲートウェイのIPはどこにありますか？これはグループ内のアプリからのすべてのパケットをインターフェイス（トンネルではなく）skipvpnにルーティングするようです。これを確認するには、en0tcpdump
ただし、再ルーティングされたすべてのパケットの「ソース IP」には、VPN のソース IP (範囲10.0.0.0/8IP) がまだ含まれているため、当然のことながら問題が発生します (つまり、返されるパケットは元の場所に戻ることができません)。
結果として、私はnatこれを使用してソース IP を試みました:
nat on en0 from any to any -> en0
しかし、これはない動作しているように見えますが、ソース IP はまだ壊れており、en0インターフェイスのソース IP に対応していません。
再ルーティングされたパケットのソース IP が正しく設定されていることを確認するにはどうすればよいですか?
答え1
— Mac OS の Pf ではこれが行われません。理由は次のとおりです。
マニュアルを見れば、NATが起こっている前にフィルタリングただし、NAT ルールは、フィルタリング ルールのようにさまざまな特徴をすべてサポートしているわけではありません。つまり、NAT の実行中にソケットの所有権を確認する方法はありません。たとえば、送信元または宛先 IP で NAT ルールの適用範囲を制限することはできますが、所有権を制限することはできません。
もう一つ言及しておきたいのはNAT処理中にPfが通常のルート検索を実行つまり、パケットはカーネルのルーティング テーブルに従ってルーティングされるため、まったく機能しないということです。この場合、パケットはデフォルト ルートのインターフェイス (VPN インターフェイス) 経由で送信されるようにディスパッチされます。また、VPN インターフェイスのアドレスが送信元 IP として使用されます。これは通常のルート検索では驚くことではありませんが、明らかに計画どおりには機能していません。nat on en0
矛盾点を簡単にまとめると次のようになります。
- NATを行わない場合、
route-to適用時にソースIPが間違っています - NATルールは、ソースIPを次のIPに変更しながら、デフォルトルートインターフェース（VPN）に設定する必要があります。非VPNインターフェースは次のようになります:
nat on vpn0 … -> (en0) - しかし、その一方で、カスタム NAT (所有権による) を使用することはできず、いずれにせよ NAT を実行すると、VPN を経由するはずのトラフィックの送信元 IP が間違ってしまいます。
PS Mac OSのPfの実際の状態はさらに悪いNAT が完了すると、所有権の一致もフィルタリング ルールでは機能しなくなります。