web-dev-qa-db-ja.com

StrongSwanを使用しているVPNサーバー「一致するピア構成が見つかりません」-それはどういう意味ですか？

VPN用のpptpdサーバーを備えたUbuntuを実行しているAWSサーバーと、異なる認証情報を持つ多くのクライアントがあります。それは素晴らしい働きをします。しかし、どうやら私はもうそれを使用することになっていないようです、私はipsecを使用することになっています。ライブサーバーで実行する前に、まずUbuntu 16.04を実行しているローカルコンピューターでこれを試しています。

私が見つけた唯一の関連するチュートリアルはこれでした。他の人は、私が「ロードウォリアー」をセットアップしているときのサイト間VPNや他のオペレーティングシステム用であるように見えます。あるいは、一般的に、これを毎日行うシステム管理者を対象としているようです（誰も私にこれを行うためにお金を払っていません） ）。

https://raymii.org/s/tutorials/IPSEC_vpn_with_Ubuntu_16.04.html

チュートリアルでは、「使いやすい」ため、認証に証明書を使用するように指示されています。

私は指示に従いました。サーバーは「冬」と呼ばれ、192.168.3.144にあります。クライアントは「charly」と呼ばれ、192.168.3.138にあります。私はこのようなサーバー証明書を生成しました：

ipsec pki --pub --in private/vpnHostKey.der --type rsa | ipsec pki --issue --lifetime 730 --cacert cacerts/strongswanCert.der --cakey private/strongswanKey.der --dn "C=CN, O=Winter, CN=winter.lan" --san winter --san 192.168.3.144 --san @192.168.3.144 --flag serverAuth --flag ikeIntermediate --outform der > certs/vpnHostCert.der

Syslogは次のことを示しています。

May 30 20:34:36 winter charon: 03[CFG] adding virtual IP address pool 2002:25f7:7489:3::/112
May 30 20:34:36 winter charon: 03[CFG]   loaded certificate "C=CN, O=Winter, CN=winter.lan" from 'vpnHostCert.der'
May 30 20:34:36 winter charon: 03[CFG]   id 'winter.lan' not confirmed by certificate, defaulting to 'C=CN, O=Winter, CN=winter.lan'

「Sudoipsecstatusall」の接続セクションは次のようになります。

Connections:
 IPSec-IKEv2:  %any...%any  IKEv2, dpddelay=300s
 IPSec-IKEv2:   local:  [C=CN, O=Winter, CN=winter.lan] uses public key authentication
 IPSec-IKEv2:    cert:  "C=CN, O=Winter, CN=winter.lan"
 IPSec-IKEv2:   remote: uses public key authentication
 IPSec-IKEv2:   child:  0.0.0.0/0 === dynamic TUNNEL, dpdaction=clear

次のようなクライアント証明書を生成しました。

cat Charly-public.der | Sudo ipsec pki --issue --lifetime 730 --cacert /etc/ipsec.d/cacerts/strongswanCert.der --cakey /etc/ipsec.d/private/strongswanKey.der --dn "C=CN, O=Winter, [email protected]" --san "mat@winter" --san "[email protected]" --outform der > Charly-cert.der

...そして今、macOS 10.13.4を実行しているMacbookを使用して接続しようとしています。 MacintoshVPNを次のように構成します。

...そして認証設定で作成した証明書を与えます。

接続しようとすると、エラーメッセージなしですぐに失敗します。サーバーログ：

May 30 20:53:15 winter charon: 06[CFG] looking for peer configs matching 192.168.3.144[[email protected]]...192.168.3.138[192.168.3.138]
May 30 20:53:15 winter charon: 06[CFG] peer config match local: 0 (ID_RFC822_ADDR -> 6d:61:74:40:77:69:6e:74:65:72:2e:6c:61:6e)
May 30 20:53:15 winter charon: 06[CFG] peer config match remote: 1 (ID_IPV4_ADDR -> c0:a8:03:8a)
May 30 20:53:15 winter charon: 06[CFG] ike config match: 28 (192.168.3.144 192.168.3.138 IKEv2)
May 30 20:53:15 winter charon: 06[CFG] no matching peer config found

これが左右の設定です：

mat@winter:~$ Sudo grep -E 'left|right' /etc/ipsec.conf
    left=%any
    leftid=winter.lan
    leftsubnet=0.0.0.0/0
    leftcert=vpnHostCert.der
    leftsendcert=always
    right=%any
    rightsourceip=10.42.42.0/24,2002:25f7:7489:3::/112
    rightdns=8.8.8.8,2001:4860:4860::8888

私の本当の質問は、「192.168.3.144 [mat @ winter] ... 192.168.3.138 [192.168.3.138]に一致するピア構成を探す/一致するピア構成が見つからない」とはどういう意味ですか？マッチングがどのように機能するのか、どの値が受け入れられるのか、どの値がクライアントから送信されているのか、クライアント側とサーバー側でどのように制御するのかがわかりません。そして、各セクションが何を表しているのか、その行を解析する方法がわかりません。

ありがとう！

これは以下で正しく答えられましたが、理解した用語で私が間違ったことの説明です。 tl; dr：左IDは、DNのCNとしてだけでなく、SANとして証明書に含まれている必要があります。

サーバー証明書とクライアント証明書の2つの証明書を接続して、2つの当事者が相互に信頼できるようにするという考え方です。どちらの証明書も認証局（「CA」）によって署名されており、両方の当事者がCA公開鍵を持っています。お互いの証明書が同じCAによって署名されていることを両者が認識した場合、両者は満足します。問題は、着信クライアント接続が特定のサーバー証明書に接続しようとしていることをStrongSwanに認識させることです。証明書を1つだけ構成したので、これは簡単に思えます。しかし、StrongSwanはより複雑なセットアップ用に設計されています。

重要なコンポーネントは、ipsec.confで構成された「leftid」です。 StrongSwanでは、任意の数の個別のVPNを構成できます。それぞれのVPNは、異なるleftidによって区別されます。クライアントが接続すると、この名前のVPNを要求します。私の場合、これは「リモートID」の下のVPN設定で構成されています。次に、サーバーが証明書を送信することを期待し、その証明書は、同じVPN名/左ID /リモートIDとして自身を識別する必要があります。

そのため、StrongSwanにはleftidの証明書が必要です。 ipsecを使用してサーバー証明書を生成します。 「C = CN、O = Winter、CN = winter.lan」のようなコンポーネントの長い文字列である「DistinguishedName」（「DN」）を指定します。サブジェクト代替名（「SAN」）をいくつでも指定できます。サーバーが起動すると、「leftid」および「leftcert」構成が読み込まれます。 DNまたはSANのいずれかでleftidを見つけようとします。

トリックは次のとおりです。leftidが見つからない場合は、leftidを破棄し、代わりにDN全体を使用します。これは次のようになります。

May 30 20:34:36 winter charon: 03[CFG]   id 'winter.lan' not confirmed by certificate, defaulting to 'C=CN, O=Winter, CN=winter.lan'

つまり、VPNの名前は「winter.lan」ではなくなり、「C = CN、O = Winter、CN = winter.lan」という名前になります。クライアントが接続したい場合は、「winter.lan」ではなく、その名前を要求する必要があります。名前が一致しない場合は実行しても意味がないため、これを行うのは理にかなっています。クライアントはwinter.lanに接続できますが、サーバーがその証明書を送信すると、クライアントが要求したものと一致せず、クライアントは接続を中止します。一方で、Macintoshにその左利きを要求するように説得する方法がないので、これを行うのは本当に残念です。

私がフォローしていたチュートリアルの大きな問題は、使用する左IDが「vpn.example.org」であり、サーバー証明書を生成するために提案されたipsecコマンドで、これはDNでのみ使用され、SANとして追加されないことです。 「winter.lan」でそれを行うと失敗します。 IDが証明書と一致しません。

May 31 21:32:00 winter charon: 05[CFG]   loaded certificate "C=CN, O=Winter, CN=winter.lan" from 'vpnHostCert.der'
May 31 21:32:00 winter charon: 05[CFG]   id 'winter.lan' not confirmed by certificate, defaulting to 'C=CN, O=Winter, CN=winter.lan'

これは、leftidもSAN with --sanとして指定した場合にのみ機能します。チュートリアルでは、「leftid =が証明書のCNと同じであることを確認する必要がある」とさえ述べています。彼らが私とは異なるバージョンのstrongswanを使用しているかどうか、または何が問題なのかはわかりません。

文字列「C = CN、O = Winter、CN = winter.lan」が文字列「winter.lan」といつどこで一致するかが明確でないため、さらに混乱が生じます。これは、これらの識別子にも「タイプ」が添付されており、一致する必要があり、タイプは通常ログに表示されないことが原因である可能性があります。

とにかく、注意すべき重要なことは、サーバーの起動時に「証明書によって確認されていない」行です。それが修正されるまで、クライアントとの接続をわざわざ試みないでください。

vpnubuntu-16.04strongswan
2
Matthew Exon

証明書に追加したsubjectAltName拡張機能の1つは[email protected]ですが、leftid=mat@winterを構成しました。これが一致しないため、ローカルIDは証明書のサブジェクトDN（つまり、C=HK, O=Winter, CN=mat@winter）にフォールバックします。これは、クライアントによって提案されたリモートID（looking for peer configs matching 192.168.3.144[mat@winter]）と一致しません。

したがって、[email protected]を構成し、それに応じてクライアント構成のリモートIDを変更するか、完全なサブジェクトDNをクライアントのリモートIDとして構成します（ただし、一部のIKEv2クライアントは実際にはそれをサポートしていません。

更新された構成では、winter.lanがsubjectAltNameとして含まれている必要があります。サブジェクトDNのCN相対DNとは照合されません。そのため、サーバー証明書を発行するときに、明示的に--san winter.lanを追加する必要があります。

構成されたローカルIDがローカル証明書のいずれのIDとも一致しない場合（サブジェクトDNまたはsubjectAltNamesのいずれか-タイプも一致する必要があることに注意してください）、サブジェクトDNがIDとして使用されます。構成がロードされると、ログに適切なメッセージ（id 'mat@winter' not confirmed by certificate, defaulting to 'C=HK, O=Winter, CN=mat@winter'など）があります。これは、構成されたConnectionsセクションのipsec statusallの出力にも表示されます。 IPとIDが一覧表示されます。したがって、構成したIDが、認証中にIKEデーモンが実際に使用するIDであることを確認してください。

looking for peer config...ログメッセージのコンポーネントは非常に単純です。例：192.168.3.144[mat@winter]...192.168.3.138[192.168.3.138]：

  • 192.168.3.144：IKE_SAのローカルIPアドレス（=レスポンダー/サーバーのIP）
  • [mat @ winter]：イニシエーター/クライアント（IDr）によって提案されたレスポンダー/サーバーIDは、構成されているIDと一致する必要があります（leftid）
  • 192.168.3.138：IKE_SAのリモートIPアドレス（=イニシエーター/クライアントのIP）
  • [192.168.3.138]：イニシエーター/クライアント（IDi）によって提案されたイニシエーター/クライアントIDは、サーバーで構成されているリモートIDと一致する必要があります（rightid、デフォルトは％any、構成されていない場合）

比較されるIDのタイプ（FQDNとUSER_FQDNまたはKEY_IDなど）も一致する必要があることに注意してください（IDはログで同じに見える場合があり、たとえばipsec statusallでもタイプが異なる場合があります）。この比較（タイプを含む）の詳細は、cfgの ログレベル が3に増加した場合にのみログに記録されます。

IDは2つの点で重要です。 1つは、特定の構成を選択できることです。そのため、IDrペイロードで特定のIDを送信することにより、クライアントはその特定のIDでサーバーに接続することを望んでおり、サーバーはそのIDに一致する構成を選択します。ペイロードはオプションであり、一部のクライアント（Windowsクライアントなど）はペイロードを送信しません。これにより、サーバーは適切と思われる構成を選択できます。クライアントIDについても同じことが言えます。これにより、サーバーが特定の構成に一致しない場合に切り替えることができます（ただし、デフォルトのrightid =％anyを使用すると、クライアントIDは構成を選択するときは無視されます-しかし、それはクライアント証明書によって確認される必要があります。

次に、IDは、有効な証明書を持っている人だけが好きなIDで自分自身を認証するのを防ぐために重要です。たとえば、クライアントにCA "X"以外のCAがインストールされていて、特定のIDを強制しない場合（通常はサーバーのホスト名と一致するように作成されます）、クライアントはこれらのいずれかによって発行された証明書を受け入れますCAは、そのID /ホスト名用に特別に発行されたものだけではありません（CA "X"が特定のサーバーIDを強制しない場合に信頼される唯一のCAである場合、サーバー証明書として別のクライアント証明書を受け入れることもあります）。クライアントにも同じことが言えます。クライアント「Y」に特別に発行された証明書を使用して、クライアント「Y」がクライアント「Z」として自分自身を認証することは望ましくありません。これは、rightid設定が異なる複数の接続定義がある場合に特に重要です。クライアントIDに基づいてVPN経由で異なるネットワークにアクセスできるようにするための異なるサブネットまたは仮想IP範囲。

私がフォローしていたチュートリアルの大きな問題は、使用する左IDが「vpn.example.org」であり、サーバー証明書を生成するために提案されたipsecコマンドで、これはDNでのみ使用され、SANとして追加されないことです。

はい、何らかの理由で、TLDが異なる2つの無関係なSAN（.comと.net）を証明書に追加します。

チュートリアルには、「leftid =が証明書のCNと同じであることを確認する必要があります」とさえ書かれています。彼らが私とは異なるバージョンのstrongswanを使用しているかどうか、または何が問題なのかはわかりません。

StrongSwanのバージョンには依存しませんが、クライアントに依存します。リモートIDを送信しない場合、サーバーは完全なサブジェクトDNをIDとして使用する構成を自由に選択できます。その場合、サーバーから返されたときにそのIDを受け入れるかどうかは、クライアント次第です。したがって、強制したいリモートID（サーバーのFQDNなど）をサーバーから送信されたDNのCNと一致させるクライアントは問題ありません。 Windowsクライアントはこれを行いますAppleクライアントも可能性があります（ただし、macOSの一部のバージョンでも一致するSANが必要です）。ただし、クライアントとしてのstrongSwanは、構成されたリモートIDが完全に一致する必要はありません。サーバーから返されるID（およびそのタイプ）。strongSwanがリモートIDを送信しない特別なクライアント構成（rightid =％vpn.example.com）があります。また、構成されたIDをサーバー証明書内のすべてのIDと照合します。これにより、クライアントはFQDNをIDとして適用でき、サーバーは、そのFQDNがサーバー証明書にsubjectAltNameとして含まれている限り、完全なサブジェクトDNで自身を識別します。

文字列「C = CN、O = Winter、CN = winter.lan」が文字列「winter.lan」といつどこで一致するかが明確でないため、さらに混乱が生じます。これは、これらの識別子にも「タイプ」が添付されており、一致する必要があり、タイプは通常ログに表示されないことが原因である可能性があります。

これは主に、strongSwanがDNの一部に対してIDを照合しないためです。ただし、前述のように、一部のクライアントはそれを実行します（少なくとも、CNに対してFQDNを照合します）。

とにかく、注意すべき重要なことは、サーバーの起動時に「証明書によって確認されていない」行です。それが修正されるまで、クライアントとの接続をわざわざ試みないでください。

そのログメッセージを確認するか、ipsec statusallの出力が意図した構成と一致しているかどうかを確認することは間違いなく良い考えです。

また、クライアントがno matching peer config foundに接続できない場合は、looking for peer configs...ログメッセージにリストされているIPとIDをipsec statusallに構成されている接続のIPとIDと比較してください。

3
ecdsa