NAT করা VPN গেটওয়ের পেছনে FTP তালিকা কেন আটকে যায়
লগইন ও PWD কাজ করে, অথচ LIST ও RETR থেমে যায় যখন NAT কেবল হেডার পুনর্লিখন করে। FTP হেল্পার কোথায় থাকা উচিত এবং প্যাসিভ মোড কীভাবে ঠিক করবেন, দেখুন।
লগইন কাজ করে, PWD কাজ করে, তারপর LIST আটকে থাকে যতক্ষণ ক্লায়েন্ট হাল ছেড়ে না দেয় বা অন্য কোনো ডেটা মোডে না যায়। এই বিভাজনটাই স্বাক্ষর: পোর্ট 21-এ কন্ট্রোল সংযোগ সুস্থ, অথচ ডেটা সংযোগ তৈরি হচ্ছে এমন ঠিকানা বা পোর্ট থেকে যেখানে অন্য প্রান্ত পৌঁছাতে পারে না। যে VPN গেটওয়ে নিজেও NAT করে, তার পেছনে সাধারণত দোষী হলো একটি FTP কমান্ড যার পেলোডে 10.8.0.6-এর মতো টানেল ঠিকানা থাকে। হেডার অনুবাদ কখনো ওই মানটি স্পর্শ করে না।
এরপর আসছে ওই মানটি কোথা থেকে আসে এবং কোন বাক্সটি তা বদলাতে পারে।
ভাঙে পেলোড, টানেল নয়
FTP ডেটা শেষবিন্দুকে কন্ট্রোল স্ট্রিমের ভেতরে রাখে। অ্যাকটিভ মোডে ক্লায়েন্ট নিজের ঠিকানা ও পোর্টসহ PORT পাঠায়, আর সার্ভার সেই জোড়ায় ফিরতি কল করে। প্যাসিভ মোডে সার্ভার একটি জোড়া দিয়ে 227 উত্তর দেয়, আর ক্লায়েন্ট তার বদলে ওই জোড়ায় কল করে।
দুই রূপই একই ধরনের বাক্য বহন করে: এই ঠিকানায়, এই পোর্টে সংযোগ করুন। যে ডিভাইস কেবল IP ও TCP হেডার পুনর্লিখন করে সে বাক্যটি অক্ষত রাখে, ফলে এক প্রান্ত এমন ঠিকানায় পৌঁছানোর চেষ্টা করে যা কেবল টানেলের অন্য দিকে বিদ্যমান। কন্ট্রোল সংযোগ ইতিমধ্যে সুস্থ ঘোষণা হওয়ার পরেই ডেটা সংযোগ আটকে যায়।
তিন মোড, তিন পেলোড
নিচের সারণি দেখায় কোন পক্ষকে কল করতে বলা হচ্ছে, এবং কেবল হেডার বদলানো NAT সে ব্যাপারে কী করতে পারে।
শেষ কলামটিকে প্রথমে ব্যর্থ হওয়া জিনিস হিসেবে পড়ুন। অ্যাকটিভ মোডে প্রাইভেট ঠিকানায় কল করে সার্ভার; প্যাসিভ মোডে করে ক্লায়েন্ট; আর FTPS-এ পেলোড সাইফারটেক্সট, তাই মধ্যস্থ ডিভাইসের হাতে কাজ করার উপকরণ আরও কম।
| Mode | Value in the control stream | Who dials whom | Header-only NAT leaves |
|---|---|---|---|
| Active (PORT) | client address and port | server dials the client | a server dialing an unreachable tunnel address |
| Passive (227) | server address and port | client dials the server | a client dialing an address it cannot route to |
| FTPS | the same values, inside TLS | as above | ciphertext, so no rewrite happens at all |
হেল্পারকে সেখানে রাখুন যেখানে অনুবাদ ঘটে
লিনাক্সে পেলোড পুনর্লিখন করে 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-এ আটকে যাওয়া সেশনের প্রথম ডেটা সংযোগের দিকে ইঙ্গিত করে, যেখানে ঠিকানা পুনর্লিখন ও প্রত্যাশা দুটোই কাজ করতে হবে। কাজ করা LIST-এর পর RETR-এ আটকে যাওয়া ট্রান্সফারের দিকেই ইঙ্গিত করে, অর্থাৎ প্যাসিভ পরিসর বা টানেলের MTU। দ্বিতীয় স্বাক্ষরটি পেলোডের সমস্যা নয়, আর হেল্পারের সেটিংস তা সারাবে না।
TLS-এর ওপর FTP হেল্পার যে পেলোড পড়ে তা সরিয়ে দেয়। মধ্যস্থ বাক্স এমন PORT বা PASV মান পুনর্লিখন করতে পারে না যা সে ডিক্রিপ্ট করতে পারে না, তাই বাকি থাকে TLS শেষ করা প্রক্সি, সীমিত পরিসরের মধ্যে পৌঁছানোযোগ্য ঠিকানা ঘোষণা করা সার্ভার, বা ভিন্ন ট্রান্সফার প্রোটোকল।
যাচাইয়ের সংক্ষিপ্ত ক্রম
উপসর্গ থেকে বাইরের দিকে কাজ করুন। নিশ্চিত করুন PWD সফল হওয়ার সময় LIST ব্যর্থ হয়, PORT বা 227 পেলোডের ভেতরের ঠিকানা ধরে নিন, এবং জিজ্ঞাসা করুন কোন ডিভাইস ওই ঠিকানা অনুবাদ করে। সেখানে হেল্পার সংযুক্ত করুন, এক ট্রান্সফার চলাকালীন প্রত্যাশার তালিকা দেখুন, তারপর সার্ভারে প্যাসিভ মোড ঠিক করুন এবং গেটওয়ে নিয়মে পরিসরটি মিলিয়ে দিন।
ডেটা-পথের ব্যর্থতাকে বাল্ক-ট্রান্সফার ব্যর্থতা থেকে আলাদা রাখুন, কারণ দুটি আপনাকে ভিন্ন সেটিংসে নিয়ে যায়।