SynologyでOpenVPNのハンドシェイクが失敗する？LAN転送を確認

ノートPCはTLSハンドシェイクが失敗したと報告するので証明書を作り直したくなりますが、その前に、もっと地味な質問をしてください。Synologyは実際にどのEthernetポートで待ち受けているのでしょうか？LANポートが二つあるNASにはアドレスが二つあり、DSMのVPN ServerパッケージはOpenVPNのリスナーをそのどちらか一方に結び付けます。ルーターが1194を別のアドレスへ転送すると、パケットはサービスに一切届かず、クライアントは交渉する相手を持ちません。

エラーの文言は、クライアントが最後に試したことではなく最初に狂ったことを書いているので、誤解を招きます。パッケージのページとルーターの規則を見比べる二分で決着します。

リスナーが結び付いているアドレスを見つける

DSMはポートをLAN 1とLAN 2と呼び、それぞれが別のアドレスとサブネットを持ちます。VPN Serverを開き、OpenVPNタブに示されたインターフェースを読み、次にコントロールパネルを開いて、DSMが同じインターフェースに持つIPv4アドレスを書き留めます。転送が名指すべきは、NASのホスト名ではなく、この二つの値です。

ケーブルを二本目に挿してもリスナーは二つにならない。両方のリンクが接続済みと表示されても、トラフィックを受け取るのは一方のアドレスだけであり、両方のインターフェースが同じサブネットにあると、二つのアドレスは保存前に誰も読み返さない一桁だけ異なります。

デーモンが実際に何に結び付いたかを示すのはSSHで見るソケットそのものだけで、設定ページの意図ではありません。

sudo netstat -anp | grep 1194

新しく追加するのではなく、既存の転送を編集する

一つの外部ポートに二つの規則があるとルーターは自由に選べるようになり、どちらを選ぶかはファームウェア更新や再起動で変わり得ます。既にある規則を開き、内部アドレスを変え、保存し、それからもう一度開いて値を読み返します。規則にサービスの名前を付けるのは、同じ転送が五つ並んだ一覧こそ間違ったものが生き残る道だからです。

external 1194/udp  ->  192.0.2.20:1194/udp

内部ポートは待ち受けポートと同じにし、プロトコルもそろえてください。UDP 1194が既定のリスナーで、TCPプロファイルはパッケージ側に独自のリスナーと、ルーター側に対応する転送を必要とします。UDPだけで待ち受けるサービスへTCPを転送しても、エラーではなく沈黙が返ります。

NASのアドレスがDHCPから来るなら、規則を保存する前に予約してください。リースが切れるとアドレスは再割り当てされ、転送は古い値を指したままになり、誰もNASに触れていない日にハンドシェイクが失敗し始めます。NAS側で静的設定にすれば同じ問題は解決しますが、アドレスがルーターのDHCP範囲の外にあることが条件です。

パケットがそもそも届くかどうかを証明する

まずNASでキャプチャを開始し、それからクライアントから接続して、出力の送信元アドレスを読みます。障害の後に開始したキャプチャは何も見えず、何も証明しません。

sudo tcpdump -i any -n udp port 1194

沈黙はトラフィックがサービスに届く前に死んだことを意味し、原因は内部アドレスの誤り、DSMファイアウォールでのポート閉塞、管理上ダウンしているインターフェースのいずれかです。出力にパケットがあれば転送は機能しており、残る不具合はネットワーク層より上にあり、はるかに狭い探索範囲になります。

キャプチャはパケットが届いたインターフェースも示し、その一点が、誤ったポートに向いた規則と起動していないポートに向いた規則を分けます。同じ試行の間にルーター自身のカウンターも見てください。キャプチャが空のままカウンターが動かなければルーターを指し、空のキャプチャでカウンターが動けば二つの機器の間の経路を指します。

パケットが届いたら、転送を責めるのをやめる

次の容疑者はプロファイルで、よくある理由は古さです。書き出した.ovpnファイルには書き出した時点の認証局と素材が入っているため、後で証明書を交換したパッケージは、古い写しを持ったままのクライアントを拒否します。

転送方式も明示的に確認する価値のある食い違いで、プロファイルとパッケージは別の場所で編集します。パッケージを切り替えずにプロファイルをUDPからTCPへ変えると、クライアントは存在しないリスナーを待ち、他のすべてと同じ汎用のハンドシェイク文言を報告します。ファイルのproto行を読み、次にサーバーページで選ばれたプロトコルを見て、それから初めて両者が一致していると結論してください。DSMのファイアウォール規則を読むのが三つ目の確認で、ローカルサブネットからのポートは許可するがインターネットからは許可しない規則は試験の後に残しやすく、台所からは通じて他のどこからも失敗する接続を生みます。

遠隔ユーザーが実際にたどる経路を試す

同じLANの内側のクライアントは転送に触れずにNASへ到達できるので、遠隔アクセスについては何も証明しません。Wi-Fiを切ったスマートフォンを使うか、ネットワークの外にいる人に頼み、その試行の間にルーターのカウンターを見てください。遠隔の試行が失敗してローカルの試行が成功するなら、転送かファイアウォールがまだ関係しています。

動いているうちに、外部ポート、内部アドレス、プロトコル、パッケージのインターフェース、プロファイル名と書き出し日という、動いている状態を記録してください。ハンドシェイクが再び失敗したら、そのメモと現在の設定の差が不具合であり、サービスが二つのポートのどちらを使うかを誰かが再発見する必要はありません。