クラウドでOpenVPNをクライアントモードで実行したいVM(EC2インスタンス))VM)を出るトラフィックは一般にVPNを通過します。ただし、既存のIPアドレスをSSH接続で使用できるようにしたいのです(そのため、現在マシンに接続しているSSH接続が切断されません)。
これが現在の.ovpn
私が使用している設定ファイル:
client
dev tun
proto udp
remote xxx.yyy.com 1198
resolv-retry infinite
nobind
persist-key
persist-tun
cipher aes-128-cbc
auth sha1
tls-client
remote-cert-tls server
auth-user-pass
comp-lzo
verb 1
reneg-sec 0
crl-verify crl.rsa.2048.pem
ca ca.rsa.2048.crt
disable-occ
編集:この質問は重複している可能性があります サーバーマシンでVPNにログインした後にSSH接続が失われるのを防ぎます ...しかし、そこにも受け入れられた答えはありません。
高度なルーティングを使用して、プライマリインターフェイスに着信するパッケージを同じインターフェイス経由でルーティングできます。このようにして、サーバーから発信されたトラフィックはVPN経由でルーティングされますが、サーバーのプライマリインターフェイスは引き続き接続に使用できます。ここでの考え方は、パケットがプライマリインターフェイスを経由する場合、「vpn」という名前の別のルーティングテーブルを使用するため、VPNクライアントのルーティング設定の影響を受けないということです。
これを実現するには、次のようにします。
/etc/iproute2/rt_tables
ファイルを編集します。次のようなものが含まれている必要があります。
#
# reserved values
#
255 local
254 main
253 default
0 unspec
#
# local
#
次の行をファイルの最後に追加します。
1 vpn
/etc/network/interfaces
ファイルのメインインターフェイスの設定(または/etc/network/interfaces.d/
の適切なファイル)に、次の行を追加します。
up ip route add 0.0.0.0/0 via def.ault.gw table vpn
up ip rule add from the.primary.ip.addr table vpn
down ip route del 0.0.0.0/0 table vpn
down ip rule del from the.primary.ip.addr
the.primary.ip.addr
をプライマリインターフェイスのIPアドレス(つまり、サーバーを利用できるようにするIP)に置き換え、def.ault.gw
をデフォルトゲートウェイアドレスに置き換えます。
'--up'および '--down'オプションを使用して、必要に応じてVM)のファイアウォールとルーティングテーブルを操作するシェルスクリプトを実行することをお勧めします。これにより、トンネリングが可能になります。 VPNを介したトラフィック(openvpnがまだ実行していない場合)およびsshトラフィックの例外を作成します。iptablesルールはトップダウン方式で適用されるため、トンネリングルールの前に例外ルールが適用されていることを確認してください。他にも質問があります。ルーティングテーブルとファイアウォールルールを管理する方法の例として使用できます。
あなたが直面している問題は、デフォルトルートがVPN上にあり、送信元へのルートがないインターフェイスから着信するパケットを除外しているルートがあることだと思います。これは RPフィルター と呼ばれます。
Sshdのデフォルトルートを他のプロセスとは異なる2つのソリューションがあります。ネットワーク名前空間を使用することも、cgroupsを使用することもできます。私はそれらについてあまり知りませんが、あなたは以下の答えでもっと読むことができます:
https://superuser.com/questions/271915/route-the-traffic-over-specific-interface-for-a-process-in-linux
提案されているように高度なルーティングによってそれを行うことができますが、それはそれほど単純ではありません。
目標を達成するための最も簡単な解決策は、(ホーム)IPアドレスをアドレス指定するパッケージを異なる方法でルーティングすることです。 sshアクセスをいくつかの安全なIPアドレスに制限することは常に良い考えです。たとえば、次のことができます。
ip route add 1.1.1.1 via 9.9.9.9
ここで、1.1.1.1はホームIPアドレスであり、9.9.9.9はルーティングテーブルのデフォルトゲートウェイすでに到達可能です。これで、マシンから外部IPへのすべてのパッケージが同じ方法で返されます。他のすべては通常どおりVPN経由でルーティングできます。このルートをopenvpn設定ファイルに追加することもできます。すべてが素晴らしいです。
ただし、ホームIPが変更されている場合(動的アドレスとも呼ばれます)、またはランダムなアドレス(複数のユーザー、旅行中)からマシンに到達する必要がある場合はそれほど優れていません。その場合、あなたは困難な道を歩まなければなりません。
何もしなければ、sshパッケージは外部インターフェース(およびIP)に到着しますが、VPN経由でルーティングすると戻る方法を見つけることができません(実際には可能性があります VPN設定によって異なりますが、送信元IPが異なり、パッケージが削除されます)。あなたの目標は、some送信パッケージを外部インターフェースにリダイレクトし、一部をVPNにリダイレクトすることです。これが問題です。
代替ルーティングテーブルを作成します。
echo "100 secure" >> /etc/iproute2/rt_tables
ルーティングの設定と制御:
# route ssh over external iface eth0 to router 9.9.9.9
ip route add default via 9.9.9.9 dev eth0 table secure
# send all packages with fwmark 1 to the secondary routing table
ip rule add fwmark 0x1 table secure
# Mark outgoing ssh packages with the mark 1
iptables -t mangle -A OUTPUT -p tcp --sport 22 -j MARK --set-mark 1
ここでは、すべての発信sshパッケージにマークを付けてから、マークされたすべてのパッケージを代替ルーティングにリダイレクトします。もちろん、すべての回答が別のインターフェイスにリダイレクトされるため、VPNをsshできるようになりましたしません。重要なのは、任意に複雑なiptablesルールを作成し、set-markを使用してそれらを異なる方法でルーティングできることです。
幸い、CONNMARKと呼ばれるものがあり、(カーネルの接続追跡機能を利用して)接続全体を前後にマークできます(xt_connmarkモジュールが必要になります)。
# mark incoming ssh *connection* with 1. Here eth0 is your external interface
iptables -A INPUT -m state --state NEW -i eth0 -p tcp --dport 22 -t mangle -j CONNMARK --set-mark 1
# restore connection mark (e.g. mark the packages)
iptables -A OUTPUT -t mangle -j CONNMARK --restore-mark
# send all packages with fwmark 1 to the secondary routing table as before..
ip rule add fwmark 0x1 table secure
単にコピー&ペーストするのではなく、概念を理解した後、現在の設定に従って上記を使用してください。
Ssh接続が確立されている同じマシンからVPNを使用している場合、追加の問題が発生します。
デフォルトでは、VPNピアがデフォルトゲートウェイになります。 sshパッケージはVPNチャネルを介してルーティングされるため、既存の接続を簡単に切断できます(サーバーはそれらをtunまたはtapインターフェースから取得し、not物理ethインターフェースから取得します)。簡単な解決策は、clientサイド構成にdefault-gatewayオプションを含めないことです(またはプッシュしないでください)。優先サブネットのルートのみをプッシュします。警告:(自宅の)パブリックアドレスを非表示にするようにVPNを作成した場合、これは希望どおりではない可能性があります。