FTP passive mode-এ firewall-এর কারণে listing আটকে যায় কেন

FTP-তে লগইন হলেও directory listing কেন আটকে যায়

Firewall-এর কারণে FTP passive mode কাজ করে না, কারণ FTP একটি নয়, দুটি TCP connection ব্যবহার করে। Port 21-এর connection-এ login এবং command যায়। তাই username ও password গ্রহণ করা হয় এবং firewall সঠিক মনে হয়। এরপর প্রথম ls-এর জন্য অন্য একটি port-এ দ্বিতীয় connection প্রয়োজন হয়। Firewall-এ সেই connection-এর জন্য কোনো অনুমতি নেই। তাই timeout না হওয়া পর্যন্ত client অপেক্ষা করতে থাকে।

সমাধান হলো data connection-এর জন্য একটি নির্দিষ্ট port range নির্ধারণ করা এবং একই range অনুমোদন করে firewall rule যোগ করা। NAT (network address translation)-এর পেছনে থাকা server-কে সঠিক address প্রচার করার জন্য আরও একটি setting প্রয়োজন। আগে connection tracking helper এই কাজ স্বয়ংক্রিয়ভাবে করত। এখন আর করে না। পুরোনো কোনো guide অনুসরণ করার আগে এর কারণ জানা গুরুত্বপূর্ণ।

নিয়ন্ত্রণ চ্যানেল এবং ডেটা চ্যানেল

FTP (file transfer protocol) RFC 959-এ নির্ধারিত হয়েছিল এবং NAT ও stateful firewall-এর আগের প্রযুক্তি। একটি session TCP port 21-এ একটি control connection খোলে এবং পুরো session জুড়ে সেটি খোলা রাখে। Command-গুলো plain text হিসেবে পাঠানো হয়। Reply তিন অঙ্কের code এবং একটি text line হিসেবে ফিরে আসে। এই connection-এ কখনো file content বহন করা হয় না।

প্রতিটি data-এর জন্য আলাদা TCP connection তৈরি হয়: একটি directory listing-এর জন্য (LIST), প্রতিটি download-এর জন্য একটি (RETR), এবং প্রতিটি upload-এর জন্য একটি (STOR)। এটি একবার খোলা হয়, ব্যবহার করা হয় এবং বন্ধ হয়ে যায়। Authentication সম্পূর্ণভাবে control channel-এ হয়। তাই data path নষ্ট হলে লক্ষণ সব সময় একই: login সফল হয়, তারপর সংযোগ আটকে থাকে। Client যদি 230 reply দেখিয়ে listing-এর সময় থেমে যায়, তাহলে সমস্যা data channel-এ, credentials-এ নয়।

Active mode: সার্ভার ক্লায়েন্টের কাছে সংযোগ স্থাপন করে

Active mode-এ ক্লায়েন্ট একটি port নির্বাচন করে, সেটিতে listen করে এবং server-কে জানায় কোথায় সংযোগ করতে হবে:

PORT 192,168,1,50,195,80

প্রথম চারটি সংখ্যা ক্লায়েন্টের IP address। শেষ দুটি সংখ্যা port-কে দুইটি byte হিসেবে প্রকাশ করে: 195 * 256 + 80 = 50000। এরপর server নিজের port 20 থেকে ক্লায়েন্টের port 50000-এ data connection খোলে।

ক্লায়েন্টের দৃষ্টিতে এই connection inbound এবং unsolicited। তাই ক্লায়েন্টের firewall এটি বাতিল করে। ক্লায়েন্ট যদি home router-এর পেছনে থাকে, তাহলে PORT command-এ থাকা address-টি private address, যেখানে server আদৌ পৌঁছাতে পারে না। FTP কাজ না করার যে reputation পেয়েছে, তার মূল কারণ Active mode।

প্যাসিভ মোড: ক্লায়েন্ট উভয় সংযোগ খোলে

প্যাসিভ মোডে ডেটা সংযোগের দিক পরিবর্তিত হয়। ক্লায়েন্ট PASV পাঠায় এবং সার্ভার নিজের একটি address ও port দিয়ে উত্তর দেয়:

227 Entering Passive Mode (203,0,113,10,195,80)

একই encoding ব্যবহার করা হয়েছে। তাই ক্লায়েন্ট 203.0.113.10-এর port 50000-এ সংযোগ করে। এখন ক্লায়েন্টই উভয় সংযোগ খোলে। এ কারণেই প্যাসিভ মোড client-side NAT-এর মধ্য দিয়েও কাজ করে এবং বর্তমান প্রায় সব ক্লায়েন্ট প্রথমে এটি অনুরোধ করে।

সমস্যাটি দূর হয়নি; শুধু অন্য জায়গায় গেছে। এখন unsolicited inbound connection আপনার সার্ভারে আসে, এমন একটি high port-এ যা প্রতিটি transfer-এর সময় পরিবর্তিত হয়। সেই firewall আপনার নিয়ন্ত্রণে, তাই সমস্যাটিও এখন আপনার।

EPSV (extended passive mode, RFC 2428) একই ধারণা ব্যবহার করে, তবে এর reply আরও সরল:

229 Entering Extended Passive Mode (|||50000|)

এতে কোনো address নেই। ক্লায়েন্ট control connection-এর জন্য ইতিমধ্যে ব্যবহৃত address পুনরায় ব্যবহার করে। এ কারণেই এটি IPv6-এর মাধ্যমে কাজ করে এবং NAT-সংক্রান্ত একটি সম্পূর্ণ bug class দূর করে। curl-এর manual অনুযায়ী, curl সাধারণত EPSV-এর আগে PASV চেষ্টা করে। port এখনও runtime-এ নির্ধারিত হয়, তাই EPSV আপনার firewall rules-এ কোনো পরিবর্তন আনে না।

কেন একটি সাধারণ firewall rule data channel অনুমোদন করতে পারে না

কারণ rule লেখার সময় port number এখনও নির্ধারিত হয়নি। প্রতিটি transfer-এর জন্য server আলাদা port বেছে নেয়। ডিফল্ট অবস্থায় রেখে দিলে, vsftpd pasv_min_port এবং pasv_max_port-কে 0 হিসেবে নথিভুক্ত করে, অর্থাৎ “যেকোনো port ব্যবহার করুন”; তাই data connection 1023-এর বেশি যেকোনো port-এ আসতে পারে। sudo ufw allow 21/tcp শুধু control channel অনুমোদন করে, আর কিছু নয়। ফলে login সফল হয়, কিন্তু listing কাজ করে না। Linux-এ service কীভাবে একটি নির্দিষ্ট port-এ listen করে এবং listening socket কীভাবে কাজ করে, তা এখনও অস্পষ্ট হলে Linux-এ port ও listening socket কীভাবে কাজ করে এই পটভূমি ব্যাখ্যা করে।

Stateful firewall connection track করে। Kernel একটি বিদ্যমান connection-এর সঙ্গে সম্পর্কিত নতুন connection-কে RELATED হিসেবে অনুমোদন করতে পারে। FTP-এর ক্ষেত্রে এর জন্য এমন কিছু প্রয়োজন, যা control stream পড়ে 227 বা PORT line থেকে port বের করবে। ডিফল্টভাবে এমন কিছু কাজ করে না।

FTP connection tracking helper আর সমাধান নয়

কার্নেল মডিউল nf_conntrack_ftp-এর দিকেই পুরোনো গাইডগুলো নির্দেশ করে। এটি plaintext control channel পড়ে, ঘোষিত port খুঁজে বের করে এবং একটি expectation নিবন্ধন করে। ফলে কোনো rule-এ সেই port উল্লেখ না থাকলেও data connection অনুমোদিত হয়। ওই গাইডগুলো লেখা হওয়ার পর থেকে 4টি বিষয় পরিবর্তিত হয়েছে।

Automatic helper assignment বন্ধ আছে এবং বর্তমান kernel-এ এটি আর চালু করা যায় না। Kernel 2016 সালে এটি ডিফল্টভাবে বন্ধ করে। এরপর Pablo Neira Ayuso-এর commit "netfilter: remove nf_conntrack_helper sysctl and modparam toggles" (August 2022) switch-টি সম্পূর্ণ সরিয়ে দেয় এবং জানায় যে "users now have to rely on explicit conntrack helper configuration via ruleset." nf_conntrack_helper sysctl Linux 5.19-এ আছে, কিন্তু Linux 6.0 থেকে আর নেই। Kernel-এর conntrack sysctl documentation-এও এটি আর তালিকাভুক্ত নয়। শুধু module load করলেই কোনো কাজ হয় না।

আপনি আপনার kernel-এর ধরন পরীক্ষা করতে পারেন। sysctl net.netfilter.nf_conntrack_helper চালান। sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_helper: No such file or directory উত্তর পাওয়া মানে kernel-এ চালু করার মতো automatic helper assignment আর নেই। এর বদলে কোনো সংখ্যা পেলে আপনি 6.0-এর আগের kernel ব্যবহার করছেন। Switch-টি এখনও আছে এবং এর default হলো 0।

Firewall front end-গুলোও এটি deprecated করেছে। Ubuntu 24.04-এর man ufw-framework, /etc/default/ufw-এর IPT_MODULES line সম্পর্কে বলে: "Unconditional loading of connection tracking modules (nf_conntrack_*) in this manner is deprecated"। এটি আরও জানায় যে helper rules "must be managed in via the RULES FILES"। firewalld firewalld.conf-এ AutomaticHelpers-কে "Deprecated. This option is ignored and no longer used." হিসেবে document করেছে। এখন helper যুক্ত করতে হলে হাতে CT target ব্যবহার করে explicit rule লিখতে হয়। নিচের fix-এর তুলনায় এটি বেশি কাজের এবং TLS চালু করলেই কাজ বন্ধ করে। Ubuntu-এ iptables এবং nftables-এ ওই rules আসলে কোথায় থাকে তা ব্যাখ্যা করা হয়েছে।

TLS এই পদ্ধতির কার্যকারিতা শেষ করে দেয়। Helper control channel-কে text হিসেবে পড়ে কাজ করে। সেই channel encrypt করলে helper ciphertext দেখতে পায়, তাই port খুঁজে বের করতে পারে না। এর কোনো সমাধান নেই এবং থাকা উচিতও নয়। আপনার control channel পড়তে সক্ষম middlebox আপনার password-ও পড়েছে।

সার্ভারে একটি প্যাসিভ পোর্ট রেঞ্জ ঘোষণা করুন

প্রতিটি FTP সার্ভারকে আপনার পছন্দমতো একটি নির্দিষ্ট রেঞ্জ থেকে প্যাসিভ পোর্ট বেছে নেওয়ার নির্দেশ দেওয়া যায়। অপশনের নামগুলো ভিন্ন হতে পারে, তাই আপনি যে সার্ভারটি চালাচ্ছেন তার ডকুমেন্টেশন দেখে নিন।

vsftpd-এর ক্ষেত্রে, /etc/vsftpd.conf-তে:

pasv_enable=YES
pasv_min_port=30000
pasv_max_port=30099

pasv_enable-তে ডিফল্টভাবেই YES থাকে। দুটি পোর্ট অপশন ডিফল্টভাবে 0-এ সেট করা থাকে, যা উপরে বর্ণিত "যেকোনো পোর্ট ব্যবহার করার" আচরণ নির্দেশ করে। sudo systemctl restart vsftpd দিয়ে এটি প্রয়োগ করুন, তারপর systemctl status vsftpd চালিয়ে নিশ্চিত করুন যে সার্ভিসটি পুনরায় চালু হয়েছে। vsftpd কোনো কনফিগারেশন লাইন পার্স করতে না পারলে তা উপেক্ষা না করে বরং স্টার্ট হওয়া বন্ধ করে দেয়। তাই রিস্টার্ট ব্যর্থ হলে, journalctl -u vsftpd -n 20 ফাইলটি পড়ে দেখুন যে সেখানে আপনার দেওয়া অপশনটির লাইনে কোনো 500 OOPS: ত্রুটি আছে কি না।

ProFTPD-এর ক্ষেত্রে, proftpd.conf-তে:

PassivePorts 30000 30099

ProFTPD-এর ক্ষেত্রে এখানে কোনো ডিফল্ট মান নেই: এই ডিরেক্টিভটি না থাকলে কার্নেল পোর্ট বেছে নেয়। ProFTPD-এর ডকুমেন্টেশনে আরও বলা হয়েছে যে, আপনার দেওয়া রেঞ্জে কোনো পোর্ট খালি না থাকলে সার্ভার কার্নেল দ্বারা নির্ধারিত পোর্টে ফিরে যায় এবং একটি মেসেজ লগ করে। তাই রেঞ্জ খুব ছোট হলে তা মাঝে মাঝে ব্যর্থ হয়, যা সঠিকভাবে নির্ণয় করা বেশ কঠিন। 1024 বা তার বেশি, অর্থাৎ নন-প্রিভিলেজড পোর্টগুলো ব্যবহার করুন।

Pure-FTPd একটি ফ্ল্যাগ গ্রহণ করে, -p first:last, যা man pure-ftpd-তে "প্যাসিভ-মোড ডাউনলোডের জন্য প্রথম থেকে শেষ পর্যন্ত শুধুমাত্র এই রেঞ্জের পোর্টগুলো ব্যবহার করুন" হিসেবে বর্ণিত হয়েছে। এটি "pure-ftpd-কে প্যাকেট ফিল্টারের সাথে আরও সামঞ্জস্যপূর্ণ করে তোলে"। প্যাকেজড বিল্ডগুলো সাধারণত এই ফ্ল্যাগটিকে একটি কনফিগারেশন ফাইলে রাখে, তাই অনুমান না করে আপনার ডিস্ট্রিবিউশনের নিজস্ব ডকুমেন্টেশন দেখে ফাইলের নাম নিশ্চিত করুন।

আপনার কতগুলো পোর্ট প্রয়োজন? প্রতি চলমান ডেটা কানেকশনের জন্য একটি। একটি বন্ধ TCP পোর্ট পুনরায় ব্যবহারের আগে কয়েক মিনিট TIME_WAIT অবস্থায় থাকে, তাই আপনার প্রত্যাশিত সর্বোচ্চ ব্যবহারের চেয়ে কয়েক গুণ বেশি পোর্ট বরাদ্দ রাখুন। অল্প কয়েকজন ব্যবহারকারীর জন্য একশটি পোর্ট যথেষ্ট, তবে একটি ব্যস্ত পাবলিক সার্ভারের জন্য আরও অনেক বেশি প্রয়োজন। vsftpd এক্ষেত্রে ProFTPD-এর চেয়ে কম নমনীয়: এর সোর্স কোড রেঞ্জের ভেতর থেকে কয়েকটি র‍্যান্ডম পোর্ট চেষ্টা করে, এবং যদি সবগুলোই ব্যস্ত থাকে তবে এটি রেঞ্জের বাইরের কোনো পোর্ট ধার না করে 500 OOPS: vsf_sysutil_bind দিয়ে সেশনটি শেষ করে দেয়। যেকোনো সার্ভারেই, রেঞ্জ খুব ছোট হলে তা আপনার সবচেয়ে ব্যস্ত সময়ে ফাইল ট্রান্সফার ব্যাহত করবে।

রেঞ্জটি কোথায় থাকা উচিত? প্রথমে sysctl net.ipv4.ip_local_port_range চালান। একটি সাধারণ Ubuntu বক্সে এটি 32768 60999 দেখায়, যা কার্নেল আউটগোয়িং কানেকশনের জন্য বরাদ্দ করে। এই উইন্ডোর ভেতরে কোনো প্যাসিভ রেঞ্জ থাকলে তা এমন আউটবাউন্ড কানেকশনের সাথে সংঘর্ষ ঘটাতে পারে যা ইতিমধ্যে পোর্টটি ধরে রেখেছে, তাই রেঞ্জটি এর নিচে রাখুন। ডিফল্ট বক্সে 30000 থেকে 30099 পর্যন্ত রেঞ্জটি নিরাপদ। এই সংখ্যার ওপর নির্ভর না করে আপনার নিজের বক্সটি পরীক্ষা করে নিন।

Firewall-এ একই range খুলুন

ufw range লেখার জন্য colon ব্যবহার করে। এর manual-এ বলা আছে, একটি range বা list ব্যবহার করে "একাধিক port নির্দিষ্ট করাও সম্ভব। সে ক্ষেত্রে protocol আবশ্যক":

sudo ufw allow 21/tcp
sudo ufw allow 30000:30099/tcp
sudo ufw status verbose

এখন ufw status verbose-এ উভয় entry তালিকাভুক্ত হওয়ার কথা। /tcp ছাড়া একই command error দিয়ে প্রত্যাখ্যাত হবে। কারণ ufw আপনাআপনি tcp বা udp নির্ধারণ করে না; আপনাকে protocol নির্দিষ্ট করতে হবে। বাকি বিষয় VPS-এ ufw rule syntax-এ আছে।

firewalld range লেখার জন্য hyphen ব্যবহার করে এবং reload প্রয়োজন:

sudo firewall-cmd --permanent --add-service=ftp
sudo firewall-cmd --permanent --add-port=30000-30099/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

--add-service=ftp 21/tcp খুলে দেয় এবং ftp helper-এর অনুরোধ করে। Shipped service definition-এ helper-টির এই নামই দেওয়া আছে। এটি আপনার passive range খোলে না। তাই শুধু এই command চালালে সমস্যার কোনো সমাধান হবে না। বিস্তারিত বিষয় VPS-এ firewalld zone ও service-এ আছে।

input chain-এর ভিতরে সরাসরি nftables ব্যবহার করলে:

tcp dport { 21, 30000-30099 } accept

আরেকটি firewall মনে রাখুন: অধিকাংশ provider operating system-এর বাইরে control panel-এ একটি network firewall চালায়। Server-এর rule সঠিক দেখালেও packet যদি এখনও না আসে, সেখানে একই range খুলুন।

NAT-এর পেছনে থাকা সার্ভারকে তার public address জানানো

সার্ভারে ip -4 addr show চালান। Interface-এর address যদি clients যে address-এ সংযোগ করে সেটিই হয়, তাহলে এই section বাদ দিন। Interface-এ যদি private address (10.x, 172.16 থেকে 172.31.x, 192.168.x) থাকে এবং platform সেটির সঙ্গে একটি public address map করে, তাহলে সার্ভার নিজের public address জানে না। vsftpd pasv_address-এর default হিসেবে উল্লেখ করে যে "address is taken from the incoming connected socket"। তাই 227 reply-তে private address থাকে এবং client-কে এমন একটি address-এ পাঠানো হয় যেখানে সে পৌঁছাতে পারে না।

FileZilla এই সমস্যাটির নির্দিষ্ট নাম ব্যবহার করে:

Server sent passive reply with unroutable address. Using server address instead.

FileZilla এটি ঠিক করে এবং কাজ চালিয়ে যায়। অন্য অনেক client তা করে না। তারা 10.0.0.5-এ সংযোগের চেষ্টা করে এবং অপেক্ষা করতে থাকে।

curl-ও সমস্যাটি আড়াল করে, যা গুরুত্বপূর্ণ যদি curl আপনার test tool হয়। এর manual-এ বলা আছে, --ftp-skip-pasv-ip "is enabled by default (added in 7.74.0)"। তাই curl 227 reply-এর address উপেক্ষা করে এবং control connection-এর address পুনরায় ব্যবহার করে। curl দিয়ে সফল হওয়া transfer একই কারণে graphical client-এ ব্যর্থ হতে পারে।

Address-টি স্পষ্টভাবে নির্ধারণ করুন। vsftpd pasv_address=203.0.113.10 গ্রহণ করে। Hostname ব্যবহার করতে চাইলে pasv_addr_resolve=YES-ও ব্যবহার করুন; এর default হলো NO। ProFTPD MasqueradeAddress গ্রহণ করে, যেখানে address, DNS name অথবা interface name দেওয়া যায়। Pure-FTPd -P গ্রহণ করে। এটি সেই পরিস্থিতির জন্য নথিভুক্ত, যেখানে "the server is behind a masquerading (NAT) box"। EPSV পুরো সমস্যাটি এড়ায়, কারণ এর reply-তে কোনো address field নেই। তবে এর ওপর নির্ভর করা যায় না, কারণ কোন command পাঠানো হবে তা client নির্ধারণ করে।

TLS-এ কী পরিবর্তন হয়

FTPS হলো TLS (transport layer security) ব্যবহার করে চালানো FTP। ক্লায়েন্ট স্বাভাবিকভাবে port 21-এ সংযোগ করে, control channel সুরক্ষিত করতে AUTH TLS পাঠায়, তারপর data channel-ও encrypt করতে PROT P পাঠায়। Plain FTP password-কে পাঠযোগ্য text হিসেবে network traffic-এ পাঠায়। তাই FTP চালু রাখতেই হলে FTPS ব্যবহার করুন। vsftpd-এর সাথে ssl_enable থাকে, যার default মান NO।

এর দুটি ফল আছে। কোনো connection tracking helper কাজ করতে পারবে না। এটি উপরের বিষয়টির বিপরীত দিক থেকে দেখা একই ফল। এবং sudo tcpdump -nAi any 'tcp port 21' এখন আর আপনাকে 227 reply দেখাবে না। তাই server কোন address ও port বিজ্ঞাপন দিয়েছে তা জানতে হলে network traffic-এর বদলে server-এর নিজস্ব log পড়ুন।

বাইরের নেটওয়ার্ক থেকে পরিবর্তন পরীক্ষা করা

অন্য একটি মেশিন থেকে এগুলো চালান। সার্ভার থেকেই পরীক্ষা করলে আপনি যে firewall ঠিক করার চেষ্টা করছেন, সেটি এড়িয়ে যায়।

sudo ss -ltnp | grep :21
curl -v --disable-epsv --user ftpuser:secret ftp://example.com/
nc -vz example.com 30000

ss চালালে port 21-এ FTP daemon listening করছে কি না দেখা উচিত। সার্ভার idle থাকলে passive range-এর কোনো port listening অবস্থায় থাকে না, কারণ transfer-এর জন্য এই socket তৈরি হয় এবং transfer শেষ হলে বন্ধ হয়ে যায়।

--disable-epsv curl-কে PASV path ব্যবহার করতে বাধ্য করে। এই path-এই address সমস্যাটি প্রকাশ পায়। trace-এ প্রথমে সার্ভারের reply, তারপর curl যে address ও port-এ সংযোগ করে তা দেখা যায়:

< 227 Entering Passive Mode (203,0,113,10,117,52)

117 * 256 + 52 = 30004, যা ঘোষিত range-এর মধ্যে আছে। ওই লাইনে private address দেখা গেলে বোঝায়, pasv_address unset। আপনার নির্ধারিত range-এর বাইরে কোনো port দেখা গেলে বোঝায়, সার্ভার configuration পরিবর্তনটি পড়েনি। তাই running service যে file ব্যবহার করে, আপনি সেটিই সম্পাদনা করেছেন কি না পরীক্ষা করুন।

nc নিজেই firewall-সংক্রান্ত প্রশ্নের উত্তর দেয়। তাৎক্ষণিক Connection refused বোঝায়, packet সার্ভারে পৌঁছেছে কিন্তু listening অবস্থায় কিছু পায়নি। idle passive port-এর ক্ষেত্রে এটিই সঠিক ফলাফল; অর্থাৎ আপনার rule কাজ করছে। nc ছেড়ে দেওয়া পর্যন্ত অপেক্ষা করলে বোঝায়, কোনো কিছু packet-টি নীরবে ফেলে দিয়েছে। এটি firewall-এর সমস্যা; firewall-টি সার্ভারে থাকতে পারে অথবা provider-এর panel-এ থাকতে পারে। এই পার্থক্যটি SSH-তে refused এবং timed out-এর পার্থক্য অংশে বর্ণিত একই বিষয়, এবং এটি প্রতিটি port-এর ক্ষেত্রেই প্রযোজ্য।

আপনার কি এখনও FTP চালানো উচিত?

নতুন কাজের জন্য, না। SFTP (SSH file transfer protocol) পোর্ট 22-এ একটি একক SSH কানেকশনের ভেতরে চলে। এতে কোনো দ্বিতীয় চ্যানেল, প্যাসিভ রেঞ্জ, NAT সেটিং বা অতিরিক্ত কোনো ডেমনের নিরাপত্তা নিশ্চিত করার প্রয়োজন নেই, কারণ OpenSSH নিজেই এটি প্রদান করে। sftp user@example.com এমন বক্সেও কাজ করে যেখানে আপনি ফাইল ট্রান্সফার সার্ভিস কনফিগার করেননি। কাউকে শুধু ফাইল দেওয়ার জন্য, sshd_config-তে ForceCommand internal-sftp এবং ChrootDirectory ব্যবহার করা যায়। সেই ডিরেক্টরির মালিকানা root-এর হতে হবে এবং ব্যবহারকারীর সেখানে লেখার অনুমতি থাকা যাবে না, অন্যথায় sshd সেশনটি প্রত্যাখ্যান করবে এবং একটি bad ownership or modes for chroot directory লাইন লগ করবে।

FTP এখনও তার জায়গা ধরে রেখেছে যখন অপর প্রান্তের কোনো পরিবর্তন সম্ভব নয়। স্ক্যানার এবং মাল্টিফাংশন প্রিন্টারের ফার্মওয়্যার শুধু FTP সমর্থন করে। ল্যাব এবং ইন্ডাস্ট্রিয়াল ইকুইপমেন্ট প্রায়ই এমন ফিক্সড ইমেজে চলে যা কেউ নতুন করে সার্টিফাই করবে না। ব্যবসায়িক অংশীদাররা একটি FTPS ড্রপ পাবলিশ করে এবং একজন সরবরাহকারীর জন্য নতুন কোনো প্রোটোকল যোগ করতে রাজি হয় না। এই প্রতিটি ক্ষেত্রে প্যাসিভ রেঞ্জ এবং সংশ্লিষ্ট ফায়ারওয়াল রুলই হলো মূল কাজ, এবং সাধারণ FTP-এর পরিবর্তে FTPS সংস্করণটি চালানো উচিত। এই দুই-চ্যানেল ডিজাইনটি 1980 সালের একটি সিদ্ধান্ত, যা RFC 959-এর পাঁচ বছর আগেই RFC 765-এ ছিল। এটি এখন এমন এক বিশ্বে চলছে যা এটি আগে কখনো কল্পনাও করেনি, এই বিষয়টি ফাইল ট্রান্সফার প্রোটোকলের ইতিহাসে বিস্তারিত আলোচনা করা হয়েছে।

FAQ

FTP-তে লগইন হয়, কিন্তু directory listing কেন আটকে থাকে?

লগইন করতে শুধু port 21-এর control connection ব্যবহৃত হয়, যা আপনার firewall অনুমতি দেয়। Directory listing-এর জন্য অন্য port-এ একটি দ্বিতীয় TCP connection প্রয়োজন, কিন্তু সেই connection blocked থাকে। FTP server-এ একটি passive port range নির্ধারণ করুন এবং firewall-এ একই range খুলুন। তাহলে listing সম্পন্ন হবে। Listing আটকে থাকা data channel-এর সমস্যা, password-এর সমস্যা নয়।

FTP passive mode-এর জন্য কোন port খুলতে হবে?

Control channel-এর জন্য port 21 এবং passive data connection-এর জন্য আপনি যে range configure করেছেন, সেটি খুলতে হবে। কোনো standard range নেই, কারণ range আপনি নির্ধারণ করেন। 30000 থেকে 30099-এর মতো range কাজ করে। একই সময়ে চলা transfer-এর সর্বোচ্চ সংখ্যা অনুযায়ী range-এর আকার নির্ধারণ করুন এবং kernel-এর outgoing port range-এর বাইরে রাখুন। এই range sysctl net.ipv4.ip_local_port_range দিয়ে দেখা যায়। Provider-এর control panel-এ network firewall থাকলে সেখানে একই range খুলুন।

আমার কি এখনও nf_conntrack_ftp প্রয়োজন?

না। বর্তমান kernel-এ এর ওপর নির্ভর করা যায় না। Automatic helper assignment ডিফল্টভাবে disabled থাকে। Linux 6.0 থেকে net.netfilter.nf_conntrack_helper switch সরিয়ে নেওয়া হয়েছে, তাই sysctl জানায় যে file-টি নেই। ufw-এর manual-এ ওই module-গুলো শর্তহীনভাবে load করাকে deprecated বলা হয়েছে। firewalld AutomaticHelpers সম্পূর্ণভাবে উপেক্ষা করে। Helper-কে control channel plain text হিসেবে পড়তে হয়। তাই FTPS enable করলেই এটি কাজ করা বন্ধ করে। এর পরিবর্তে একটি passive port range নির্ধারণ করুন।

আমার FTP client কেন বলে passive reply-তে routable নয় এমন address আছে?

Server PASV-এ নিজের interface-এ দেখা address দিয়ে উত্তর দিয়েছে, এবং সেই address private। Platform যখন public address-কে private address-এ map করে, তখন এটি ঘটে। Public address স্পষ্টভাবে নির্ধারণ করুন: vsftpd-তে pasv_address, ProFTPD-তে MasqueradeAddress অথবা Pure-FTPd-তে -P। FileZilla ইতিমধ্যে যে address-এ connected হয়েছে, সেটিই আবার ব্যবহার করে এই সমস্যা সামলে নেয় এবং "Using server address instead" log করে। তাই কিছু client ভুল configuration সত্ত্বেও কাজ করে, আর অন্যগুলো আটকে থাকে।

আমার কি FTPS নাকি SFTP ব্যবহার করা উচিত?

উভয় প্রান্ত নিয়ন্ত্রণ করতে পারলে সব ক্ষেত্রে SFTP ব্যবহার করুন। এটি port 22-এ SSH-এর ওপর একটি connection ব্যবহার করে, আলাদা data channel খোলার প্রয়োজন হয় না এবং এটি ইতিমধ্যে চালু থাকে। FTPS হলো TLS-এর ওপর FTP। তাই এতে দুই-channel নকশা এবং এর সঙ্গে থাকা সব firewall সমস্যা বজায় থাকে। অন্য প্রান্তে আর কোনো protocol না থাকলে FTPS ব্যবহার করুন। Internet-এর মাধ্যমে plain FTP ব্যবহার করবেন না, কারণ password network-এর ওপর পাঠযোগ্য text হিসেবে যায়।