2つのサーバー間のOpenVPN OSPF、複数のトンネル

OpenVPNはよく文書化されており、Habréには次のようなインストールに関する記事があります。

これ



しかし、2台のサーバーと自動フォールトトレランスとの間のいくつかのトンネルが一度に見つからないように。 私の場合、OpenVPNとOSPFが配置されるサーバーは両方ともNATの背後にあります。 これによりソリューションは多少複雑になりますが、主にエッジルーターのインターフェイスから出るトラフィックを制御する必要があるためです。



与えられた:



2台のCentos 7エッジルーター:



r01:

ens0 1.1.1.1-プロバイダー1

ens1 2.2.2.2-プロバイダー2

ens2 10.0.0.1-ゲートウェイとOpenVPNサーバー間の仮想ネットワーク。

r02:

ens0 3.3.3.3-プロバイダー3

ens1 4.4.4.4-プロバイダー4

ens2 10.1.1.1-ゲートウェイとOpenVPNサーバー間の仮想ネットワーク。



2つのOpenVPN / OSPF Centos 7サーバー:



host01:

ens0 10.0.0.2-ネットワークプロバイダーを介したSNAT 1。

ens0 10.0.0.3-ネットワークプロバイダーを介したSNAT 2。

ens1 192.168.0.0/23-ローカルエリアネットワーク。

host02:

ens0 10.1.1.2-ネットワークプロバイダーを介したSNAT 3。

ens0 10.1.1.3-ネットワークプロバイダーを介したSNAT 4。

ens1 192.168.4.0/23-ローカルエリアネットワーク。



このスキームのプロバイダーはすべて異なり、速度、コストも異なります。



チャレンジ:



host01とhost02の間に4つのトンネルを作成して、それらが常にアクティブになるようにし、プロバイダーのいずれかが落ちた場合、ルートはより低速またはより高価なチャネルに切り替える必要があります。 両方のプロバイダーに障害が発生した場合(各サーバーに1つ)、チャネルも機能する必要があります。 同時に、優先チャネルが機能する場合、サーバーはそのチャネルに切り替える必要があります。



この記事では、キーの生成、OpenVPN、Quaggaのインストールのプロセスについては詳しく説明しません。 DHと他のすべてのキーと証明書をすべてのインスタンスに同時に使用できるため、サーバーとクライアントのキーを生成するだけで十分だと言えます。 しかし、もちろん、セキュリティが非常に心配な場合は、トンネルごとに2つの証明書を生成できます。 私の場合、サーバーサービス用とクライアントサービス用の証明書が1つずつありました。



インストール:



システムCentOS Linuxリリース7.4.1708(コア)/ 3.10.0-693.5.2.el7.x86_64。

yum install openvpn easy-rsa quagga

使用されたソフトウェアバージョン:



openvpn 2.4.4 x86_64 easy-rsa 2.2.2-1.el7 quagga.x86_64 0.99.22.4-4.el7
      
      





セットアップ:



次のポートがトンネル用に選択されています。



udp 1150-1.1.1.1-3.3.3.3

udp 1151-2.2.2.2-4.4.4.4

udp 1152-1.1.1.1-4.4.4.4

udp 1153-2.2.2.2-3.3.3.3



OpenVPNでは、サーバーとクライアントがパケットを送信するポートがパケット受信ポートと同じである必要があることに注意する必要があります。NATを使用する場合、発信パケットのポートは異なり、トンネルはそのようなエラーで上昇しません。

TCP / UDP:[AF_INET] 1.1.1.1:1194 [2]から拒否された着信パケット、予想されるピアアドレス:[AF_INET] 1.1.1.1:2364(-remoteを削除するか--floatを追加して、この着信ソースアドレス/ポートを許可します) )



ポートが常に真になるようにするには、境界ルーターとOpenVPNサーバーを設定する必要があります。



host01:



 -A POSTROUTING -p udp --dport 1150 -o ens0 -j SNAT --to-source 10.0.0.2:1050 -A POSTROUTING -p udp --dport 1151 -o ens0 -j SNAT --to-source 10.0.0.3:1051
      
      





同様に、境界ルーターでは次のようになります(r01):



 -A POSTROUTING -p udp -s 10.0.0.2 --dport 1150 -o ens0 -j SNAT --to-source 1.1.1.1:1150 -A POSTROUTING -p udp -s 10.0.0.3 --dport 1151 -o ens1 -j SNAT --to-source 2.2.2.2:1151
      
      





次に、トンネルを構成します。1つのクライアント/サーバーペアの構成を指定し、他のペアも同様に構成します。ポート、アドレス、およびトンネルインターフェイス番号を変更します。



サーバー構成:



 dev tun1 proto udp topology subnet remote 1.1.1.1 ifconfig 10.10.11.1 255.255.255.252 cipher AES-256-CBC persist-tun persist-key ping 10 ping-restart 30 tls-server daemon dh /etc/openvpn/dh2048.pem ca /etc/openvpn/ca.crt cert /etc/openvpn/srv.crt key /etc/openvpn/srv.key reneg-sec 300 port 1150 verb 3
      
      







クライアント構成:



 dev tun1 proto udp topology subnet remote 3.3.3.3 ifconfig 10.10.11.2 255.255.255.252 cipher AES-256-CBC ping 10 ping-restart 30 tls-client daemon ca /etc/openvpn/ca.crt cert /etc/openvpn/cli.crt key /etc/openvpn/cli.key reneg-sec 300 port 1150 verb 3
      
      





トポロジサブネットトンネルの構成における重要なパラメーターであり、ポイントツーポイントインターフェイスではなくサブネットのように見えるようにトンネルのアドレスを指定できます。 このパラメーターはデフォルトのパラメーターではなく、最新のサーバーに推奨されます。 これがないと、トンネル内でブロードキャストパケットを交換する方法がないため、OSPFを構成する方法がありません。



サーバーとクライアントでifconfigトンネルを上げると、次のようになります。



 tun1: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500 inet 10.10.11.1 netmask 255.255.255.252 destination 10.10.11.1
      
      





 tun1: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500 inet 10.10.11.2 netmask 255.255.255.252 destination 10.10.11.2
      
      





4つのトンネルすべてが立ち上がった後、これが写真です。



udp 1150-1.1.1.1-3.3.3.3-tun1-10.10.11.1-10.10.11.2

udp 1151-2.2.2.2-4.4.4.4-tun2-10.10.12.1-10.10.12.2

udp 1152-1.1.1.1-4.4.4.4-tun3-10.10.15.1-10.10.15.2

udp 1153-2.2.2.2-3.3.3.3-tun4-10.10.16.1-10.10.16.2



ファイアウォールルールを追加する場合を除き、追加の静的ルートは必要ありません。



 -A FORWARD -o tun1 -m comment --comment "1" -j ACCEPT -A FORWARD -i tun1 -m comment --comment "1"-j ACCEPT -A FORWARD -o tun2 -m comment --comment "2" -j ACCEPT -A FORWARD -i tun2 -m comment --comment "2"-j ACCEPT -A FORWARD -o tun3 -m comment --comment "3" -j ACCEPT -A FORWARD -i tun3 -m comment --comment "3"-j ACCEPT -A FORWARD -o tun4 -m comment --comment "4" -j ACCEPT -A FORWARD -i tun4 -m comment --comment "4"-j ACCEPT
      
      





耐障害性。



スクリプトを使用してルートスイッチングを実現できますが、面倒であり、エレガントなソリューションではありません。 以前は、実際に動的ルーティングを使用したことはありませんでした。 たくさんのプロトコルがありますが、OSPFにやめたのは、全般的に、より多くの情報とアプリケーションの方法を見つけたからです。 プロトコルlinkstateタイプは、チャネル、インターフェースの状態を考慮に入れて交換します。 これをBGPまたはRIPに実装することはかなり可能だと思います。 ソリューションのBGPバージョンを見てみたいです。

OSPFがLSAサービスパケットを送受信するには、リンクステートアドバタイズメントでファイアウォールのポートを開く必要があります。



 -A INPUT -i tun1 -p 89 -m comment --comment "multicast tun1"-j ACCEPT -A INPUT -i tun2 -p 89 -m comment --comment "multicast tun2"-j ACCEPT -A INPUT -i tun3 -p 89 -m comment --comment "multicast tun3"-j ACCEPT -A INPUT -i tun4 -p 89 -m comment --comment "multicast tun4"-j ACCEPT
      
      





Quaggaのセットアップに移りましょう。



まず、Quaggaサービスの操作に表示されるフォルダーとファイルが、サービスを開始するユーザーに属していることを確認する必要があります。



 chown -R quagga:quagga /etc/quagga chown -R quagga:quagga /var/log/quagga/ospfd.log
      
      





サービスを開始します:



 systemctl start zebra systemctl start ospfd
      
      





その後、OSPFの構成を開始できます。



コンソールにはtelnetまたはvtyshの 2つの方法でアクセスできますが、2 番目の方法を選択しました。

すぐに書き込みを行って構成ファイルのアクセス許可を確認することをお勧めします。そうしないと、入力したすべてのコマンドが保存されず、次のようになります。



 host01# wr Building Configuration... Configuration saved to /etc/quagga/zebra.conf Configuration saved to /etc/quagga/ospfd.conf [OK]
      
      





すべてのインターフェイスがシマウマで利用可能かどうかを確認します。



 sh inter
      
      





OSPFでルーティングされたネットワークとすべてのtunインターフェイスが配置されている場合、続行できます。

まず、トンネルのコストを設定する必要があります。コストが低いほど、トンネルの優先度が高くなります。 次の方法で実行できます。



 interface tun1 ip ospf cost 10
      
      





さらに、私の場合、他のtun2 30、tun3 15、tun4 20についても。



その後、ルーターを起動できます。



 router ospf ospf router-id 192.168.1.0 redistribute connected route-map LAN passive-interface default no passive-interface ens0 no passive-interface tun1 no passive-interface tun2 no passive-interface tun3 no passive-interface tun4 network 10.10.11.0/30 area 0.0.0.0 network 10.10.12.0/30 area 0.0.0.0 network 10.10.15.0/30 area 0.0.0.0 network 10.10.16.0/30 area 0.0.0.0 network 192.168.1.0/23 area 0.0.0.0 ! ip prefix-list LAN seq 10 permit 192.168.4.0/23 ip prefix-list LAN seq 100 deny any ! route-map LAN permit 10 match ip address prefix-list LAN
      
      





この構成では、redistribute connectedパラメーターを使用して、すべてのルートを別のサーバーにアナウンスするだけでなく、必要なルートのみをアナウンスします。また、route-map LANパラメーターを使用すると、ネットワークをフィルターできます。



トンネルの反対側でもまったく同じ構成にする必要があります。 ospfdサービスをアクティブにした後、約10秒後に、両方のサーバーに近隣のルートが表示され、コストに応じてトンネルが選択されます。 優先トンネルが機能しなくなると、トンネルが残るまで自動的に別のトンネルに切り替わります。 また、より成功したインターフェイスが再びアクティブになった場合、ルーティングはそれに沿って行われます。



およそのルート更新時間は10秒です。この時間を短縮するには、ip ospf hello-intervalおよびip ospf dead-intervalパラメーターを変更できます。



すべてのサービスをスタートアップに追加することを忘れないでください。たとえば、OpenVPN構成ファイルはsrv-1050.confおよびcli-1050.confと呼ばれます。この場合、コマンドは次のようになります。



 systemctl enable openvpn@srv-1050 systemctl enable openvpn@cli-1050
      
      





ご清聴ありがとうございました。これは誰かに役立つと思います。



All Articles