防火墙的目标地址转换和源地址转换

遇到一起防火墙故障,对防火墙的工作原理和目标地址转换、 源地址转换有了进一步的了解,记录于此。

结果说在前面

网络结构非常简单:外网-防火墙-内网。内网中架有网站,在外网使用域名访问。 内网中机器需要上外网,也需要用域名互访。 在这种情况下,地址转换规则应当这样配:

  • 外网访问内网,只需要做目标地址转换,不需要做源地址转换。
  • 内网通过域名访问内网,除了做目标地址转换,还必须做源地址转换。

上面第一条有一种“例外”情况,就是网关配置错误的情况,比如我们遇到的: 内网6有 2 块网卡,都配置了同一网段的内网地址,并且每块网卡都配置了网关。 由于是同一网段,所以两个网关是一样的。 在这种情况下,外网访问也必须做源地址转换, 否则内网能收到请求,但处理结果无法返回外网,外网看到的结果是没有回应。

防火墙数据包转换发送原理

为什么会这样?这要从防火墙的原理说起。 上面的外网访问内网,正常处理过程应该是这样的:

  1. 防火墙收到外网访问请求数据包,格式中包含【防火墙外网IP 外网用户IP】
  2. 防火墙进行目标地址转换,数据包变成【内网IP 外网用户IP】
  3. 内网服务器收到请求,进行处理,返回结果数据包【外网用户IP 内网IP】, 由于目标地址是外网IP,所有经过路由,此数据包被发向网关(防火墙)
  4. 针对返回数据包,防火墙做目标地址转换的反操作, 数据包变成【外网用户IP 防火墙外网IP】
  5. 数据包发回请求用户。

刚才说到的“例外”情况,问题就出在步骤 3,内网服务器返回结果数据包中, 内网IP 不是防火墙指向的那个 IP,而是这太内网服务器的另一个 IP 地址, 也就是说内网服务器通过网卡1接受了请求,却从网卡2发送返回数据。 这样的数据包到了防火墙之后,目标地址转换的反操作会失败(内网IP 不一致), 所以数据依然会通过防火墙发给用户,但却是一个新的 TCP 会话/连接, 无法和原先的用户请求包对应。 结果就是新的数据包到了用户那里,不知道是给谁的, 而用户原先发送的请求,也一直“收不到”回应数据包。 外在表现就是用户看到请求发送成功,却没有回应。

在这种情况下,如果同时做了源地址转换是能够通的,处理过程如下:

  1. 防火墙收到外网访问请求数据包,格式中包含【防火墙外网IP 外网用户IP】
  2. 防火墙进行目标地址转换,数据包变成【内网IP 外网用户IP】, 进行源地址转换,数据包变成【内网IP 防火墙/网关IP】
  3. 内网服务器收到请求,进行处理,返回结果数据包【防火墙/网关IP 内网IP】, 由于目标地址仍然是防火墙/网关IP,所以防火墙能够找到相应的连接, 会接受数据包并进行处理。
  4. 针对返回数据包,防火墙 做源地址转换的反操作,数据包变成【外网用户IP 内网IP】, 做目标地址转换的反操作, 数据包变成【外网用户IP 防火墙外网IP】(R)
  5. 数据包发回请求用户。

可以看到,即使(R)操作失败,由于防火墙已经将内网服务器返回数据包和 防火墙接收的外网用户请求连接成功对应, 结果数据包的目标地址也成功转换成了外网用户IP, 所以数据能够成功发回请求用户,并和用户请求会话/连接相对应。

从另外一个角度看,外网访问做双向地址转换虽然可行,但有一个缺点, 就是数据包到达内网服务器时,外网用户IP 被转换成了防火墙/网关IP, 这样内网中的应用程序就无法获取外网用户的真实IP了, 只能看到请求来自防火墙/网关IP。

内网通过域名访问内网

上面的都理解之后,内网通过域名访问内网为什么必须要做双向转换就清楚了。 问题同样出在接受请求的服务器处理完,发送返回数据包时。

内网1 通过域名访问内网6,在没有做源地址转换时的情形:

  • 由于是通过域名访问,所以请求数据通过防火墙转发给内网6, 用户IP是内网地址(这是关键)
  • 内网6处理完毕发送结果数据包,返回数据包的目标地址就是内网1的地址 由于同在一个子网内,数据包会通过交换机直接发向内网1,不过防火墙

问题产生了,在内网1 上,请求数据直接发向防火墙,返回数据直接来自内网6, 不对应,又是一宗没有回应数据包的情形。

如果同时做了源地址转换,问题就能够解决。因为内网1 的请求数据在通过防火墙时, 用户地址(内网1 IP)会被转换成防火墙/网关IP, 返回数据包也就会发往防火墙/网关IP,再被防火墙转换发回 内网1, 不存在内网1 和内网6 的直接对话, TCP 数据包也能对应上,访问就没有问题了。

不同品牌、类型的防火墙工作机制也许不同,但原理都差不多。 不专业的地方,还请过路仙人不吝赐教。

通过代理使用 GitHub

Git 是非常好用的开发工具,越来越离不开了。 如果要与他人合作项目,GitHub 是很好的平台。 但如果身处受限网络,要管理 GitHub 上的项目, 还是要费一番周折的。

GitHub 网页访问应该不用说了,工具多得是。 我要说的是对项目进行管理,比如 push/pull 操作等。

最简单的方式是通过 https_proxy,比如:

export https_proxy=http://127.0.0.1:8087

然后将仓库地址改为 HTTP 方式。

虽然简单,但有一点不方便,就是进行写操作时, 比如 push ,会需要手工输入用户名和密码, 而不是 GitHub 常用的证书自动认证。

更好的方法还是走 ssh 协议代理, 这需要一个软件 connect-proxy。 Ubuntu 下可以通过 Apt 安装, ArchLinux 下要通过 AUR 安装( 包地址 )。

先要有 Socks 代理,通常,可以使用无限制网络的 VPS, 然后使用 ssh 打个隧道:

# Native ssh
ssh -D 127.0.0.1:22888 -CfNg domain.tld -o ControlPath=/tmp/ssh-22888-domain.tld
# OR
# 使用 authssh 更方便
autossh -M 0 -D 127.0.0.1:22888 -CfNg domain.tld -o ControlPath=/tmp/ssh-22888-domain.tld

可以 telnet localhost 22888 检查通不通。

然后,在 $HOME/.ssh/config 中添加一段:

Host github.com
    # On Ubuntu
    ProxyCommand /usr/bin/connect-proxy -S 127.0.0.1:22888 %h %p
    # OR
    # On ArchLinux
    ProxyCommand /usr/bin/connect -S 127.0.0.1:22888 %h %p

-S 参数如果换成 -H ,就是使用 http 代理, 效果应该和上面的简单方法一样。

最后,将仓库地址改为 SSH 方式。 现在,本地 GitHub 仓库中 push 操作就正常了,简单测试一下 GitHub 登录:

$ ssh -T git@github.com
Hi fwolf! You've successfully authenticated, but GitHub does not provide shell access.

Apple Mail 邮件太多不下载问题的解决

Apple Mail version3.6(936)

原先拿到这个 mac 本本的时候,由于家中网速比较慢,收发邮件比较折磨人,而我又属于对邮件依赖较重的,所以专门申请了个新的 gmail 帐号,专门用在这个机器上,把邮件下载到本地便于处理(平时个人邮件都是自己发给自己的 N 个邮箱共享),顺便体验下 Apple Mail 软件。

Apple Mail 倒算是中规中矩,按下不表,中间有一段时间没怎么用这台 mac,而这个专用 gmail 帐号里面堆积的邮件应该也不少了,简单估计有几百封吧。终于,等到我想用的那一天,突然发现它不下载新邮件了。

逐项检查,系统和软件工作正常,网络正常,gmail 登录进去肯定是有新邮件,而且 pop 设置正常。所有的东西都没有动过,并且原先刚设置好这个帐号的时候,邮件下载都是正常的。Command+0 打开 Activity 窗口监视──连接、登录、查找新邮件、退出,貌似正常,但完全无视我邮箱中赫然在目的新邮件哪。

纯属无意中翻看 gmail 的在线帮助,其实对这类帮助并不报太大希望的,因为一般上面只有一些常规问题的答案,我的问题比较蹊跷,八成没有。帮助里面专门有针对 Apple Mail 3.0 Troubleshooting,列了几个问题,对照我的情况,逐个回答如下:

  • Have you recently used Gmail’s POP service with this client and address?
  • --> Yes, this address just worked recently
  • When are you encountering problems?
  • --> Downloading
  • Does your client display an error?
  • --> No, my mail client does not show an error
  • Downloading issues
  • --> Some or all messages don’t download

然后帮助给了4个解决方法,其中第2条是亮点:

Try enabling recent mode in your POP client by replacing 'username@gmail.com'
in the Username field of your POP client settings with 'recent:username@gmail.com',
and uncheck the box next to Remove copy from server after retrieving a message
in your Advanced POP client settings. Recent mode fetches the last 30 days of mail,
regardless of any other factors. If you don't Leave messages on server your 
messages will be moved to Trash after download.

看仔细了,在邮件帐户前面加上 recent:,只下载最近30天的邮件,这个以前没听说过,从之,我的邮件又愉快的下载了。至于30天以前的邮件如何下载,我是不需要了。至于为什么会这样,还真不明白是 gmail 这里有限制,还是 Apple Mail 无法读取30天以前邮件的邮件头导致无法下载,希望有明白人指点一二。

附 gmail 帮助截图为据:

Gmail帮助中关于Apple Mail的Troubleshooting

Flash 无法修改设置的问题

Adobe flash player settings

这个怪怪的问题也不是一天两天了,就是 flash 设置窗口,或者当 flash 游戏需要使用本地存储空间时,自动弹出的设置窗口,这个窗口无法用鼠标点击,用键盘 TAB 键能在各部分之间游荡但还是无法调整设置,基本上就卡死在这里了。

遇到这种情况,可以访问这个链接:http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html,注意链接中并不是图片,而是实际的设置调整组件。比如刚才说的访问本地资源需要确认的问题,在这里设置成Never Ask Again,同网站的资源就再也不会弹出窗口导致 flash 卡死了。

Ubuntu 9.04, Firefox 3.0.13, Flash Player 10.0 r32.

参考:

压缩网页图片

不压不知道,一压吓一跳,大部分图片几乎都能在近似无损的情况下压缩掉 65% 原始大小左右,如果指明有损压缩,比如 jpeg 的 85 %,还能更小。

Smush.it

smushit 现在已经属于 Yslow 的一部分了,可以通过 firefox 插件使用,也能在线用,缺点就是你的图片必须能够从公网访问。

可以压缩各种图片,按照官方的解释,它会尝试各种工具和算法,找到最优的方式。因此,smushit 是一种很安全的压缩工具,几乎看不到差别,就是用起来麻烦些。

imagemagick

不同的图片格式有各自的特点,比如 gif 善于存储颜色较少的图片,也是动画图片的首选;png 善于存储能够矢量化的图片,jpg 则善于存储颜色、图片变化都比较多的图片。根据不同的图片特点,进行类型转换,有时能收到不错的效果。

图片 convert 之后,还可以利用其它工具进一步压缩,不过效果不大了。

另附一个转换图片类型之后,批量替换模板中调用文件名的脚本:

grep logo.gif * -R | awk '{print $1}' | sed 's/://' | xargs -I '{}' sed -i 's/logo.gif/logo.jpg/' '{}'

jpegoptim

这是今天刚发现的好东西,ubuntu 源中有,主要可以用它去除 jpg 图片文件当中的 comment exif IPTC 等无用标记,我测试的情况压缩率比 smushit 略低一点点。由于能够通过命令行使用,所以易用性更强。

一般我喜欢用 --strip-all 参数去除所有无用内容,实际压缩之前可以用 -n 参数预测一下压缩率(默认直接压缩覆盖源文件了),24bit Adobe 类型的图片基本上都能够压缩掉 65% 原始大小,碰到 24bit JFIF 这种类型的图片一般压不动,但带上有损压缩参数比如 -m85之后,依然能够达到较理想的压缩率,并且图片损失效果不明显。

遇到无法压缩的图片、压缩后体积反而增大的图片会自动跳过,很贴心。

基本上,有了上面三种方式,就能够处理大部分网页图片了。

Curl奇怪的403错误

自己用的小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之所以特殊,也不排除是这种原因吧。