apache 通过 HTTPS 隧道

Tunnel over HTTPS

提问by ephemient

At my workplace, the traffic blocker/firewall has been getting progressively worse. I can't connect to my home machine on port 22, and lack of ssh access makes me sad. I was previously able to use SSH by moving it to port 5050, but I think some recent filters now treat this traffic as IM and redirect it through another proxy, maybe. That's my best guess; in any case, my ssh connections now terminate before I get to log in.

在我的工作场所，流量拦截器/防火墙变得越来越糟糕。我无法通过端口 22 连接到我的家用机器，而且缺乏 ssh 访问让我很伤心。我以前可以通过将 SSH 移动到端口 5050 来使用它，但我认为最近的一些过滤器现在将此流量视为 IM 并通过另一个代理重定向它，也许吧。这是我最好的猜测；无论如何，我的 ssh 连接现在在我登录之前终止。

These days I've been using Ajaxterm over HTTPS, as port 443 is still unmolested, but this is far from ideal. (Sucky terminal emulation, lack of port forwarding, my browser leaks memory at an amazing rate...) I tried setting up mod_proxy_connecton top of mod_ssl, with the idea that I could send a CONNECT localhost:22 HTTP/1.1request through HTTPS, and then I'd be all set. Sadly, this seems to not work; the HTTPS connection works, up until I finish sending my request; then SSL craps out. It appears as though mod_proxy_connecttakes over the whole connection instead of continuing to pipe through mod_ssl, confusing the heck out of the HTTPS client.

这些天我一直在通过 HTTPS 使用 Ajaxterm，因为端口 443 仍然不受干扰，但这远非理想。（苏茨基终端仿真，缺乏端口转发的，我的浏览器泄漏内存以惊人的速度...）我试图建立mod_proxy_connect之上mod_ssl，用的想法，我可以发送CONNECT localhost:22 HTTP/1.1通过HTTPS请求，然后我会准备就绪. 可悲的是，这似乎不起作用；HTTPS 连接有效，直到我完成发送请求；那么 SSL 就失败了。看起来好像mod_proxy_connect接管了整个连接而不是继续通过管道mod_ssl，混淆了 HTTPS 客户端。

Is there a way to get this to work? I don't want to do this over plain HTTP, for several reasons:

有没有办法让它发挥作用？我不想通过纯 HTTP 执行此操作，原因如下：

• Leaving a big fat open proxy like that just stinks
• A big fat open proxy is not good over HTTPS either, but with authentication required it feels fine to me
• HTTP goes through a proxy -- I'm not tooconcerned about my traffic being sniffed, as it's ssh that'll be going "plaintext" through the tunnel -- but it's a lot more likely to be mangled than HTTPS, which fundamentally cannot be proxied

• 像这样留下一个巨大的开放代理很糟糕
• 大型开放代理也不适用于 HTTPS，但需要身份验证对我来说感觉很好
• HTTP 通过代理——我不太担心我的流量被嗅探，因为 ssh 将“明文”通过隧道——但它比 HTTPS 更容易被破坏，HTTPS 从根本上不能被代理

Requirements:

要求：

• Must work over port 443, without disturbing other HTTPS traffic (i.e. I can't just put the ssh server on port 443, because I would no longer be able to serve pages over HTTPS)
• I have or can write a simple port forwarder client that runs under Windows (or Cygwin)

• 必须在端口 443 上工作，而不会干扰其他 HTTPS 流量（即我不能将 ssh 服务器放在端口 443 上，因为我将不再能够通过 HTTPS 提供页面）
• 我已经或可以编写一个在 Windows（或 Cygwin）下运行的简单端口转发器客户端

Edit

编辑

DAG: Tunnelling SSH over HTTP(S)has been pointed out to me, but it doesn't help: at the end of the article, they mention Bug 29744 - CONNECT does not work over existing SSL connectionpreventing tunnelling over HTTPS, exactly the problem I was running into. At this point, I am probably looking at some CGI script, but I don't want to list that as a requirement if there's better solutions available.

DAG：已经向我指出了基于 HTTP(S) 的隧道 SSH，但它没有帮助：在文章的末尾，他们提到了错误 29744 - CONNECT 在现有的 SSL 连接上不起作用，阻止了通过 HTTPS 的隧道，正是我遇到的问题。在这一点上，我可能正在查看一些 CGI 脚本，但如果有更好的解决方案可用，我不想将其列为一项要求。

采纳答案by Alexander

Find out why the company has such a restrictive policy. It might be for a good reason.

找出为什么公司有这样的限制性政策。这可能是有充分理由的。

If you still find that you want to bypass the policy, you could write a small proxy that will listen on your server on port 443 and then, depending on the request, will forward the traffic either to your web server or to the SSH daemon. There are two catches though.

如果您仍然发现要绕过该策略，您可以编写一个小型代理，该代理将在端口 443 上侦听您的服务器，然后根据请求将流量转发到您的 Web 服务器或 SSH 守护程序。不过有两个问题。

1. To determine whether it's an HTTPS request or an SSH request, you need to try to read some data with a (small) timeout, this is because TLS/SSL handshakes start with the client sending some data, whereas the SSH handshake starts with the server sending some data. The timeout has to be big enough to delays in delivering the initial data from the client in the TLS/SSL handshake, so it'll make establishing SSH connections slower.

2. If the HTTP proxy in your company is smart, it'll actually eavesdrop on the expected TLS/SSL "handshake" when you CONNECTto port 443, and, when it detects that it's not an TLS/SSL handshake, it might terminate the SSH connection attempt. To address that, you could wrap the SSH daemon into an TLS/SSL tunnel (e.g., stunnel), but they you'll need to differentiate requests based on the TLS/SSL version in your client request to determine whether to route the TLS/SSL connection to the web server or to the TLS/SSL-tunneled SSH daemon.

1. 要确定它是 HTTPS 请求还是 SSH 请求，您需要尝试以（小）超时读取一些数据，这是因为 TLS/SSL 握手从客户端发送一些数据开始，而 SSH 握手从服务器开始发送一些数据。超时必须足够大，以延迟在 TLS/SSL 握手中从客户端传递初始数据，因此它会使建立 SSH 连接的速度变慢。

2. 如果您公司的 HTTP 代理是智能的，当您CONNECT访问 443 端口时，它实际上会窃听预期的 TLS/SSL“握手” ，并且当它检测到它不是 TLS/SSL 握手时，它可能会终止 SSH 连接试图。为了解决这个问题，您可以将 SSH 守护程序包装到 TLS/SSL 隧道中（例如，stunnel），但是您需要根据客户端请求中的 TLS/SSL 版本区分请求，以确定是否路由 TLS/SSL连接到 Web 服务器或到 TLS/SSL 隧道的 SSH 守护进程。

回答by Brian

You should be able to use iptables to forward ssh traffic from your work machines to ssh while all other machines attaching to your home server on port 443 get the Apache server.

您应该能够使用 iptables 将 ssh 流量从您的工作机器转发到 ssh，而在端口 443 上连接到您的家庭服务器的所有其他机器获得 Apache 服务器。

Try a rule like this:

试试这样的规则：

iptables -t nat -A PREROUTING -p tcp -s 111.111.111.111 --dport 433 -j REDIRECT --to-port 22

iptables -t nat -A PREROUTING -p tcp -s 111.111.111.111 --dport 433 -j REDIRECT --to-port 22

Where 111.111.111.111 is your office computer's ip address.

其中 111.111.111.111 是您办公室计算机的 IP 地址。

That all assumes you're running Linux >= 2.4, which you should be by now. It's been out for almost a decade.

这一切都假设您正在运行 Linux >= 2.4，您现在应该是。已经出来快十年了。

Documentation for iptables is at http://www.netfilter.org.

iptables 的文档位于http://www.netfilter.org。

回答by Brian

Set up OpenVPN 2.1 server at home, use port 443 (if you set up your home any HTTPS service at port 443, trigger OpenVPN's port-share option to handle both OpenVPN and HTTPS transactions at port 443; this feature is only available to non-Windows OS)

在家里设置 OpenVPN 2.1 服务器，使用端口 443（如果您在端口 443 设置您的家任何 HTTPS 服务，则触发 OpenVPN 的端口共享选项以在端口 443 处理 OpenVPN 和 HTTPS 事务；此功能仅适用于非视窗操作系统）

Then, set up your OpenVPN client on your laptop in road-warrior mode to access the OpenVPN server at home. You will be able to call home or anywhere you like within a secure VPN network you've created with OpenVPN. It is no longer required to use SSH for this purpose.

然后，在您的笔记本电脑上以公路战士模式设置 OpenVPN 客户端，以访问家中的 OpenVPN 服务器。在您使用 OpenVPN 创建的安全 VPN 网络中，您将能够给家里或任何您喜欢的地方打电话。不再需要为此目的使用 SSH。

回答by Huibert Gill

How about using 2 IP adresses on your machine?

在你的机器上使用 2 个 IP 地址怎么样？

Bind apache/https on one IP_1:443 and your sshd on the other IP_2:443?

在一个 IP_1:443 上绑定 apache/https，在另一个 IP_2:443 上绑定 sshd？

回答by 11855589966

Could you set up a middle man?

你能不能设置一个中间人？

Run a small/free/cheap instance in the cloud listening on 443 for SSH, then though that cloud instance tunnel to your home box on your favorite port - 22 or whatever.

在云中运行一个小型/免费/便宜的实例，在 443 上侦听 SSH，然后通过该云实例隧道连接到您最喜欢的端口 - 22 或其他端口上的家庭设备。

It'll add some latency I'm sure, but it solves the problem of leaving the original home setup intact.

我敢肯定，它会增加一些延迟，但它解决了保持原始家庭设置完好无损的问题。

回答by user48678

Since apache has no problem whatsoever with CONNECT when no SSL is involved, I turn off SSL features and I use stunnel to serve an https version of my site. This does not require any recompilation, and allows your site to serve https normally. So far, the cleanest workaround I know.

由于在不涉及 SSL 时 apache 对 CONNECT 没有任何问题，因此我关闭了 SSL 功能并使用 stunnel 来提供我网站的 https 版本。这不需要任何重新编译，并允许您的站点正常提供 https 服务。到目前为止，我所知道的最干净的解决方法。

See http://chm.duquesne.free.fr/blog/?p=281for details.

有关详细信息，请参阅http://chm.duquesne.free.fr/blog/?p=281。

回答by user48678

See:

看：

SSH Through or Over Proxy

通过或通过代理的 SSH

http://daniel.haxx.se/docs/sshproxy.html

http://daniel.haxx.se/docs/sshproxy.html

http://www.agroman.net/corkscrew/

http://www.agroman.net/corkscrew/

回答by Harley Holcombe

I think you'll have to find a port that you're not using currently that you can get out on, and listen on that. 443 is the obvious candidate, but you say that's not possible. What about mail (25, 110, 143), telnet (23), ftp (21), DNS (53), or even whois (43)?

我认为你必须找到一个你目前没有使用的端口，你可以出去，然后听听。443 是明显的候选，但你说那是不可能的。邮件 (25, 110, 143)、telnet (23)、ftp (21)、DNS (53) 甚至 whois (43) 呢？

回答by Robert Gould

I'm really sorry for being the Devil's advocate here, but if they are blocking ports at your work, its likely because they don't want people breaching security.

我真的很抱歉在这里成为魔鬼的拥护者，但是如果他们在您的工作中阻止端口，那可能是因为他们不希望人们破坏安全性。

Now if you get permission to open a tunnel from your boss, that's fine, but IF something happens, ANYTHING, and they figure out you have a tunnel, I can almost assure you, you'll become the scapegoat. So if I were you I'd not be opening tunnels at work if they are setting up firewalls against it.

现在，如果你从你的老板那里得到了打开隧道的许可，那很好，但是如果发生了什么事，任何事情，而且他们发现你有一条隧道，我几乎可以向你保证，你会成为替罪羊。因此，如果我是你，我就不会在工作中打开隧道，如果他们设置了防火墙。

回答by Zoredache

Proxy tunnel may be your answer

代理隧道可能是你的答案

http://proxytunnel.sourceforge.net/

http://proxytunnel.sourceforge.net/

lets say my ssh server is host.domain.tld and my works proxy server is 10.2.4.37

假设我的 ssh 服务器是 host.domain.tld 而我的作品代理服务器是 10.2.4.37

I would add this to my local ssh config

我会将它添加到我的本地 ssh 配置中

Host host.domain.tld ProxyCommand /usr/local/bin/proxytunnel -q -p 10.2.4.37:3128 -d %h:%p ProtocolKeepAlives 30

主机 host.domain.tld ProxyCommand /usr/local/bin/proxytunnel -q -p 10.2.4.37:3128 -d %h:%p ProtocolKeepAlives 30