При зверненні до GridFTP-сервера та успішної автентифікації при виконанні будь-які операції обміну (перегляд каталогу, завантаження файлів) клієнт підвисає на тривалий час, а потім видає помилку при утворенні каналу даних.

Дана проблема проявляється для будь-якої служби, що використовує у своєму складі GridFTP-сервер та знаходиться на сервері із приватною IP-адресою, з'єднання на який передаются через трансляцію IP-адреси призначення маршрутизатором на вході у мережу (Destination NAT, DNAT).

На разі це застосовно до CREAM CE, DPM, WMS, VOBOX.

При погодженні встановлення каналу передачі даних у пасивному режимі, GridFTP-сервер надсилає клієнтові внутрішню приватну IP-адресу замість реальної.

Протокол GridFTP, як і оригінальний FTP, використовує 2 TCP-з'єднання: одне для керування, а інше для безпосередньої передачі даних. З'єднання керування завжди ініціюється клієнтом, а з'єднання даних може в залежності від погодження ініціюватись як клієнтом (пасивний режим) так і сервером (активний режим). За замовчуванням, більшість GridFTP-клієнтів обирають пасивний режим, оскільки він дозволяє працювати у випадку, коли клієнт знаходиться за NAT-шлюзом і не має змоги приймати вхідні з'єднання. У цьому випадку сервер передає клієнту параметри нового з'єднання – як-то IP-адресу та TCP-порт. Проблема полягає в тому, що сервер, у загальному випадку, не має можливості визначити чи знаходиться він за NAT-шлюзом та реальну IP-адресу, з якої відбувається трансляція з'єднань на нього. Тому він передає у якості точки з'єднання адресу свого мережевого інтерфейса, яка у випадку NAT-трансляції належить до приватного діапазону адрес та не маршрутизується крізь Інтернет. Відповідно, клієнт не може під'єднатися до такої адреси, знаходячись зовні приватної мережі сервера. При зверненні із внутрішньої мережі ця проблема може і не проявлятись.

Пропоноване рішення полягає в тому, щоб заставити сервер думати, що з'єднання відбулося на зовнішньодоступну адресу, а не на внутрішню, що призведе до формування правильної адреси точки підключення каналу даних. Цього можна досягти за допомогою додавання додаткової IP-адреси на Loopback-інтерфейс та спеціального правила трансляції iptables.

1. Створіть конфігурацію вторинної адреси на Loopback-інтерфейсі. Для RedHat-подібних дистрибутивів достатньо створити файл /etc/sysconfig/network-scripts/ifcfg-lo:real приблизно такого змісту:

   DEVICE=lo:real
   IPADDR=a.b.c.d
   NETMASK=255.255.255.255
   ONBOOT=yes

   де у поле IPADDR вписати зовнішню IP-адресу, з якої виконуєтсья трансляція з'єднань на сервер.

2. Додати до конфігурації iptables правило, що “завертає” усі з'єднання іззовні на новостворений інтерфейс. Наводимо приклад секції *nat файлу /etc/sysconfig/iptables:

   *nat
   :PREROUTING ACCEPT [0:0]
   :POSTROUTING ACCEPT [0:0]
   :OUTPUT ACCEPT [0:0]
   -A PREROUTING -s ! 10.0.0.0/255.0.0.0 -p tcp -m tcp --dport 2811 -j DNAT --to-destination a.b.c.d
   COMMIT

3. Запустити мережевий інтерфейс та застосувати конфігурацію iptables:

   # ifup lo:real
   # service iptables restart

— Євген Слюсар 2012/06/11 13:36