Запуск экземпляра Google Compute Instance с внутренним интерфейсом, сопоставленным с временным общедоступным IP-адресом ... кажется невозможным установить активный соединение ftp с внешним сервером ftp. Я видел другой пост без каких-либо решений о подключении в активном режиме из облака Google. На мой взгляд, есть проблема в правилах NAT / переадресации портов между локальным и публичным IP.
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
Заранее спасибо!
Я нашел решение! В облачной сети Google невозможно установить активное соединение 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. I.e., from the example above:
Client: PORT 192,168,1,2,7,138
Решение:
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. I.e., 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.
Подробнее Вот
Я не знаю, возможно ли такое решение в среде Google.
Единственное решение, найденное для облака Google (на данный момент): взломать ftp-клиент (в моем случае это просто: ruby), принудительно отправив реальный внешний сетевой адрес в команде ftp PORT.
Приветствуются другие лучшие решения!