Розбіжності
Тут показані розбіжності між вибраною ревізією та поточною версією сторінки.
|
tech:kb0003 [2012/04/16 14:06] Євген Слюсар |
tech:kb0003 [2012/06/11 10:36] (поточний) |
||
|---|---|---|---|
| Рядок 1: | Рядок 1: | ||
| ====== KB0003 ====== | ====== KB0003 ====== | ||
| ===== Проблема ===== | ===== Проблема ===== | ||
| - | <code> | + | При зверненні до GridFTP-сервера та успішної автентифікації при виконанні будь-які операції обміну (перегляд каталогу, завантаження файлів) клієнт підвисає на тривалий час, а потім видає помилку при утворенні каналу даних. |
| - | mzg | + | |
| - | </code> | + | |
| ===== Застосовність ===== | ===== Застосовність ===== | ||
| Рядок 14: | Рядок 12: | ||
| ===== Пояснення ===== | ===== Пояснення ===== | ||
| + | Протокол GridFTP, як і оригінальний FTP, використовує 2 TCP-з'єднання: одне для керування, а інше для безпосередньої передачі даних. З'єднання керування завжди ініціюється клієнтом, а з'єднання даних може в залежності від погодження ініціюватись як клієнтом (пасивний режим) так і сервером (активний режим). За замовчуванням, більшість GridFTP-клієнтів обирають пасивний режим, оскільки він дозволяє працювати у випадку, коли клієнт знаходиться за NAT-шлюзом і не має змоги приймати вхідні з'єднання. У цьому випадку сервер передає клієнту параметри нового з'єднання -- як-то IP-адресу та TCP-порт. Проблема полягає в тому, що сервер, у загальному випадку, не має можливості визначити чи знаходиться він за NAT-шлюзом та реальну IP-адресу, з якої відбувається трансляція з'єднань на нього. Тому він передає у якості точки з'єднання адресу свого мережевого інтерфейса, яка у випадку NAT-трансляції належить до приватного діапазону адрес та не маршрутизується крізь Інтернет. Відповідно, клієнт не може під'єднатися до такої адреси, знаходячись зовні приватної мережі сервера. При зверненні із внутрішньої мережі ця проблема може і не проявлятись. | ||
| ===== Вирішення ===== | ===== Вирішення ===== | ||
| + | Пропоноване рішення полягає в тому, щоб заставити сервер думати, що з'єднання відбулося на зовнішньодоступну адресу, а не на внутрішню, що призведе до формування правильної адреси точки підключення каналу даних. Цього можна досягти за допомогою додавання додаткової IP-адреси на Loopback-інтерфейс та спеціального правила трансляції iptables. | ||
| + | |||
| + | - Створіть конфігурацію вторинної адреси на Loopback-інтерфейсі. Для RedHat-подібних дистрибутивів достатньо створити файл ''/etc/sysconfig/network-scripts/ifcfg-lo:real'' приблизно такого змісту: <code> | ||
| + | DEVICE=lo:real | ||
| + | IPADDR=a.b.c.d | ||
| + | NETMASK=255.255.255.255 | ||
| + | ONBOOT=yes</code>де у поле ''IPADDR'' вписати зовнішню IP-адресу, з якої виконуєтсья трансляція з'єднань на сервер. | ||
| + | - Додати до конфігурації iptables правило, що "завертає" усі з'єднання іззовні на новостворений інтерфейс. Наводимо приклад секції ''*nat'' файлу ''/etc/sysconfig/iptables'': <code> | ||
| + | *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</code> | ||
| + | - Запустити мережевий інтерфейс та застосувати конфігурацію iptables: <code> | ||
| + | # ifup lo:real | ||
| + | # service iptables restart</code> | ||
| + | --- //[[people:slu|Євген Слюсар]] 2012/06/11 13:36// | ||
