FTP passive mode কেন কাজ করে না এবং এর সমাধান

কেন FTP লগইন করার পর ডিরেক্টরি লিস্টিং হ্যাং হয়ে যায়

ফায়ারওয়ালের কারণে FTP passive mode কাজ করে না, কারণ FTP একটির পরিবর্তে দুটি TCP কানেকশন ব্যবহার করে। পোর্ট 21-এর কানেকশনটি লগইন এবং কমান্ডগুলো বহন করে, তাই ইউজারনেম ও পাসওয়ার্ড গৃহীত হয় এবং ফায়ারওয়ালকে সবকিছু ঠিকঠাক মনে হয়। এরপর প্রথম ls-এর জন্য একটি ভিন্ন পোর্টে দ্বিতীয় কানেকশনের প্রয়োজন হয়। ফায়ারওয়ালে সেই কানেকশনটির অনুমতি না থাকায় ক্লায়েন্ট টাইম-আউট না হওয়া পর্যন্ত অপেক্ষা করতে থাকে।

এর সমাধান হলো ডেটা কানেকশনগুলোর জন্য একটি নির্দিষ্ট পোর্ট রেঞ্জ নির্ধারণ করা এবং ফায়ারওয়ালে সেই একই রেঞ্জের অনুমতি দেওয়া। NAT (network address translation)-এর পেছনে থাকা সার্ভারের ক্ষেত্রে আরও একটি সেটিংস প্রয়োজন হয়, যাতে এটি সঠিক অ্যাড্রেসটি অ্যাডভার্টাইজ করতে পারে। আগে কানেকশন ট্র্যাকিং হেল্পাররা এই কাজটি করে দিত। এখন আর তারা তা করে না, এবং কোনো পুরনো গাইড অনুসরণ করার আগে এই কারণটি জেনে রাখা জরুরি।

কন্ট্রোল চ্যানেল এবং ডেটা চ্যানেল

FTP (file transfer protocol) RFC 959-এ নির্দিষ্ট করা হয়েছে এবং এটি NAT ও stateful firewall-এর চেয়েও পুরনো। একটি সেশন TCP port 21-এ একটি কন্ট্রোল কানেকশন খোলে এবং পুরো সেশন জুড়ে তা খোলা রাখে। কমান্ডগুলো plain text হিসেবে পাঠানো হয়। উত্তরগুলো একটি তিন ডিজিটের কোড এবং এক লাইন টেক্সট হিসেবে ফিরে আসে। সেই কানেকশন দিয়ে কখনোই ফাইলের বিষয়বস্তু আদান-প্রদান হয় না।

প্রতিটি ডেটার জন্য আলাদা TCP কানেকশন তৈরি হয়: একটি ডিরেক্টরি লিস্টিংয়ের জন্য (LIST), একটি প্রতিটি ডাউনলোডের জন্য (RETR), এবং একটি প্রতিটি আপলোডের জন্য (STOR)। এটি খোলা হয়, একবার ব্যবহার করা হয় এবং তারপর বন্ধ করে দেওয়া হয়। অথেন্টিকেশন সম্পূর্ণভাবে কন্ট্রোল চ্যানেলে ঘটে, তাই ডেটা পাথ নষ্ট হয়ে গেলে সবসময় একই রকম দেখায়: সফল লগইন, তারপর হ্যাং হয়ে যাওয়া। যদি ক্লায়েন্ট একটি 230 রিপ্লাই প্রিন্ট করে এবং তারপর লিস্টিংয়ে আটকে যায়, তবে বুঝবেন সমস্যাটি ডেটা চ্যানেলে, ক্রেডেনশিয়াল বা পাসওয়ার্ডে নয়।

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

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

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

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

ক্লায়েন্টের দৃষ্টিকোণ থেকে এই কানেকশনটি ইনবাউন্ড এবং অনাকাঙ্ক্ষিত, তাই ক্লায়েন্টের ফায়ারওয়াল এটি ড্রপ করে দেয়। যদি ক্লায়েন্ট কোনো হোম রাউটারের পেছনে থাকে, তবে PORT কমান্ডে থাকা অ্যাড্রেসটি একটি প্রাইভেট অ্যাড্রেস হয়, যা সার্ভারের পক্ষে কোনোভাবেই রিচ করা সম্ভব নয়। Active mode-এর কারণেই FTP-এর কাজ না করার কুখ্যাতি তৈরি হয়েছে।

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

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

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

একই এনকোডিং, তাই ক্লায়েন্ট 203.0.113.10-এর 50000 পোর্টে সংযোগ স্থাপন করে। ক্লায়েন্ট এখন উভয় সংযোগই খোলে, আর এই কারণেই প্যাসিভ মোড ক্লায়েন্ট-সাইড NAT-এর ক্ষেত্রে কাজ করে এবং বর্তমানের প্রতিটি ক্লায়েন্ট প্রথমেই এটি ব্যবহার করতে চায়।

সমস্যাটি দূর হওয়ার পরিবর্তে স্থানান্তরিত হয়েছে। এখন অনাকাঙ্ক্ষিত ইনবাউন্ড সংযোগটি আপনার সার্ভারে এসে পৌঁছায়, এমন একটি হাই পোর্টে যা প্রতিটি ট্রান্সফারের সাথে পরিবর্তিত হয়। সেই ফায়ারওয়ালটি আপনার, তাই এখন সমস্যাটিও আপনার।

EPSV (এক্সটেন্ডেড প্যাসিভ মোড, RFC 2428) একই ধারণার ওপর ভিত্তি করে তৈরি, তবে এর উত্তরটি আরও পরিচ্ছন্ন:

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

এতে কোনো ঠিকানা থাকে না। ক্লায়েন্ট কন্ট্রোল সংযোগের জন্য ইতিমধ্যে যে ঠিকানাটি ব্যবহার করছে সেটিই পুনরায় ব্যবহার করে, যা এটিকে IPv6-এর ওপর কাজ করতে সক্ষম করে এবং NAT সংক্রান্ত এক ধরনের ত্রুটি দূর করে। curl-এর ম্যানুয়াল অনুযায়ী, curl সাধারণত PASV-এর আগে EPSV চেষ্টা করে। পোর্টটি এখনও রানটাইমে নির্বাচন করা হয়, তাই EPSV আপনার ফায়ারওয়াল নিয়মে কোনো পরিবর্তন আনে না।

কেন সাধারণ firewall rule ডেটা চ্যানেলকে অনুমতি দিতে পারে না

কারণ আপনি যখন rule লিখছেন, তখন port নম্বরটি তৈরিই হয়নি। সার্ভার প্রতিটি ট্রান্সফারের সময় এটি নির্বাচন করে। ডিফল্ট অবস্থায়, vsftpd pasv_min_port এবং pasv_max_port-কে 0 হিসেবে নথিবদ্ধ করে, যার অর্থ হলো "যেকোনো port ব্যবহার করো", তাই ডেটা কানেকশন 1023-এর উপরের যেকোনো port-এ আসতে পারে। sudo ufw allow 21/tcp শুধুমাত্র কন্ট্রোল চ্যানেলকে অনুমতি দেয় এবং অন্য কিছুকে নয়, আর ঠিক এই কনফিগারেশনের কারণেই লগইন সফল হয় কিন্তু লিস্টিং কাজ করে না। যদি একটি নির্দিষ্ট port-এ সার্ভিস লিসেন করার বিষয়টি এখনো অস্পষ্ট মনে হয়, তবে Linux-এ port এবং listening socket কীভাবে কাজ করে বিষয়টি এর প্রেক্ষাপট হিসেবে কাজ করবে।

একটি stateful firewall কানেকশন ট্র্যাক করে এবং কার্নেল একটি বিদ্যমান কানেকশনের RELATED হিসেবে নতুন কানেকশন গ্রহণ করতে পারে। FTP-এর ক্ষেত্রে এর জন্য এমন কিছু প্রয়োজন যা কন্ট্রোল স্ট্রিমটি পড়তে পারে এবং একটি 227 বা PORT লাইন থেকে port নম্বরটি বের করে আনতে পারে। ডিফল্টভাবে এমন কিছু নেই যা এটি করে।

কেন FTP connection tracking helper এখন আর কার্যকর সমাধান নয়

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

স্বয়ংক্রিয় হেল্পার অ্যাসাইনমেন্ট বন্ধ করে দেওয়া হয়েছে। কার্নেল ডকুমেন্টেশনে nf_conntrack_helper sysctl-কে "0 - disabled (default)" হিসেবে উল্লেখ করা হয়েছে এবং বলা হয়েছে: "যদি এটি নিষ্ক্রিয় থাকে, তবে কানেকশনে হেল্পার অ্যাসাইন করার জন্য iptables রুল সেটআপ করা আবশ্যক।" শুধুমাত্র মডিউলটি লোড করলে কোনো কাজ হয় না।

বর্তমান কার্নেলগুলোতে এই সুইচটি আর নেই। sysctl net.netfilter.nf_conntrack_helper কমান্ডটি চালান। যদি sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_helper: No such file or directory উত্তর আসে, তবে বুঝতে হবে কার্নেলে স্বয়ংক্রিয় হেল্পার অ্যাসাইনমেন্ট আর নেই। যদি এর পরিবর্তে কোনো সংখ্যা ফিরে আসে, তবে সুইচটি এখনও বিদ্যমান এবং এর ডিফল্ট মান 0।

ফায়ারওয়াল ফ্রন্ট-এন্ডগুলোও এটিকে বাতিল করেছে। Ubuntu 24.04-এর man ufw-framework-এ /etc/default/ufw ফাইলের IPT_MODULES লাইন সম্পর্কে বলা হয়েছে: "এই পদ্ধতিতে কানেকশন ট্র্যাকিং মডিউল (nf_conntrack_*) লোড করা এখন আর গ্রহণযোগ্য নয় (deprecated)", এবং আরও বলা হয়েছে যে হেল্পার রুলগুলো অবশ্যই "RULES FILES-এর মাধ্যমে ম্যানেজ করতে হবে।" firewalld-এর firewalld.conf ফাইলে AutomaticHelpers সম্পর্কে বলা হয়েছে: "বাতিল করা হয়েছে (Deprecated)। এই অপশনটি উপেক্ষা করা হয় এবং আর ব্যবহৃত হয় না।" বর্তমানে হেল্পার যুক্ত করার অর্থ হলো হাতে কলমে CT টার্গেট ব্যবহার করে একটি স্পষ্ট রুল লেখা, যা নিচের সমাধানের চেয়ে বেশি জটিল এবং TLS চালু করার সাথে সাথেই এটি কাজ করা বন্ধ করে দেয়। Ubuntu-তে iptables এবং nftables অংশে এই রুলগুলো কোথায় থাকে তা আলোচনা করা হয়েছে।

TLS এই বিতর্কের অবসান ঘটায়। একটি হেল্পার কন্ট্রোল চ্যানেলকে টেক্সট হিসেবে পড়ে কাজ করে। সেই চ্যানেলটি এনক্রিপ্ট করলে হেল্পার শুধুমাত্র সাইফারটেক্সট দেখতে পায়, তাই এটি পোর্টটি খুঁজে পায় না। এর কোনো সমাধান নেই এবং থাকা উচিতও নয়: যে মিডলবক্স আপনার কন্ট্রোল চ্যানেল পড়তে পারে, সেই মিডলবক্স আপনার পাসওয়ার্ডও পড়তে সক্ষম।

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

প্রতিটি 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 কোনো কনফিগারেশন লাইন পার্স করতে না পারলে তা উপেক্ষা না করে বরং স্টার্ট হতে অস্বীকার করে, তাই রিস্টার্ট ব্যর্থ হলে 500 OOPS: লাইনের জন্য journalctl -u vsftpd -n 20 পড়ুন, যেখানে আপনি অপশনটি টাইপ করেছেন।

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

PassivePorts 30000 30099

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

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

আপনার কতগুলো পোর্ট প্রয়োজন? প্রতি চলমান ডেটা কানেকশনের জন্য একটি। একটি বন্ধ TCP পোর্ট পুনরায় ব্যবহারের আগে কয়েক মিনিট TIME_WAIT অবস্থায় থাকে, তাই আপনার প্রত্যাশিত সর্বোচ্চ ব্যবহারের চেয়ে কয়েক গুণ বেশি পোর্ট বরাদ্দ রাখুন। অল্প সংখ্যক ব্যবহারকারীর জন্য একশটি পোর্ট যথেষ্ট, তবে একটি ব্যস্ত পাবলিক সার্ভারের জন্য আরও অনেক বেশি পোর্টের প্রয়োজন।

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

ফায়ারওয়ালে একই রেঞ্জ ওপেন করুন

ufw একটি কোলন ব্যবহার করে রেঞ্জ লেখে এবং এর ম্যানুয়াল অনুযায়ী, একাধিক পোর্ট নির্দিষ্ট করার জন্য রেঞ্জ বা লিস্ট ব্যবহার করা যেতে পারে, তবে সেক্ষেত্রে প্রোটোকল উল্লেখ করা বাধ্যতামূলক:

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

ufw status verbose এখন উভয় এন্ট্রিই তালিকাভুক্ত করবে। /tcp ছাড়া একই কমান্ড দিলে তা একটি এরর মেসেজের মাধ্যমে প্রত্যাখ্যান করা হবে, কারণ ufw প্রোটোকল অনুমান করতে পারে না; আপনাকে অবশ্যই tcp বা udp উল্লেখ করতে হবে। VPS-এ ufw রুল সিনট্যাক্স-এ বাকি অংশ আলোচনা করা হয়েছে।

firewalld একটি হাইফেন ব্যবহার করে রেঞ্জ লেখে এবং এর জন্য রিলোড প্রয়োজন:

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 হেল্পারের অনুরোধ জানায়, যা শিপড সার্ভিস ডেফিনিশনে উল্লেখ থাকে। এটি আপনার প্যাসিভ রেঞ্জ ওপেন করে না, তাই শুধুমাত্র এটি ব্যবহার করলে আপনি আগের অবস্থানেই থাকবেন। VPS-এ firewalld জোন এবং সার্ভিস-এ বিস্তারিত আলোচনা করা হয়েছে।

সরাসরি nftables-এর ক্ষেত্রে, আপনার input চেইনের ভেতরে:

tcp dport { 21, 30000-30099 } accept

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

NAT-এর পেছনে থাকলে সার্ভারকে তার পাবলিক অ্যাড্রেস জানান

সার্ভারে ip -4 addr show চালান। যদি ইন্টারফেসে থাকা অ্যাড্রেসটিই ক্লায়েন্টদের সংযোগের জন্য ব্যবহৃত হয়, তবে এই অংশটি বাদ দিন। যদি ইন্টারফেসে একটি প্রাইভেট অ্যাড্রেস (10.x, 172.16 থেকে 172.31.x, 192.168.x) থাকে এবং প্ল্যাটফর্ম সেটিকে একটি পাবলিক অ্যাড্রেসের সাথে ম্যাপ করে, তবে সার্ভার তার নিজের পাবলিক অ্যাড্রেসটি জানে না। vsftpd-এর ডকুমেন্টেশন অনুযায়ী pasv_address-এর ডিফল্ট মান হলো "ইনকামিং কানেক্টেড সকেট থেকে অ্যাড্রেসটি নেওয়া হয়", তাই 227 রিপ্লাইতে প্রাইভেট অ্যাড্রেসটি থাকে এবং ক্লায়েন্টকে এমন কোথাও পাঠানো হয় যেখানে সে পৌঁছাতে পারে না।

FileZilla-তে এটি স্পষ্টভাবে উল্লেখ করা থাকে:

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

FileZilla এটি ঠিক করে নেয় এবং কাজ চালিয়ে যায়। অনেক ক্লায়েন্ট তা করে না। তারা 10.0.0.5-এ ডায়াল করে এবং ঝুলে থাকে।

curl-ও এই সমস্যাটি লুকিয়ে রাখে, যা গুরুত্বপূর্ণ যদি আপনি curl দিয়ে পরীক্ষা করেন। এর ম্যানুয়াল অনুযায়ী --ftp-skip-pasv-ip "ডিফল্টভাবে সক্রিয় থাকে (7.74.0 ভার্সনে যুক্ত হয়েছে)", তাই curl 227 রিপ্লাইতে থাকা অ্যাড্রেসটিকে উপেক্ষা করে এবং কন্ট্রোল কানেকশনের অ্যাড্রেসটি পুনরায় ব্যবহার করে। curl দিয়ে যে ট্রান্সফার কাজ করে, তা শুধুমাত্র এই একটি কারণে গ্রাফিক্যাল ক্লায়েন্টে ব্যর্থ হতে পারে।

অ্যাড্রেসটি স্পষ্টভাবে সেট করুন। vsftpd-এর জন্য pasv_address=203.0.113.10 ব্যবহার করুন, এবং যদি আপনি হোস্টনাম লিখতে চান তবে pasv_addr_resolve=YES (ডিফল্ট NO) ব্যবহার করুন। ProFTPD-এর জন্য MasqueradeAddress ব্যবহার করুন, যা একটি অ্যাড্রেস, DNS নাম বা ইন্টারফেস নাম গ্রহণ করে। Pure-FTPd-এর জন্য -P ব্যবহার করুন, যা এমন ক্ষেত্রে ডকুমেন্ট করা হয়েছে যেখানে "সার্ভার একটি মাস্করেডিং (NAT) বক্সের পেছনে থাকে"। EPSV পুরো সমস্যাটি এড়িয়ে যায় কারণ এর রিপ্লাইতে কোনো অ্যাড্রেস ফিল্ড থাকে না, তবে আপনি এর ওপর নির্ভর করতে পারবেন না, কারণ ক্লায়েন্ট সিদ্ধান্ত নেয় কোন কমান্ড পাঠাতে হবে।

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

FTPS হলো TLS (transport layer security)-এর মাধ্যমে পরিচালিত FTP। ক্লায়েন্ট সাধারণত port 21-এ সংযোগ স্থাপন করে, এরপর control channel সুরক্ষিত করতে AUTH TLS পাঠায় এবং সবশেষে data channel এনক্রিপ্ট করার জন্য PROT P পাঠায়। সাধারণ FTP-তে পাসওয়ার্ড প্লেইন টেক্সট হিসেবে নেটওয়ার্কে আদান-প্রদান হয়, তাই যদি FTP ব্যবহার করতেই হয়, তবে FTPS ব্যবহার করুন। vsftpd-এর সাথে ssl_enable ডিফল্টভাবে NO হিসেবে থাকে।

এর ফলে দুটি বিষয় ঘটে। কোনো connection tracking helper কাজ করতে পারে না, যা উপরের আলোচনার অন্য দিক। এছাড়া sudo tcpdump -nAi any 'tcp port 21' আর আপনাকে 227 রিপ্লাই দেখাবে না। তাই সার্ভার কোন অ্যাড্রেস এবং পোর্ট বিজ্ঞাপন (advertise) করছে তা জানতে চাইলে নেটওয়ার্ক ট্র্যাফিক না দেখে সার্ভারের নিজস্ব লগ পড়ুন।

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

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

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

ss কমান্ডটি দেখালে বোঝা যাবে যে FTP daemon 21 নম্বর পোর্টে লিসেন করছে। সার্ভার অলস অবস্থায় থাকলে প্যাসিভ রেঞ্জে কিছুই লিসেন করে না, কারণ এই সকেটগুলো কেবল ডেটা ট্রান্সফারের জন্য তৈরি হয় এবং কাজ শেষে বন্ধ হয়ে যায়।

--disable-epsv কমান্ডটি curl-কে PASV পাথের দিকে বাধ্য করে, যা মূলত অ্যাড্রেস সংক্রান্ত সমস্যাটি প্রকাশ করে। ট্রেসটি সার্ভারের রিপ্লাই প্রিন্ট করে, তারপর curl যে অ্যাড্রেস এবং পোর্টে ডায়াল করে তা দেখায়:

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

117 * 256 + 52 = 3004, যা ঘোষিত রেঞ্জের মধ্যেই আছে। ওই লাইনে একটি প্রাইভেট অ্যাড্রেস থাকার অর্থ হলো pasv_address সেট করা হয়নি। যদি পোর্টটি আপনার নির্ধারিত রেঞ্জের বাইরে হয়, তবে বুঝতে হবে সার্ভার কনফিগারেশনের পরিবর্তনটি পড়েনি; তাই রানিং সার্ভিসটি যে ফাইলটি ব্যবহার করছে, আপনি সেটিই এডিট করেছেন কি না তা যাচাই করুন।

nc কমান্ডটি নিজেই ফায়ারওয়ালের প্রশ্নের উত্তর দেয়। তাৎক্ষণিক Connection refused পাওয়ার অর্থ হলো প্যাকেটটি সার্ভারে পৌঁছেছে এবং সেখানে লিসেন করার মতো কিছু পায়নি, যা একটি অলস প্যাসিভ পোর্টের জন্য সঠিক ফলাফল: অর্থাৎ আপনার রুলটি কাজ করছে। যদি nc পর্যন্ত হ্যাং হয়ে থাকে, তবে বুঝতে হবে কোনো কিছু প্যাকেটটিকে নীরবে ড্রপ করছে। এটি একটি ফায়ারওয়াল, যা হয় আপনার সার্ভারের ভেতরে অথবা আপনার প্রোভাইডারের প্যানেলে রয়েছে। এই পার্থক্যটি SSH-এর জন্য refused বনাম timed out-এ বর্ণিত পার্থক্যের মতোই এবং এটি প্রতিটি পোর্টের ক্ষেত্রেই প্রযোজ্য।

আপনার কি এখনও 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 ব্যবহার করা উচিত। দুটি চ্যানেলের এই ডিজাইনটি 1985 সালের একটি সিদ্ধান্ত, যা বর্তমানে এমন এক বিশ্বে চলছে যার জন্য এটি তৈরি হয়নি; এই বিষয়টি ফাইল ট্রান্সফার প্রোটোকলের ইতিহাস-এ বিস্তারিত আলোচনা করা হয়েছে।

FAQ

FTP-তে লগইন করা গেলেও ডিরেক্টরি লিস্টিং কেন আটকে যায়?

লগইন করার জন্য শুধুমাত্র পোর্ট 21-এর কন্ট্রোল কানেকশন ব্যবহৃত হয়, যা আপনার ফায়ারওয়াল অনুমতি দেয়। কিন্তু ডিরেক্টরি লিস্টিংয়ের জন্য ভিন্ন একটি পোর্টে দ্বিতীয় একটি TCP কানেকশন প্রয়োজন হয়, যা ফায়ারওয়াল দ্বারা ব্লক করা থাকে। FTP সার্ভারে একটি প্যাসিভ পোর্ট রেঞ্জ নির্ধারণ করুন এবং ফায়ারওয়ালে সেই একই রেঞ্জ খুলে দিন, তাহলেই লিস্টিং সম্পন্ন হবে। লিস্টিং আটকে যাওয়া মানে এটি একটি ডেটা চ্যানেল সংক্রান্ত সমস্যা, পাসওয়ার্ডের কোনো সমস্যা নয়।

FTP প্যাসিভ মোডের জন্য কোন কোন পোর্ট খোলা প্রয়োজন?

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

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

না, এবং বর্তমান কার্নেলে আপনি এর ওপর নির্ভর করতে পারবেন না। অটোমেটিক হেল্পার অ্যাসাইনমেন্ট ডিফল্টভাবে নিষ্ক্রিয় থাকে এবং সাম্প্রতিক কার্নেলগুলোতে net.netfilter.nf_conntrack_helper সুইচটি সরিয়ে ফেলা হয়েছে, তাই sysctl রিপোর্ট করে যে ফাইলটি নেই। ufw-এর ম্যানুয়াল অনুযায়ী এই মডিউলগুলো আনকন্ডিশনাল লোড করাকে এখন আর উৎসাহিত করা হয় না এবং firewalld সম্পূর্ণভাবে AutomaticHelpers উপেক্ষা করে। এছাড়া একটি হেল্পারকে কন্ট্রোল চ্যানেলটি প্লেইন টেক্সট হিসেবে পড়তে হয়, তাই FTPS চালু করার সাথে সাথেই এটি কাজ করা বন্ধ করে দেয়। এর পরিবর্তে একটি প্যাসিভ পোর্ট রেঞ্জ নির্ধারণ করুন।

FTP ক্লায়েন্ট কেন বলে যে প্যাসিভ রিপ্লাইতে একটি আনরাউটেবল অ্যাড্রেস আছে?

সার্ভার PASV-এর মাধ্যমে এমন একটি অ্যাড্রেস প্রদান করেছে যা তার নিজস্ব ইন্টারফেসে দেখা যায় এবং সেই অ্যাড্রেসটি একটি প্রাইভেট অ্যাড্রেস। যখন প্ল্যাটফর্ম কোনো পাবলিক অ্যাড্রেসকে প্রাইভেট অ্যাড্রেসে ম্যাপ করে, তখন এমনটি ঘটে। পাবলিক অ্যাড্রেসটি স্পষ্টভাবে সেট করুন: vsftpd-এর ক্ষেত্রে pasv_address, ProFTPD-এর ক্ষেত্রে MasqueradeAddress, অথবা Pure-FTPd-এর ক্ষেত্রে -P। FileZilla ইতিমধ্যে কানেক্ট করা অ্যাড্রেসটি পুনরায় ব্যবহার করে এই সমস্যা এড়িয়ে যায় এবং "Using server address instead" লগ দেখায়; এই কারণেই কিছু ক্লায়েন্ট এই ভুল কনফিগারেশন সত্ত্বেও কাজ চালিয়ে নিতে পারে, কিন্তু অন্যগুলো আটকে যায়।

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

উভয় প্রান্ত আপনার নিয়ন্ত্রণে থাকলে SFTP ব্যবহার করুন: এটি পোর্ট 22-এ SSH-এর মাধ্যমে একটি মাত্র কানেকশন ব্যবহার করে, কোনো ডেটা চ্যানেল খোলার প্রয়োজন হয় না এবং এটি আগে থেকেই চালু থাকে। FTPS হলো TLS-এর ওপর FTP, তাই এটি দুটি চ্যানেলের ডিজাইন বজায় রাখে এবং এর সাথে আসা ফায়ারওয়ালের সব সমস্যাও থেকে যায়। যখন অপর পক্ষ অন্য কোনো প্রোটোকল সমর্থন করে না, তখনই কেবল এটি বেছে নিন। ইন্টারনেটের মাধ্যমে প্লেইন FTP ব্যবহার করবেন না, কারণ এতে পাসওয়ার্ড নেটওয়ার্কে প্লেইন টেক্সট হিসেবে আদান-প্রদান হয়।