ネットワークネームスペースを介して特定のアプリケーションにVPNを使用する

ネットワークネームスペースを介して特定のアプリケーションにVPNを使用する

このガイドを使用して、ネットワークネームスペースを使用してVPN関連トラフィックを処理しようとしています。https://schnouki.net/posts/2014/12/12/openvpn-for-a-single-application-on-linux/Debian で。

以下のように名前空間と花嫁を設定するのがすべてです。名前空間名は piavpn、名前空間側の veth は vpn1、基本側の veth は vpn0 です。ただし、その名前空間ではインターネットやメインネットワークにアクセスできません。

名前空間から:

sudo ip netns exec piavpn ip addr list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
7: vpn1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether da:8f:25:6f:47:74 brd ff:ff:ff:ff:ff:ff
    inet 10.200.200.2/24 scope global vpn1
       valid_lft forever preferred_lft forever
    inet6 fe80::d88f:25ff:fe6f:4774/64 scope link 
       valid_lft forever preferred_lft forever

一般的なネットワークでは:

ip addr list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 00:90:f5:eb:90:24 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 68:17:29:90:f5:ba brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.16/24 brd 192.168.0.255 scope global dynamic wlan0
       valid_lft 80406sec preferred_lft 80406sec
    inet6 fe80::6a17:29ff:fe90:f5ba/64 scope link 
       valid_lft forever preferred_lft forever
4: vmnet1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 00:50:56:c0:00:01 brd ff:ff:ff:ff:ff:ff
5: vmnet8: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 00:50:56:c0:00:08 brd ff:ff:ff:ff:ff:ff
8: vpn0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 2a:19:71:d5:79:29 brd ff:ff:ff:ff:ff:ff
    inet 10.200.200.1/24 scope global vpn0
       valid_lft forever preferred_lft forever
    inet6 fe80::2819:71ff:fed5:7929/64 scope link 
       valid_lft forever preferred_lft forever

pingには2つの方法があります。

ping 10.200.200.2
PING 10.200.200.2 (10.200.200.2) 56(84) bytes of data.
64 bytes from 10.200.200.2: icmp_seq=1 ttl=64 time=0.084 ms
64 bytes from 10.200.200.2: icmp_seq=2 ttl=64 time=0.068 ms

sudo ip netns exec piavpn ping 10.200.200.1
PING 10.200.200.1 (10.200.200.1) 56(84) bytes of data.
64 bytes from 10.200.200.1: icmp_seq=1 ttl=64 time=0.088 ms
64 bytes from 10.200.200.1: icmp_seq=2 ttl=64 time=0.040 ms

ただし、その名前空間ではインターネットやメインネットワークにアクセスできません。 sysctlでipv4転送を有効にしたため、これはiptablesの問題のようです。

私のiptablesルールは次のとおりです。https://gist.github.com/anonymous/a1b440f1d3538be6557d

NAT iptablesのルールは次のとおりです。

sudo iptables -t nat --list
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  10.200.200.0/24      anywhere            
MASQUERADE  all  --  10.200.200.0/24      anywhere            
MASQUERADE  all  --  10.200.200.0/24      anywhere            
MASQUERADE  all  --  10.200.200.0/24      anywhere            
MASQUERADE  all  --  anywhere             anywhere            
MASQUERADE  all  --  10.0.0.0/8           anywhere

明らかに、私が何度も試したところが混乱していました。しかし、忍耐力を持たなければなりません。

名前空間から通常の接続を取得するまで、VPNについて心配する必要はありません。

答え1

トリックはufwを無効にすることです。

sudo ufw disable

その後、iptablesを更新してルールを再度追加し、NetworkManagerが何らかの理由で上書きして/etc/resolv.confを再作成しました。

今、すべてが完璧です。

関連情報