四つのプロトコルファミリーは、ラックに残ったほぼすべての機器をカバーし、それぞれLinuxでは異なる形で失敗します。使うべきパッケージを決めるのは、遠端が公開しているポートと設定済みの提案であり、たまたま実行しているディストリビューションではありません。フォーラムの投稿に書かれたものを入れて、つながるまで編集する——そうやって午後が消えます。まず機器を読み、次にインストールし、最後に検証します。

遠端が公開しているものを記録する

パッケージマネージャーを開く前に、機器が期待するプロトコル、ポート、認証を書き出します。四つのファミリーが古い機器の大半をカバーし、下の表がその決定のすべてを一画面に示しています。

FamilyPortsLinux side
PPTPTCP 1723 plus GRE, IP protocol 47pppd with a peer file
L2TP/IPsecUDP 500, 4500, 1701NetworkManager plugin over strongSwan
IKEv1 aggressive with XAuthUDP 500native strongSwan connection
AnyConnect-style portalTCP 443openconnect with a TUN device

マニュアルと機器自身のファイアウォール規則は、ログインページに書かれたプロトコル名より信頼できます。IPsecをうたう機器がIKEv1しか話さないこともあり、誰も適用していないファームウェアが後からIKEv2を追加するかもしれません。データパスと設定ポートの両方を確認してください。古い機器と現代のネットワークが食い違うのはまさにそこです。この手順を誤ると、相手側が一度も持ったことのない機能に対してクライアントをデバッグすることになります。

PPTP:pppdを編集する前にGREを証明する

LinuxでのPPTPは起動するデーモンではなくpppdの呼び出しで、接続パラメータは呼び出されたときにpppdが読む名前付きのpeerファイルに置かれます。ディストリビューションは今もパッケージ化していますが、このプロトコルの既知の弱点のため機密性の要る用途には向きません。他に何も提供しない機器のためだけに厳密に残してください。クライアントが折衝している間にGREを観察し、推測ではなく短いキャプチャで確かめます。最も時間を浪費する失敗は認証ではなく、欠けているデータパスです。

pppd call branch-office
tcpdump -ni any proto gre -c 5

設定が完了してもリンクが一度もトラフィックを運ばないなら、資格情報に触れる前にGREの経路を疑ってください。クラウドのセキュリティグループにはプロトコル47の明示的な規則が必要で、一部のネットワークは目に見えるエラーもなく完全に遮断します。実際に使うネットワークからテストし、何でも許すラボから試さないことです。

L2TP/IPsec:合致する提案ひとつが十回の試行に勝る

デスクトップのダイアログではなくデーモンのログを読んでください。ダイアログは複数の異なる失敗をひとつのメッセージにまとめてしまうからです。NO_PROPOSAL_CHOSENエラーは第一フェーズのものです。クライアントがサーバーの受け付けない暗号化、ハッシュ、Diffie-Hellmanグループを提示しています。機器が何をサポートするかを列挙し、それに合う提案をひとつ書いてください。無作為な組み合わせはたいてい同じエラーを遅く生むだけです。デスクトップでは、strongSwanまたはLibreswanを下に置いたNetworkManager L2TPプラグインが実用的なクライアントです。

デスクトップのプラグインにとってひとつの意味を持つ提案文字列が、作業を渡すデーモンにとっては別の意味になることがあるので、編集している層に合った構文を保ってください。機器がトンネル秘密も要求する場合、それはIPsec鍵とは別の段階です。何かを入力する前に、インターフェースがどちらを尋ねているかを確認してください。

XAuthを用いたアグレッシブIKEv1と、ポータルの場合

FortiGate系の端点は通常、XAuthと構成モードのアドレスを伴うアグレッシブモードを求めますが、グラフィカルなプラグインがそれをまったく公開しないこともあります。ネイティブのデーモンなら対応でき、下のブロックはその設定の形であって完全なファイルではありません。提案の値についてはベンダーの最新ドキュメントを確認してください。

conn branch
    keyexchange=ikev1
    aggressive=yes
    leftauth=psk
    leftauth2=xauth
    leftsourceip=%config
    right=203.0.113.10

古いstrongSwanのリリースは、バージョン5がleftauth2=xauthを使うところでxauth=clientを使っていたため、コピーした断片は構文だけで失敗することがあります。TLSポータルでは、AnyConnectプロトコルを話すopenconnectがCiscoと大半の再ブランド製品を扱い、TUNデバイスとそれを設定する権限が必要です。ポータルアドレスはブラウザが表示するとおりに、機器が期待するパスも含めて渡し、その背後を試す前に割り当てられたアドレスを確認してください。インターフェースを事前に作っておけば、設定中の驚きをひとつ減らせます。

sudo ip tuntap add dev tun0 mode tun
sudo openconnect --protocol=anyconnect vpn.example.com

接続し、決まった順序で検証する

VPNマネージャーは同時にひとつだけ動かしてください。NetworkManagerのプロファイルと手動で起動したデーモンは経路とDNSを奪い合います。手動接続を試す前にプロファイルを落とし、古いトンネルインターフェースが残っていないことを確認します。そのうえでこの順に検証します。トンネルのアドレス、必要な唯一の内部ホストへの経路、名前解決、そして最後に実際のリクエストです。緑のアイコンが証明するのは認証だけで、それ以外ではありません。

ip -4 addr show tun0
ip route get 10.20.30.10
getent hosts app.internal

どこかの手順が失敗したら、次を試すのではなくそこで止めてください。壊れた経路の下流にあるDNSの失敗は何も教えてくれません。試す前に動作するプロファイルのコピーを保存してください。消した接続ファイルは失いやすく、作り直すのは面倒です。提案の値は機器の型番とファームウェア版と同じメモに残してください。そのメモが、筐体を入れ替えるときに移行と考古学の差を分けます。

関連記事