1) リバースパスフィルタリングの無効化

1) リバースパスフィルタリングの無効化

高度な情報

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.5Aにルーティングされるため、マシン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 42ip 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)、クライアントは接続できました。6journalctl -fu openvpn-server@<conf_file_name>.servicerp_filter2

おすすめ記事