Чому списки FTP зависають за VPN-шлюзом, який робить NAT

Вхід і PWD проходять, а LIST і RETR стають, коли NAT переписує лише заголовки. Подивіться, де має бути помічник FTP і як виправити пасивний режим.

Вхід працює, PWD працює, а потім LIST висить, доки клієнт не здасться або не перейде в інший режим даних. Цей поділ і є ознакою: керівне з'єднання до порту 21 здорове, а з'єднання даних будується з адреси або порту, до якого інша сторона не може дістатися. За VPN-шлюзом, який теж робить NAT, звичайний винуватець — команда FTP, у навантаженні якої вказано тунельну адресу на кшталт 10.8.0.6. Переклад заголовків ніколи не торкається цього значення.

Далі — звідки береться це значення і яка коробка має право його змінювати.

Ламається навантаження, а не тунель

FTP вміщує кінцеву точку даних усередині керівного потоку. В активному режимі клієнт надсилає PORT зі своєю адресою та портом, а сервер передзвонює на цю пару. У пасивному режимі сервер відповідає 227 з парою, і клієнт телефонує вже на неї.

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

Три режими, три навантаження

Таблиця нижче показує, якій стороні велено телефонувати, і що з цим може зробити NAT, який переписує лише заголовки.

Читайте останній стовпець як те, що відмовляє першим. В активному режимі на приватну адресу телефонує сервер, у пасивному — клієнт, а при FTPS навантаження зашифроване, тож проміжній коробці працювати ще важче.

ModeValue in the control streamWho dials whomHeader-only NAT leaves
Active (PORT)client address and portserver dials the clienta server dialing an unreachable tunnel address
Passive (227)server address and portclient dials the servera client dialing an address it cannot route to
FTPSthe same values, inside TLSas aboveciphertext, so no rewrite happens at all

Поставте помічника туди, де відбувається переклад

У Linux переписуванням навантаження займається помічник nf_conntrack_ftp. Він стежить за керівним з'єднанням, вивчає узгоджений порт, створює очікування для потоку даних і на машині з NAT переписує адресу та порт усередині навантаження. Він допомагає лише на пристрої, який перекладає адресу клієнта. Його завантаження на клієнті або на маршрутизаторі, який лише пересилає потік, нічого не змінює в сесії.

Ці три команди показують, чи є модуль, чи він під'єднаний і чи існує очікування, поки сесія відкрита:

modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftp

Завантажити модуль — не те саме, що його під'єднати. Ядра починаючи з 4.7 постачаються з net.netfilter.nf_conntrack_helper=0, тому помічник чекає явного правила, наприклад iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Якщо список очікувань залишається порожнім під час спроби передачі, перевіряти треба під'єднання, а не модуль.

Пасивний режим: скажіть серверу, що оголошувати

Пасивний режим легше зробити детермінованим, бо серверу можна сказати, що вписати у відповідь 227. У vsftpd це pasv_address разом із pasv_min_port і pasv_max_port; ProFTPD використовує MasqueradeAddress і PassivePorts. Задайте це першим, бо правильно оголошена адреса знімає потребу будь-що переписувати на тому боці.

Потім пропустіть рівно цей діапазон портів через шлюз, наприклад -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, щоб правило збігалося з тим, що оголошує сервер.

Два налаштування мають збігатися. Сервер, якому велено оголошувати 30000-30100, тоді як шлюз дозволяє 40000-40100, відмовляє найменш корисним чином: керівна розмова виглядає здоровою, а кожне з'єднання даних помирає. Порівняйте числа, перш ніж налагоджувати щось інше.

Дві ознаки відмови і що прибирає FTPS

Зависання на LIST вказує на перше з'єднання даних сесії, де мають працювати і переписування адреси, і очікування. Зависання на RETR після робочого LIST вказує на саму передачу, тобто на пасивний діапазон або MTU тунелю. Ця друга ознака не є проблемою навантаження, і налаштування помічника її не виправлять.

FTP поверх TLS прибирає навантаження, яке читає помічник. Проміжна коробка не може переписати значення PORT або PASV, яке не може розшифрувати, тож залишаються проксі, що завершує TLS, сервер, що оголошує доступну адресу в обмеженому діапазоні, або інший протокол передачі.

Короткий порядок перевірок

Рухайтеся від симптома назовні. Переконайтеся, що LIST відмовляє, поки PWD проходить, перехопіть адресу всередині навантаження PORT або 227 і спитайте, який пристрій перекладає цю адресу. Під'єднайте помічника там, поспостерігайте за списком очікувань під час однієї передачі, потім виправте пасивний режим на сервері та відобразіть діапазон у правилі шлюзу.

Тримайте відмову на шляху даних окремо від відмови під час масової передачі, бо вони ведуть до різних налаштувань.

Схожі статті