使用映射到临时公有IP的内部接口运行Google计算实例…似乎不可能与外部ftp服务器build立活动的 ftp连接。 我看到另一个post，没有任何有关谷歌云活动模式连接的解决scheme。 在我看来，在本地和公共IP之间的NAT /端口转发规则中存在一些问题。
ftp xxx.xxx.xxx.xxx Connected to xxx.xxx.xxx.xxx. 220 Microsoft FTP Service Name (xxx.xxx.xxx.xxx:user): username 331 Password required for username. Password: 230-Welcome 230 User user logged in. Remote system type is Windows_NT. ftp> dir 500 Invalid PORT Command. ftp: bind: Address already in use ftp> 在“谷歌防火墙”，我打开了 xxx.xxx.xxx.xxx（ftp服务器地址）的所有端口。 服务器只接受活动模式连接（不是被动的）。
本地机器中没有防火墙规则。
ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1460 inet 10.132.0.3 netmask 255.255.255.255 broadcast 10.132.0.3 ether 42:01:0a:84:00:03 txqueuelen 1000 (Ethernet) RX packets 19215527 bytes 28123647876 (26.1 GiB) RX errors 0 dropped 0 overruns 0 frame 1 TX packets 10673733 bytes 814976332 (777.2 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1 (Local Loopback) RX packets 162643 bytes 54080619 (51.5 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 162643 bytes 54080619 (51.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
提前致谢！
我find了解决scheme！ 在谷歌云networking是不可能build立一个与外部FTP服务器的主动FTP连接。
The big problem is that when a client program is using network address translation to hide behind a routing device on an internal network, when using PORT the client tells a server on the external network to connect to an address on the client's internal network. Ie, from the example above: Client: PORT 192,168,1,2,7,138
解决scheme：
The solution depends from the network administrator of the client network to use high-quality network address translation software. Devices can keep track of FTP data connections, and when a client on a private network uses "PORT" with an internal network address, the device should dynamically rewrite the packet containing the PORT and IP address and change the address so that it refers to the external IP address of the routing device. The device would then have to route the connection incoming from the remote FTP server back to the internal network address of the client. Ie, from the example above we had: Client: PORT 192,168,1,2,7,138 When the packet containing this PORT reaches the routing device, it should be rewritten like this, assuming the external address is 17.254.0.26: Client: PORT 17,254,0,26,7,138 The remote server would then attempt to connect to 17.254.0.26:1930. The routing device in this example would then forward all traffic for this connection to and from the client address at 192.168.1.2:1930.
更多细节在这里
我不知道如果在谷歌环境是可能的这种解决scheme。
唯一的解决scheme谷歌云（现在）：黑客的FTP客户端（在我的情况下，这很简单：ruby）强制发送真正的外部networking地址在FTP端口命令。
欢迎其他更好的解决scheme！