私はアウトバウンドパケットをセキュリティ協会に合わせるために一週間以上努力してきました。
私の(例)シナリオは次のとおりです。
- LAN:1.1.1.0/24
- FreeBSD インターフェイス: xn0 (Amazon EC2 インスタンス)
- NAT トラフィックの仮想アドレスは 2.2.2.2/32 から来ます。
- 目的地到着: 3.3.3.3/32
問題の説明
FreeBSD BoxですべてのSAが実行されているという事実にもかかわらず、pfまたはipfwを使用してパケットをnatしようとする試みは機能せず、natされたパケットはデフォルトのルーティングインターフェイスを使用して流れ続け、ipsecトンネルに入りません。 。
以下はSAの使用例です。
$ ipsec status vpn
vpn{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: cca608fa_i d74355dc_o vpn{1}: AES_CBC_256/HMAC_SHA2_256_128, 2688 bytes_i (32 pkts, 32s ago), 4992 bytes_o (32 pkts, 32s ago), rekeying in 43 minutes vpn{1}: 2.2.2.2/32 === 3.3.3.3/32
私のNATルールは次のとおりですpf.conf
。
nat on enc0 from 1.1.1.0/24 to 2.2.2.2/32 -> 3.3.3.3
これは私のものですipsec0 interface status
:
ipsec0: flags=8011<UP,POINTOPOINT,MULTICAST> metric 0 mtu 1400 inet 3.3.3.3/32 --> 2.2.2.2/32 netmask 0xffffffff options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> reqid: 0 groups: ipsec
3.3.3.3から2.2.2.2にスムーズに行くことができます。
以下は、xn0(物理インターフェイス)の単純なパケットキャプチャです。
$ tcpdump -i xn0 -n -vvv host 2.2.2.2
1.1.1.10 > 2.2.2.2: ICMP echo request, id 15745, seq 818, length 64
そしてenc0にはトラフィックは表示されません。
もう一つの試みは、次のように設定することですsysctl
。
net.inet.ipsec.filtertunnel=1
しかし、このオプションが正確に何をしているのかわかりません。
私は多くの人がこの自然現象を働かせようとしましたが、成功しないことを見ました。
答え1
数日間、苦労した後、次の手順でこの問題を処理することができ、他の人を助けるためにここに解決策を投稿します。
ソースを関連付ける必要なSAの一意のIDを取得します。たとえば、次のようになります。
setkey -DP
そしてSA固有のIDを見つけます。
3.3.3.3[any] 2.2.2.2[any] any
out ipsec
esp/tunnel/REALIPLOCAL-REALIPREMOTE/unique:1
created: Jul 22 22:29:34 2018 lastused: Jul 22 22:29:34 2018
lifetime: 9223372036854775807(s) validtime: 0(s)
spid=2715 seq=0 pid=13358 scope=global
refcnt=1
この場合:1
新しいポリシーを追加:
setkey -v -c
spdadd -4 1.1.1.0/24 2.2.2.2/32 any -P out ipsec esp/tunnel/REALLOCALIP-REALREMOTEIP/unique:1;
これは、トンネル内でパケットをルーティングし、実際にインストールされたSAと一致させるのに十分でなければなりません。
このUniqueIDは、インストールされているSAと一致する必要があります。 StrongSwanでSAのインストール順序を変更する場合は、新しいUniqueIDに対応するようにこのポリシーを変更する必要があります。
natルールはenc0インターフェイスに適用する必要があります。
引用:
https://github.com/opnsense/core/issues/440
頑張ってください。