私の質問:
私はUbuntu 22.04を使用しており、ExpressVPNのcliツールを使用してExpressVPNでVPNを設定しています。 ExpressVPN では ovpn 構成ファイルも提供されるため、認証情報を保持しながら必要に応じて構成を調整できます。
VPNを使用する前は、ホームルータからポート22を転送し、ネットワーク外からコンピュータにSSH経由で接続できました。
マシンがVPNに接続されていると、SSH経由で接続できなくなります。
私が試したこと:
まず、tcpdumpを使用して、問題が私が考えたこと、つまりルータに接続されたプライマリインターフェイスからの着信インバウンド接続と、ExpressVPN / OpenVPN tun0で生成されたインターフェイスへのアウトバウンドパケットであることを確認しました。
tcpdump 出力の一部:
19:17:22.488812 enp5s0 In IP [src ip omitted] > 192.168.1.20.ssh: Flags [S], seq 2135016686, win 65535, options [mss 1400,sackOK,TS val 58875528 ecr 0,nop,wscale 9], length 0
19:17:22.488853 tun0 Out IP 192.168.1.20.ssh > [src ip omitted]: Flags [S.], seq 2642908921, ack 2135016687, win 64900, options [mss 1310,sackOK,TS val 638298497 ecr 58875528,nop,wscale 7], length 0
19:17:23.514229 tun0 Out IP 192.168.1.20.ssh > [src ip omitted]: Flags [S.], seq 2642908921, ack 2135016687, win 64900, options [mss 1310,sackOK,TS val 638299523 ecr 58875528,nop,wscale 7], length 0
19:17:23.515183 enp5s0 In IP [src ip omitted] > 192.168.1.20.ssh: Flags [S], seq 2135016686, win 65535, options [mss 1400,sackOK,TS val 58876582 ecr 0,nop,wscale 9], length 0
19:17:23.515204 tun0 Out IP 192.168.1.20.ssh > [src ip omitted]: Flags [S.], seq 2642908921, ack 2135016687, win 64900, options [mss 1310,sackOK,TS val 638299524 ecr 58875528,nop,wscale 7], length 0
19:17:25.515204 enp5s0 In IP [src ip omitted] > 192.168.1.20.ssh: Flags [S], seq 2135016686, win 65535, options [mss 1400,sackOK,TS val 58878582 ecr 0,nop,wscale 9], length 0
19:17:25.515227 tun0 Out IP 192.168.1.20.ssh > [src ip omitted]: Flags [S.], seq 2642908921, ack 2135016687, win 64900, options [mss 1310,sackOK,TS val 638301524 ecr 58875528,nop,wscale 7], length 0
19:17:27.546040 tun0 Out IP 192.168.1.20.ssh > [src ip omitted]: Flags [S.], seq 2642908921, ack 2135016687, win 64900, options [mss 1310,sackOK,TS val 638303555 ecr 58875528,nop,wscale 7], length 0
このスレッドへの回答に記載されている指示に従ってください。 VPNサーバーに接続した後にSSHが端末に入ることを許可する方法 成功しませんでした。
提案された解決策がなぜ機能しないのか理解できません。
本質的に私に必要なのは、tun0ではなく、そのネットワークに割り当てられているインターフェイスのパブリックIPを介してネットワーク外で接続を開いたままにする方法です。
ovpn定義(またはコマンドライン)でパスを操作してこれを実行できますか?それとも、iptablesを使用する方が良いですか?それとも、提案されたソリューションを使用して追加したパスが正しくないのでしょうか。
リンクされたスレッドで提案されたソリューションを試している間に、次のルールとパスを追加しました。
ip rule add from x.x.x.x table 128
ip route add table 128 to 255.255.255.0/24 dev enp5s0
ip route add table 128 default via 192.168.1.20
ここで、xxxx は VPN に接続していない場合のパブリック IP です。
VPNに接続した後のパスは次のとおりです。
0.0.0.0/1 via 100.64.100.5 dev tun0
default via 192.168.1.1 dev enp5s0 proto dhcp metric 100
10.0.0.0/8 via 192.168.1.1 dev enp5s0
100.64.100.1 via 100.64.100.5 dev tun0
100.64.100.5 dev tun0 proto kernel scope link src 100.64.100.6
128.0.0.0/1 via 100.64.100.5 dev tun0
169.254.0.0/16 dev tun0 scope link metric 1000
172.16.0.0/12 via 192.168.1.1 dev enp5s0
173.239.199.150 via 192.168.1.1 dev enp5s0
192.168.0.0/16 via 192.168.1.1 dev enp5s0
192.168.1.0/24 dev enp5s0 proto kernel scope link src 192.168.1.20 metric 100
VPNに接続すると、すべてのパスが自動的に追加されます。 VPN 接続がないパスは次のとおりです (助けになる場合)。
default via 192.168.1.1 dev enp5s0 proto dhcp metric 20100
192.168.1.0/24 dev enp5s0 proto kernel scope link src 192.168.1.20 metric 100
新しい路線:
0.0.0.0/1 via 100.64.100.5 dev tun0
default via 192.168.1.1 dev enp5s0 proto dhcp metric 100
10.0.0.0/8 via 192.168.1.1 dev enp5s0
100.64.100.1 via 100.64.100.5 dev tun0
100.64.100.5 dev tun0 proto kernel scope link src 100.64.100.6
128.0.0.0/1 via 100.64.100.5 dev tun0
169.254.0.0/16 dev enp5s0 scope link metric 1000
172.16.0.0/12 via 192.168.1.1 dev enp5s0
173.239.199.206 via 192.168.1.1 dev enp5s0
192.168.0.0/16 via 192.168.1.1 dev enp5s0
192.168.1.0/24 dev enp5s0 proto kernel scope link src 192.168.1.20 metric 100
答え1
接続の問題は、リターンパケットが別のインターフェイスから出てくることです。インバウンドパケットは enp5s0 を介して着信し、 tun0 を通過します。
使用するルールを変更する必要があります。
まず、現在のルールがすでにホスト(宛先)に到達したパケットにのみ影響するように、最初の行を「to」xxxxに変更する必要があります。したがって、パケットには影響しません。これを「to」に変更すると、パケットがホストを離れるインターフェイス/ゲートウェイと送信元IPに影響します。
2行目の255.255.255.0/24は無効で、最も高いユニキャストアドレスは223.255.255.254です。したがって、ルールの2行目は一致しません。
ルールは次のようにする必要があります。
ip rule add to x.x.x.x table 128
ip route add table 128 default via 192.168.1.1 dev enp5s0
これにより、SSHの問題が解決されます。
ルートに関するいくつかの追加注:
0.0.0.0/1 は ips 0.0.0.1 - 127.255.255.254 を表します。 - これはあなたが望むものだとは思わない。アドレスは0.0.0.0/0でなければならず、エイリアスのデフォルト値を使用できます。 **このルートを変更すると、より長いプレフィックス(より具体的なルート)と一致しないすべてのトラフィックがインターネットトラフィックを含むVPNを介してルーティングされます。
答え2
私はProtonVPNで同じ問題を経験しました。私がしたことは、そこからのトラフィックの送信元IPへの静的ルートを作成し、eth0インターフェイスをターゲットとして使用することでした。
ip route add 2.3.4.5 via 4.4.4.4 dev eth0
そのうち、2.3.4.5はソースIP、4.4.4.4はeth0(デフォルトゲートウェイ)のゲートウェイ、eth0はインターフェイスです。