ACME.challengeTests connects with the external domain and ip address - won't work behind secure routers #32
正在加载...
在新工单中引用
没有提供说明。
删除分支 %!s(<nil>)
删除分支是永久的。虽然已删除的分支在实际被删除前有可能会短时间存在，但这在大多数情况下无法撤销。是否继续？
There should be a way to pass the localhost as the host to test.
What happens when loopback is not enabled in the router, is that the whole greenlock-cli fails due to the test emitting an ECONNREFUSED.
And in most cases loopback should not be enabled in the router as it's a security hole allowing an attacker to spoof the packet's source.
You've got a compound problem there.
Either the router should be properly configured with hairpinning, or it should be properly configured without hairpinning. It should not be half configured.
Without hairpinning the request should work just the same as any other request - it goes out to external DNS servers, gets the external IP, makes a request out to the external IP that comes back in through the NAT of the router.
With proper hairpinning the request should be rewritten by the router and turned back on itself.
That said, you can update
/etc/hoststo get the localhost behavior that you desire... it just defeats the purpose of the test, which is to check that an outside source can properly get inside.Well, the point of “hairpinning” is to create a loopback that will circumvent the problem that occurs without it.
And without it, the packets that are meant for the machines behind the NAT are received by the router with the inbound ip being a local ip. Any secure enough router will drop those- as it can easily be an attack.
There’s a specific vulnerability that my CSP pointed me to, in order to convince me not to set this up- this is something unpublished yet. Should probably be published soon. And it looked bad enough to convince me anyone could fool the router by crafting the packets with simple tools.
Now in some configurations it may be complicated or undesired to modify
hostsfor this purpose. That’s why I think a flag in the configuration to toggle this off will be great!Also it’s common to use external tools in order to check for external ip address, external access etc. As internal access != external access.
I think that for the very least- it should not fail on this check, but throw a warning that will be used for diagnostics if the whole process fails.