Archive

Posts Tagged ‘tunnel’

Curl奇怪的403错误

July 1st, 2009 Fwolf 4 comments

自己用的小PHP应用,使用curl抓网页下来处理,为了穿墙方便,使用Privoxy作为代理,便于选择哪些网站使用proxy、哪些不用。但今天却遇到了奇怪的问题,访问google baidu这些网站居然都返回403错误,而访问其他的一些网站没事,如果设置为不使用proxy则都能正常访问。

难道google baidu就不让用proxy连接么?显然不可能,所以打开curl的信息输出(curl_setopt($this->mSh, CURLOPT_VERBOSE, 1);)看看,得到以下结果:

*   Trying 127.0.0.1... * connected
* Connected to 127.0.0.1 (127.0.0.1) port 8118 (#0)
* Establish HTTP proxy tunnel to www.baidu.com:80
> CONNECT www.baidu.com:80 HTTP/1.0
Host: www.baidu.com:80
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Proxy-Connection: Keep-Alive

< HTTP/1.0 403 Connection not allowable
< X-Hint: If you read this message interactively, then you know why this happens ,-)
< 
* The requested URL returned error: 403
* Received HTTP code 403 from proxy after CONNECT
* Closing connection #0
... Failed.

可以看到proxy服务器工作正常,的确是baidu返回了403错误,但原因肯定还在我这边。终于,从网上(1of2, 2of2)得到了点启发──我使用的是proxytunnel而非proxy。

在代码中,有这么一句:

	curl_setopt($this->mSh, CURLOPT_HTTPPROXYTUNNEL, true);
	curl_setopt($this->mSh, CURLOPT_PROXY, $phost);

php文档中没有详细说明,不过man curl中有详细解释,两者都是代理,proxytunnel(-p参数)允许其他协议通过http代理传输,而proxy(-x参数)则只能走http协议。所以我猜测,google baidu的服务器和curl的proxytunnel不和,所以返回403。

禁用掉上面2行代码的第一句后,curl访问恢复正常。

比较奇怪的是,几种操作系统下还不一样,一台MAC OSX就要显式的禁用proxytunnel才可以,curl版本:

$ curl --version
curl 7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Protocols: tftp ftp telnet dict ldap http file https ftps 
Features: GSS-Negotiate IPv6 Largefile NTLM SSL libz 

而另外一台ubuntu则完全不受影响,怎么都能用,curl版本:

$ curl --version
curl 7.18.2 (i486-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.10
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz 

MT主机上的centos也没事,curl版本:

$ curl --version
curl 7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Protocols: tftp ftp telnet dict ldap http file https ftps 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz 

看来不完全是curl版本问题,MAC OSX的确与众不同啊。

还有一个原因也会导致curl返回403错误,如果设置了:

	curl_setopt($ch, CURLOPT_NOBODY, true);

则需要紧跟着设置:

	curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'GET');

不然会因为http服务器不允许 HEAD 命令而返回403错误。参考:Trouble with a cURL request in PHP。MAC OSX上curl之所以特殊,也不排除是这种原因吧。

Related posts

Categories: Develop, Internet, PHP Tags: , , , , , ,

用ssh打通反向隧道,内网也可对外提供服务

July 10th, 2008 Fwolf 2 comments

一般正规一点的网络环境,大多是这样的:防火墙后分为内网和中立区(DMZ),并且内网和DMZ虽然都能访问外网,互相却是无法直接访问的。内网和DMZ的区别就是,来自外网的访问,都通过防火墙上的规则映射到DMZ里的服务器上,而内网一般是不允许这样的。

现在需要解决的问题就是,在防火墙只能给DMZ开端口,内网和外网不可直接互访的情况下,如果让内网的机器对外提供服务。

ssh是很神奇的,使用它创建的隧道,可以起到代理的作用,数据流的方向是:

本机 -> 隧道 -> 外网

应用到我们的问题中,如果把隧道反过来,就是:

外网 -> DMZ -> 隧道 -> 内网

这就需要用到ssh的反向隧道,它在服务器上打开一个监听端口,这个端口的访问会被隧道传输到本地,结果再通过隧道传到服务器上,从监听端口返回给客户。这样,在我们的应用中,内网机器通过外网访问DMZ服务器,创建ssh反向隧道,就能够对外提供服务了。当然,防火墙上要将相应端口映射到DMZ的服务器上。

比如,在内网登录DMZ服务器:

ssh -R 8082:localhost:82 fwolf@svr5.tld -o ControlPath=/tmp/ssh_svr5_reverse_tunnel

这样,访问DMZ服务器svr5的8082端口,就是在访问本机的82端口。之所以带上-o ControlPath,是为了和其它访问svr5的进程使用不同的master模式(如果不是第一次创建这个master,而是使用了原来的连接的sockts,肯定就不会创建隧道了)。

有几个问题还需要注意一下:

  • 如果DMZ上监听端口小于1000的话,就必须用root用户登录DMZ服务器,比如root@svr5.tld
  • DMZ服务器上的sshd必须开启GatewayPorts选项,在文件/etc/ssh/sshd_config中加入GatewayPorts yes
  • 记得不要idle,参考中有在服务端设置的方法。
  • 如果放在其它脚本,比如/etc/rc.local中执行的话,除了配置自动登录,还可以带上-fN参数,放到后台去。

参考

Update @ 2008-07-25

注意,由于使用了反向隧道,所以ssh隧道实际作用相当于一个代理,访问的来源也自然就都成了127.0.0.1,如果同时还启用了denyhosts,千万记得要把本机地址127.0.0.1放入白名单/etc/hosts.allow,不然就会成为其他登录失败的牺牲品(失败的登录,其来源也成了loopback的地址):

ssh_exchange_identification: Connection closed by remote host
Fatal error: Lost connection with the server

没办法,为了网络通道的畅通,只能牺牲一部分安全性了。

Related posts