☰

LDAP へのリモート ポート転送がハングする

tag-icon • tag-icon ssh ssh-tunneling
LDAP へのリモート ポート転送がハングする

Windows マシン (ローカル)、Centos 7 VM (VM)、および VM 経由で通信する必要がある LDAP (LDAP) があります。

LOCAL は VM に ssh でき、LDAP と独立して通信できます。

VMはLOCALまたはLDAPと直接通信できません

私はLOCALで次のようなコマンドを実行しました

ssh -R 389:LDAP:389 VM

VM内では

curl ldap://localhost/...認証が提供され、ほぼ動作します。適切な応答が返されますが、接続がハングします。

なぜハングしているのですか。どうすれば修正できますか? VM は完全に制御できますが、LOCAL は部分的に制御できますが、LDAP は制御できません。通信するインフラストラクチャを制御できません。

私は、OpenShift クラスターを複数の VM に展開しており、OpenShift は特定の LDAP 経由で認証される必要があるため、これを実行できるようにしたいと考えています。現在の構成 (curl がハングする) では、LDAP との統合が機能していません。VM が通信できるネットワーク上で起動した LDAP Docker イメージと OpenShift を統合したところ、正常に機能したため、このハングが問題の原因であると考えられます。

LDAPを実行しているマシンであれば、

ssh -R 400:localhost:389 localhost

その時点で

curl ldap://localhost:400/...正常に動作します（ハングアップしません）

ちょっと不思議だ

答え1

問題は解決しました。curling 時のハングアップは、実際には curl と特定の LDAP 設定に関する一般的な問題です。

参考:

これは次の場合に発生します:

curl インストールで使用される LDAP バックエンドは openldap です。おそらく Debian の場合です。クエリは、紹介を返すサーバーに対して行われます。M$AD はその 1 つです :-( 外部 LDAP 構成により、自動紹介追跡が可能になります。curl で自動紹介追跡をサポートする簡単な方法はまだありません。回避策として、ldap 構成でこの機能を無効にすることをお勧めします (ldap.conf で "REFERRALS off")。これにより、ハングが解消されます。もちろん、これにより紹介からの結果も失われますが、現在の curl の状態では、いずれにしてもそれらは返されません。

詳細:https://curl.haxx.se/mail/lib-2016-01/0101.html

Openshift は、無関係なネットワークの問題により、ldap で動作しませんでした。

関連情報