我有一个在webfaction上托管的django应用程序，它现在有一个静态/私有ip。
我们办公室的网络显然位于防火墙后面，AD服务器正在此防火墙后面运行。从网络内部我可以使用带有AD内部IP地址和端口389的python-ldap进行身份验证，并且一切正常。
当我将其移至托管网络服务器时，我更改已在防火墙上打开的IP地址和端口。为简单起见，我们打开的端口是389，但是验证请求总是超时。当登录webfaction并从shell运行python并查询ipaddress时，我得到webfactional的通用IP地址而不是我的静态ip。
当我尝试在django中进行身份验证时，是否会发生这种情况？请求来自运行python的底层IP地址，而不是防火墙所期望的静态IP？
我对所有这些网络和端口映射毫无头绪，所以任何帮助都将非常感谢！
希望有道理吗？
答案 0 :(得分：3)
我建议不要将防火墙上的端口直接打开到LDAP。相反，我会建议制作SSH隧道。这将在LDAP流量周围进行必要的加密。这是一个例子。
ssh -N -p 22 username@ldapserver -L 2222/localhost/389
这假设ssh服务器在ldap服务器的端口22上运行，并且可以从Web主机访问。它将创建从ldap服务器上的端口389到Web主机上的端口2222的隧道。然后，在Web主机上配置django应用程序，以认为LDAP服务器在localhost端口2222上运行。
答案 1 :(得分：0)
托管的django应用程序与内部AD之间存在相当多的组件。您将需要测试每个以查看它们之间的路径中的所有内容是否正确。
因此您的AD服务器位于防火墙后面。您的防火墙具有IP“a.b.c.d”，并且端口389上防火墙IP的所有流量都将转发到AD服务器。我建议您将此更改为防火墙上更高的随机端口，顺便说一下。那里少扫描。
通过shell访问，您可以测试是否可以访问您的网络。让您的防火墙管理员检查防火墙日志，同时尝试以下之一（或与python类似的东西）：
检查通往防火墙的路径（如果webfaction阻止此操作，这可能无效，否则您将看到您的流量将通过的主机列表 - 如果路径上有防火墙您将看到您的连接丢失，因为默认情况下在大多数防火墙上都会丢弃）：
tracert a.b.c.d
在端口389上telnet到你的防火墙ip（telnet测试将允许你的防火墙管理员在他的日志中看到连接尝试进入端口389.如果那些确实到达，这意味着外部comm应该工作得很好）：
telnet a.b.c.d 389
同样，您需要检查AD服务器是否收到这些请求（检查您的日志），并且还可以响应它们。也许你的AD服务器没有设置为与防火墙通信？