高度な情報
Machines involved:
A := vpn server inet 10.9.0.1 peer 10.9.0.2 tun0
B := vpn server inet 10.8.0.1 peer 10.9.0.2 tun2
vpn client inet 10.9.0.6 peer 10.9.0.5 tun1
C := vpn client inet 10.8.0.6 peer 10.9.0.5 tun0
説明する
合計3つの機械があります。マシンBはopenvpnサーバーとクライアントを実行します。マシンAがredirect-gateway def1
マシンBにプッシュすると、VPNサーバーの応答パケットがルーティングの理由でマシン0.0.0.0/1 via 10.9.0.5, 128.0.0.0/1 via 10.9.0.5
Aにルーティングされるため、マシンCは明らかにマシンBのopenvpn-serverに接続できません。これで、コンピュータのB WANゲートウェイを介してパケットをルーティングするには、ポリシールーティングが必要です。
1回試行失敗
次のコマンドを使用して、VPNサーバーから送信されたパケットを表示しようとしています。
iptables -t mangle -A OUTPUT -p tcp -m multiport --sports 1194 -j MARK --set-xmark 14
ip route add table 14 default via WAN_IP
ip rule add fwmark 14 table 14
しかし、まだマシンAにルーティングされ、tcpdump -i tun1
マシンBとマシンAtcpdump -i tun0
で観察できます。
**machine B**
eth0:
22:22:33.734511 IP machine_C_IP.54089 > machine_B_IP.1194: UDP, length 86
tun1:
22:32:42.713371 IP 10.9.0.6.1194 > machine_C_IP.34514: UDP, length 94
**machine A**
tun0:
20:47:47.769628 IP machine_A_IP.openvpn > machine_C_IP.40287: UDP, length 94
2回試行失敗
また、openvpnプロセス所有者がパケットを表示してみました。私に加えた[Eメール保護] Group = vpnserver
それから:
iptables -t mangle -A OUTPUT -m Owner --gid-owner vpnserver -j MARK --set-xmark 14 ip ルート追加テーブル 14 デフォルトでは、fwmark 14 は WAN_GATEWAY IP ルールで追加されます。表 14
ただし、パケットはまだマシンAにルーティングされます。
働く
次の方法はうまくいきますが、クライアントごとにIPごとにパスを追加する必要があるため、不便で使用しないようにします。一部のクライアントには動的IPがあるため、スクリプトを使用してドメイン名で正しいIPを取得する必要があります。
ip route add table 14 default via WAN_IP
ip rule add to machine_C_IP table 14
抽象的な
実際のルーティング後にiptablesのOUTPUTチェーンが適用されるため、タグ付きパケットが正しくルーティングされないのではないか?それとも、パケットを表示したときに何かが落ちましたか?発信VPNサーバーパケットを私のWANゲートウェイにルーティングする他の方法はありますか?
現状
路線default via WAN_GATEWAY dev eth0 table 42
0.0.0.0/1 via 10.9.0.5 dev tun1
default via WAN_GATEWAY dev eth0 onlink
10.1.1.0/24 dev veth0 proto kernel scope link src 10.1.1.2
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
10.9.0.0/24 via 10.9.0.5 dev tun1
10.9.0.5 dev tun1 proto kernel scope link src 10.9.0.6
WAN_SUBNET/26 via WAN_GATEWAY dev eth0
WAN_SUBNET/26 dev eth0 proto kernel scope link src WAN_IP
MACHINE_A_IP via WAN_GATEWAY dev eth0
128.0.0.0/1 via 10.9.0.5 dev tun1
知的財産権規則
0: from all lookup local
32760: from all fwmark 0xe lookup 42
32761: from all fwmark 0xa lookup 42
32764: from all to WAN_IP lookup 42
32765: from WAN_IP lookup 42
32766: from all lookup main
32767: from all lookup default
答え1
スレッドの以前の答えに基づいて、OpenVPN 2.4.3を実行しているUbuntu 17.10(賢い)コンピュータで問題を解決した方法です。
1) リバースパスフィルタリングの無効化
私たちはする必要がありますユニキャストリバースパス転送の変更厳格モード(rp_filter=2
)の代わりに緩和モード(rp_filter=1
)を使用してください。厳密モードでは、戻りパケットを転送するために使用されるのと同じネットワークインターフェイスから着信パケットを受信する必要があります。
sysctl -w net.ipv4.conf.<if>.rp_filter=2
<if>
コンピュータがルータに接続するために使用する物理イーサネットインターフェイスはどこにありますか?私の場合、コマンドは次のようになりましたsysctl -w net.ipv4.conf.enp2s0.rp_filter=2
。カーネルパラメータを読むにはsysctl net.ipv4.conf.<if>.rp_filter
。
再起動後も変更を保持するには、次の行を追加または変更します/etc/sysctl.conf
。
net.ipv4.conf.<if>.rp_filter=2
2)暗号化されたパケットを表示するようにOpenVPNサーバーを設定する
サーバー.conf
ファイルに以下を追加します。
mark <value>
ここでは<value>
、パケットを表示するために使用される任意の固有値です。これにより、OpenVPNサーバーによって暗号化されたパケットを再ルーティングできます。私はそれを使用しましたmark 9
。
OpenVPNサーバーを再起動してください。
3) 新しい IP ルールと IP パスを使用して、表示されたパケットをルータに再ルーティングします。
ip rule add fwmark <value> table <N>
ip route add default via <router> table <N>
これは<N>
ルーティングテーブルのランダムな一意の番号であり、<router>
私のLAN上のルータのIPアドレスです。つまり、次のコマンドを実行しました。ip rule add fwmark 9 table 42
とip route add default via 192.168.8.1 table 42
。
再起動後もこれらの変更を維持する方が難しいです。特に、/etc/network/interfaces
ネットワーク接続を管理するために既存のファイルの代わりに新しいnetplanパッケージを使用するUbuntu 17.10の場合は、さらにそうです。より良い解決策がないので、OpenVPNシステムサービスファイルに一連のコマンドを追加しました。 OpenVPNが起動するExecStartPre=-/sbin/ip rule add fwmark 9 table 42
前に、IPルールとルートが作成されますExecStartPre=-/sbin/ip route add default via 192.168.8.1 table 42
。-
コマンドが失敗しても(ルールまたはパスがすでに存在する場合)、サーバーが起動するようにコマンドパスの前にマイナス記号を使用します。systemd.service のマニュアルページより多くの情報を知りたいです。
ヒント:私はOpenVPNサーバーを私のコンピュータでsystemdサービスとして実行しています。私の場合、この問題を解決するための最良の方法は、ファイルからOpenVPNサーバーの詳細情報を増やして.conf
から 。リバースパスフィルタリングが無効になっていないと、クライアントが接続しようとしたときにどのアクティビティも表示されない可能性があります。設定後(ステップ1)、一部のアクティビティを表示できますが、TLSハンドシェイクは失敗します。 OpenVPNパケットをルーターに再ルーティングした後(ステップ2〜3)、クライアントは接続できました。6
journalctl -fu openvpn-server@<conf_file_name>.service
rp_filter
2
答え2
なぜ失敗したのか
1回試行失敗そして2回試行失敗ルーティングの決定後にiptablesのチェーンが実行されるため、動作しません。 iptablesの図を参照してください。http://inai.de/images/nf-packet-flow.png。
さらに、2回試行失敗無効な方法を使用してVPNサーバーインスタンスのユーザー/グループを設定しました。 systemdユニットファイルではなく、/etc/openvpn/server.confでユーザーまたはグループを指定する必要があります。つまり:
- ユーザーまたはグループの作成
adduser vpnserver
- 次に、ユーザーまたはグループを /etc/openvpn/server.conf に追加します。
user vpnserver
- VPNサーバープロセスがこのユーザー/グループとして実行されていることを確認してください。
ps -A o pid,cmd,user,group|grep vpn
解決策
ローカルプロセスのパケットは、プロセスにセットがある場合にのみ表示できます。アウトレットオプション。 OpenVPNは以下をサポートします。 https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage
/etc/openvpn/server.confのオプションでパケットを表示して--mark value
から。ip rule add fwmark value table 42
ip routes default via WAN_GATEWAY table 42
これにより、マシンCはマシンBのVPNサーバーに接続できます。
選ぶ
または、VPNサーバーとクライアントにnetns名前空間を使用してから、iptablesチェーンを使用することもできます。