Linux（Debian 8）ルーターでは、iproute2を使用してソースルーティングが構成されます。 FORWARDおよびINPUT \ OUTPUTパケットの両方が正しくルーティングされます。 ラウンドロビンデフォルトゲートウェイを有効にした後、OpenVPNクライアントの接続時に問題が発生し始めました。 このケースは非常にまれなので、見つけた解決策をこのメモの形でコミュニティと共有することにしました。
次のコマンドを使用して、ラウンドロビンのデフォルトゲートウェイを有効にします。
ip route add default scope global nexthop via $GW1 dev $IF1 weight 1 nexthop via $GW2 dev $IF2 weight 1 nexthop via $GW3 dev $IF3 weight 1
実際には、ルーティングはもう少し複雑ですが、これらの詳細は最終出力に大きな影響を与えないため、省略できます。 ご覧のとおり、重みが同じ3つのゲートウェイが交互に使用されています。 OpenVPNサーバーはすべてのインターフェースをリッスンし、UDPプロトコルで動作します。 理論的には、このような設定で動作するはずですが、クライアントはこのサーバーへの接続を停止しました。 インターフェイスのいずれかを介して接続した場合、同じSSHが引き続き機能しますが。 理由はUDPプロトコルにあると想定できますが、DNSサーバーを確認したところ、UDP要求への応答が正しいインターフェイスから返されていることがわかりました。 したがって、ラウンドロビンゲートウェイをオンにすると、ソースルーティングはOpenVPNに対してのみ壊れるので、その中で理由を探す必要があります。
接続するとき、ハンドシェイクを開始する前に、パスワードを使用したログインが要求され、認証に成功します。それ以上の接続は発生せず、クライアント接続失敗ログには有用な情報は表示されません
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) TLS Error: TLS handshake failed SIGUSR1[soft,tls-error] received, process restarting MANAGEMENT: >STATE:1451454269,RECONNECTING,tls-error Restart pause, 2 second(s)
一部のクライアント（実際には1人だけに会った）がログで興味深いものを受け取ったことは興味深い。 最初のインターフェイス$ IP1に接続すると、ログは次のようになりました。
Incoming packet rejected from [AF_INET]$IP1:1194[2], expected peer address: [AF_INET]$IP2:1194 (allow this incoming source address/port by removing --remote or adding --float) Incoming packet rejected from [AF_INET]$IP1:1194[2], expected peer address: [AF_INET]$IP3:1194 (allow this incoming source address/port by removing --remote or adding --float)
そして円で。 さらに、クライアント上でサーバーのIPアドレスが$ IP2に置き換えられた場合、応答パケットは$ IP2からではなく、$ IP1および$ IP3から送信されます。 つまり クライアントがどのIPに接続しても、同じアドレスからの応答はありません 。 かなり奇妙な振る舞い。 繰り返しますが、ソースから他の接続へのルーティングは正しく機能します。
トラブルシューティングの過程で、プロトコルをTCPに変更すると、接続が成功し、UDPでの作業の実装でその理由を探さなければならないことが判明しました。 その後、解決策が見つかりました-OpenVPNのサーバー側のMultihomeパラメーター。 man openvpn multihomeパラメーター：
-マルチホーム
マルチホームUDPサーバーを構成します。 このオプションは、サーバーに複数のIPアドレス（たとえば、複数のインターフェイス、またはセカンダリIPアドレス）があり、-localを使用して1つにバインドしない場合に使用する必要があります。
特定のアドレスのみ。 このオプションは、クライアントが通信しているアドレスからUDP応答パケットが常に送信されるように、パケットパスに追加のルックアップを追加します。 これはすべてでサポートされていません
プラットフォーム、さらに処理が追加されるため、デフォルトでは有効になっていません。
注：このオプションは、UDPサーバーにのみ関連します。
注2：複数のIPv4アドレスを持つLinuxマシンでIPv6 + IPv4デュアルスタックバインドを行う場合、カーネルのサポートが欠落しているため、3.15より前のカーネルではIPv4アドレスへの接続が正しく機能しません
IPv4マップの場合（ただし、一部のディストリビューションはこれを以前のカーネルバージョンに移植しています）。
理由は、UDPプロトコルを使用したOpenVPNサーバーの動作原理にあります。 マルチホームオプションは、udpパケットに追加の処理を追加します。これにより、要求が到着したアドレスからの応答パケットの送信が保証されます。 具体的には、OpenVPNのソースを調べた後に何が起こるかがわかります。 したがって、OpenVPNのラウンドロビンデフォルトゲートウェイを正しく動作するように設定するときは、TCPプロトコルを使用するか、UDPを使用するときにマルチホームパラメーターを追加する必要があります。