چرا فهرست‌های 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

کمک‌کننده را همان‌جا بگذارید که ترجمه رخ می‌دهد

در لینوکس بازنویسی بار را کمک‌کننده 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 را بگیرید و بپرسید کدام دستگاه آن نشانی را ترجمه می‌کند. کمک‌کننده را همان‌جا وصل کنید، در طول یک انتقال فهرست انتظارها را ببینید، سپس حالت غیرفعال را روی سرور درست کنید و بازه را در قاعده دروازه بازتاب دهید.

شکست مسیر داده را از شکست انتقال انبوه جدا نگه دارید، چون شما را به تنظیمات متفاوتی می‌فرستند.

مقالات مرتبط