アクティブなOpenVPNクライアントを持つサーバーでSSHを許可する

SSHで接続するCentOS 7を実行しているVPSがあります。インターネットトラフィックがVPNを経由するようにVPSでOpenVPNクライアントを実行したいのですが、SSHを介してサーバーに接続できるようにします。OpenVPNを起動すると、SSHセッションが切断され、VPSに接続できなくなります。着信SSH（ポート22）接続がVPSの実際のIP（104.167.102.77）で開かれているが、発信トラフィック（VPSのWebブラウザーからなど）をVPN経由でルーティングできるようにVPSを構成するにはどうすればよいですか？

私が使用するOpenVPNサービスはPrivateInternetAccessであり、config.ovpnファイルの例は次のとおりです。

クライアント
開発者
プロトUDP
リモートnl.privateinternetaccess.com 1194
無限の解決と再試行
ノバインド
永続キー
持続する
ca ca.crt
tls-client
remote-cert-tlsサーバー
auth-user-pass
comp-lzo
動詞1
レネク秒0
crl-verify crl.pem

VPSのIPアドレス：

1：lo：mtu 65536 qdisc noqueue state UNKNOWN
    リンク/ループバック00：00：00：00：00：00 brd 00：00：00：00：00：00
    inet 127.0.0.1/8スコープホストlo
       valid_lft forever preferred_lft forever
    inet6 :: 1/128スコープホスト
       valid_lft forever preferred_lft forever
2：ens33：mtu 1500 qdisc pfifo_fast state UP qlen 1000
    リンク/エーテル00：50：56：be：16：f7 brd ff：ff：ff：ff：ff：ff
    inet 104.167.102.77/24 brd 104.167.102.255スコープグローバルens33
       valid_lft forever preferred_lft forever
    inet6 fe80 :: 250：56ff：febe：16f7 / 64スコープリンク
       valid_lft forever preferred_lft forever
4：tun0：mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    リンク/なし
    inet 10.172.1.6ピア10.172.1.5/32スコープグローバルtun0
       valid_lft forever preferred_lft forever

VPSのIPルート：

10.172.1.5 dev tun0経由の0.0.0.0/1
デフォルトは104.167.102.1を介してdev ens33 proto static metric 1024
10.172.1.1経由10.172.1.5 dev tun0
10.172.1.5 dev tun0 proto kernel scope link src 10.172.1.6
104.167.102.0/24 dev ens33 proto kernel scope link src 104.167.102.77
104.167.102.1 dev ens33経由の109.201.154.177
10.172.1.5 dev tun0経由の128.0.0.0/1

私はこれと同様の問題を抱えており、このフォーラム投稿で説明されている修正を試みています。

アイデアは、現在、パブリックIPアドレスに接続すると、返信パケットがVPN経由でルーティングされるというものです。これらのパケットを強制的にパブリックインターフェイス経由でルーティングする必要があります。

これらのrouteコマンドはうまくいけばトリックを行います：

IPルールはxxxxテーブル128から追加

ipルートテーブル128をyyyy / y dev ethXに追加

IPルートは、zzzzを介してデフォルトのテーブル128を追加します

xxxxはパブリックIP、yyyy / yはパブリックIPアドレスのサブネット、ethXはパブリックイーサネットインターフェイス、zzzzはデフォルトゲートウェイです。

これは（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システムでは、ルーティングテーブルエントリに「経由」を追加する必要があることがわかりました。

# 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つでこのスクリプトを試しましたが、完全に機能しています。

hmmは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サブネットゲートウェイに変更します。

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>は任意の識別子です。

pfSenseで自分でOpenVPNサーバーを実行している私にとっては、「トンネルを通過するすべてのクライアント生成IPv4トラフィックを強制する」設定のチェックを外すことでした。