Чи може хтось просто пояснити відмінності між пасивним режимом FTP (PASV) та розширеним пасивним режимом FTP (EPSV)?
Відповіді:
Єдина відмінність полягає в тому PORT/PASV, що вони обмежені IPv4 при EPRT/EPSVроботі з будь-яким мережевим протоколом (хоча на практиці використовується лише IPv6).
Стандартні PORT(активні) та PASV(пасивні) команди в протоколі управління FTP обмінюються інформацією адреси та порту як шість однобайтових десяткових знаків , з яких інший кінець повинен реконструювати чотирибайтну IP-адресу та двобайтовий номер TCP-порту.
PORT <address[4]>,<port[2]>
PORT 132,235,1,2,24,131
Але потім почали з’являтися інші протоколи. IPv4 збирався замінити на "IPng", у якому було досить багато конкуруючих пропозицій щодо заміни (OSI CLNP, TUBA, SIP, SIPP, CATNIP - в різні періоди історії), деякі з меншими, довшими і навіть змінними розмірами адреси хоста, поки нарешті не визначилися IPv6 з 16-байтними адресами.
Просто надсилання більшої кількості байтів не спрацювало б - сервери та клієнти не могли сподіватися, що вони знають правильний протокол, виходячи виключно з довжини адреси. (Наприклад, що робити, якщо у вас є один протокол з 16-байтною адресою + 4-байтним портом, інший з 12-байтною адресою + 12-байтний порт?)
Крім того - хоча це було менш важливим 20 років тому - в наші дні в Інтернеті є мільйони NAT-пристроїв , які перевіряють і керують з'єднаннями FTP-контролю, щоб "зовнішній" хост бачив лише глобальні адреси IPv4, навіть якщо "всередині" хост надіслав локальний RFC1918. Навіть без NAT, потужні брандмауери часто переглядають команди керування, щоб автоматично дозволити з'єднання даних без ручних правил.
Це в основному означає, що просто надсилання більшої кількості номерів PORTабо PASVгарантовано перерветься для багатьох людей. Можливо, деякі брандмауэры тихо неправильно трактують деякі байти адреси як порт, а тихо відкидають решту; інші можуть перервати з’єднання або просто вийти з ладу.
Щоб уникнути різних проблем, як описано вище, для підтримки протоколу в FTP потрібно було ввести нові команди.
У 1993 р. RFC 1639 (спочатку RFC 1545 ) ввів "довгу адресу" LPRTтаLPSV команди, які були на зразок PORT&, PASVале зі змінною довжиною адреси ; вони також включали ідентифікатор типу протоколу. (Синтаксис це не змінило - IPv6-адреса: порт просто надсилатиметься як 21 число, а не шість.)
LPRT <protocol>,<addr-length>,<address...>,<port-length>,<port...>
LPRT 4,4,132,235,1,2,2,24,131
LPRT 6,16,16,128,0,0,0,0,0,0,0,8,8,0,32,12,65,122,2,20,162
Однак це все ще не вирішило деяких проблем, наприклад, попросити сервер використовувати інший протокол, ніж для підключення управління. RFC також швидко застаріла; коли IPv6 вийшов лише через рік, його не можна було використовувати з LPRT, оскільки для нього не було призначено ідентифікатор протоколу LPRT (лише для різних ранніх пропозицій).
Щоб виправити це, RFC 2428 в 1998 р. Додав, EPRTа EPSVтакож "розширений порт" і "розширений пасив" , який також мав метод узгодження протоколу, який підтримує обидва кінці. Команди "розширені" також надсилають адреси в читаній людиною формі - для IPv6, це означає використання шістнадцяткових і двокрапкових позначень, а не ряд окремих десяткових чисел.
EPRT x<protocol>x<address>x<port>x
EPRT |1|132.235.1.2|6275|
EPRT |2|1080::8:800:200C:417A|5282|
На закінчення, підтримка IPv6 - єдина відмінність.
EPSVвідповідь не включає IP-адресу (що PASVвідповідає). Це дозволяє уникнути поширеної проблеми, коли сервер FTP, розташований позаду NAT, не знає, що це зовнішня IP-адреса, і плутає FTP-клієнта, надсилаючи йому його внутрішню адресу.
Різниця між активними та пасивними вже відповіла. Розширений пасивний (EPSV) є просто пасивним для IPv4 та IPv6, оскільки синтаксис відповіді на PASV був специфічним для IPv4, і тому нова команда була потрібна для IPv6. Те саме з EPTR проти PORT в активному режимі. Існує дещо інша поведінка з EPRT та EPSV в тому, що вони можуть містити тільки порт, а не IP та порт, як PORT і PASV. Таким чином, передача даних може здійснюватися лише між системами, які мають керуюче з'єднання. За допомогою PORT та PASV можна створити з'єднання даних між іншими системами (хоча це сьогодні вважається поганим дизайном та ризиком для безпеки).