web-dev-qa-db-ja.com

OpenVPNクライアントがアクティブなサーバーでのSSHの許可

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
17
odie5533

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

現在のところ、パブリック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を使用して)私には機能しませんが、あなたを助けるかもしれないことに注意してください。

17
MrK

これは少し遅れるかもしれませんが...

問題は、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ゲートウェイでなければなりません。

18
John Doe

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

16
SandPox

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

0
user3820047

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>の値は、ユーザーが選択した任意の識別子です。

0
alecov

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

0
nandoP