SSHで接続するCentOS 7を実行するVPSがあります。 VPSでOpenVPNクライアントを実行して、インターネットトラフィックがVPN経由でルーティングされるようにしたいのですが、それでもSSH経由でサーバーに接続できます。 OpenVPNを起動すると、SSHセッションが切断され、VPSに接続できなくなります。着信SSH(ポート22)接続をVPSの実際のIP(104.167.102.77)で開くことを許可しながら、VPNを介して(VPSのWebブラウザーなどから)発信トラフィックをルーティングするようにVPSを構成するにはどうすればよいですか?
私が使用しているOpenVPNサービスはPrivateInternetAccessで、config.ovpnファイルの例は次のとおりです。
client dev tun proto udp remote nl.privateinternetaccess.com 1194 resolv-retry infinite nobind persist-key persist-tun ca ca.crt tls-client remote-cert-tls server auth-user-pass comp-lzo verb 1 reneg-sec 0 crl-verify crl.pem
VPSのIPアドレス:
1:lo:mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8スコープHost lo valid_lft forever preferred_lft forever inet6 :: 1/128 scope Host valid_lft forever preferred_lft forever 2:ens33:mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:50:56:be:16:f7 brd ff:ff:ff:ff:ff:ff inet 104.167.102.77/24 brd 104.167.102.255 scope global ens33 valid_lft forever preferred_lft forever inet6 fe80 :: 250:56ff:febe:16f7/64 scope link valid_lft forever preferred_lft forever 4:tun0:mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100 link/none inet 10.172.1.6 peer 10.172.1.5/32 scope global tun0 valid_lft forever preferred_lft forever
VPSのIPルート:
0.0.0.0/1 via 10.172.1.5 dev tun0 default via 104.167.102.1 dev ens33 proto static metric 1024 10.172.1.1 via 10.172.1.5 dev tun0 10.172.1.5 dev tun0プロトカーネルスコープリンクsrc 10.172.1.6 104.167.102.0/24 dev ens33プロトカーネルスコープリンクsrc 104.167.102.77 109.201.154.177経由で104.167.102.1 dev ens33 128.0。 10.172.1.5 dev tun0経由の0.0/1
私はこれと同様の問題を抱えており、 このフォーラムの投稿 で説明されている修正を試みています。
現在のところ、パブリックIPアドレスに接続すると、リターンパケットがVPN経由でルーティングされるという考え方です。これらのパケットを強制的にパブリックインターフェイス経由でルーティングする必要があります。
これらのルートコマンドはうまくいけばトリックを実行します:
x.x.x.xテーブル128からのIPルール追加
ip route add table 128 to y.y.y.y/y dev ethX
ip route add table 128 default via z.z.z.z
ここで、x.x.x.xはパブリックIP、y.y.y.y/yはパブリックIPアドレスのサブネット、ethXはパブリックイーサネットインターフェイス、z.z.z.zはデフォルトゲートウェイです。
これは(DebianとPrivateInternetAccessを使用して)私には機能しませんが、あなたを助けるかもしれないことに注意してください。
これは少し遅れるかもしれませんが...
問題は、OpenVPNによってデフォルトゲートウェイが変更され、OpenVPNを開始する前に適切なルートを設定しない限り、現在のSSH接続が切断されることです。
次は私のために働きます。 iptablesとip(iproute2)を使用します。以下では、OpenVPNが起動する前のデフォルトゲートウェイインターフェースが「eth0」であると想定しています。これは、eth0がデフォルトゲートウェイインターフェイスではなくなった場合でも、eth0への接続が確立されたときに、その接続の応答パケットがeth0に再び戻るようにするためです。
接続マーク、ファイアウォールマーク、ルーティングテーブルに同じ番号を使用できます。それらの違いをより明確にするために、明確な数値を使用しました。
# set "connection" mark of connection from eth0 when first packet of connection arrives
Sudo iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234
# set "firewall" mark for response packets in connection with our connection mark
Sudo iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
# our routing table with eth0 as gateway interface
Sudo ip route add default dev eth0 table 3412
# route packets with our firewall mark using our routing table
Sudo ip rule add fwmark 4321 table 3412
===
更新:
上記は、Debian Jessieでは私にとってはうまくいきます。しかし、古いWheezyシステムでは、ルーティングテーブルエントリに「via」を追加する必要があることがわかりました。
# our routing table with eth0 as gateway interface
Sudo ip route add default dev eth0 via 12.345.67.89 table 3412
「12.345.67.89」は元の非VPNゲートウェイでなければなりません。
@MrKの回答に基づいて、インターフェイス/ IPを確認する必要がないように、ここで簡単なコードを記述して作業を迅速化します。
ip rule add from $(ip route get 1 | grep -Po '(?<=src )(\S+)') table 128
ip route add table 128 to $(ip route get 1 | grep -Po '(?<=src )(\S+)')/32 dev $(ip -4 route ls | grep default | grep -Po '(?<=dev )(\S+)')
ip route add table 128 default via $(ip -4 route ls | grep default | grep -Po '(?<=via )(\S+)')
私はVPSの4つでこのスクリプトを試しましたが、完全に機能しています。
私がpfSenseでOpenVPNサーバーを実行している私にとっては、「クライアントが生成したすべてのIPv4トラフィックをトンネル経由で強制する」設定をオフにすることでした。
VPNを起動すると、デフォルトゲートウェイが置き換えられます。つまり、ボックスから生成された、またはボックスを介してルーティングされたトラフィックは、VPNゲートウェイに転送されます。
簡単な解決策は、VPN経由でルーティングしたくないすべてのトラフィックをフィルタリングし、それを使用して他のことを行うことです。 1つの可能性は、ボックスから生成されたトラフィックをローカルソースアドレスでピックアップし、ローカルゲートウェイ経由でルーティングすることです。これにより、SSHなどのサービスが正しく機能するようになります。
ここでそれを行います。まず、新しいルーティングテーブルを作成し、すべてをローカルゲートウェイ経由でルーティングするデフォルトルートを追加します。
# <table> is any number between 2 and 252.
# Check /etc/iproute2/rt_tables for more info.
ip route add default via <gateway> table <table>
ip route add <lan-addr> dev <device> table <table>
次に、特定の送信元アドレスからボックスを出るすべてのトラフィックに何らかの識別子を付けてマークする新しいパケットフィルタールールを作成します。
# <mark> is any number.
iptables -tmangle -AOUTPUT -s<local-addr> -jMARK --set-mark <mark>
最後に、前述のすべてのマークされたトラフィックを選択し、上記の生成されたテーブルを使用してルーティングするルーティングポリシーを作成します。
ip rule add fwmark <mark> table <table>
ここでも、<mark>
および<table>
の値は、ユーザーが選択した任意の識別子です。
うーん、IPサブネットオーバーラップのように聞こえます... nl.privateinternetaccess.comとしてのVPNターミネーションのパブリックIP以外は、IPスキームの詳細を知らないと、確実に判断できません。
たとえば、nl.privateinternetaccess.comの反対側のリモートサブネットが10.32.43.0/24で、インスタンスがサブネットが10.32.44.0/24のaws vpcにある場合などです。ただし、ソースsshクライアントは10.32.43.0/24(aws vpcのユーザー側)にあるため、戻りSSHトラフィックが誤ってvpn経由でオランダにプッシュされるため、機能しません。
これに関するより多くの助けのために完全なIP /サブネット情報を提供してください。
...
oK、nlに接続した後、デフォルトのルートがトンネルにあるように見えます:
10.172.1.5 dev tun0経由の0.0.0.0/1
接続後に変更できます。多くの場合、VPNサーバーは偽のルートを提供します。特にずさんな軍団で。この場合、デフォルトのルートがプッシュされるため、vpsボックスからのすべてのトラフィックはnlに送られます。デフォルトルートを104.167.102.xまたはur vpsプロバイダーのurサブネットゲートウェイに変更します。