کدام پورت‌های VPN را روی فایروال باز کنیم: پروتکل به پروتکل

PPTP به TCP 1723 و GRE نیاز دارد، L2TP/IPsec به UDP 500 و 4500 و ESP، و SSTP و OpenVPN و WireGuard هر یک به یک پورت نیاز دارند. آنچه باید باز شود این است.

دو قاعده جداگانه تعیین می‌کند که آیا تونل VPN از فایروال عبور می‌کند: پورتی که کلاینت به آن زنگ می‌زند و پروتکلی که بار مفید را حمل می‌کند. فقط اولی را باز کنید تا تونل احراز هویت شود و بعد هیچ داده‌ای جابجا نشود. حداقل یک پورت TCP و GRE برای PPTP، دو پورت UDP و ESP برای L2TP/IPsec و IKEv2، و یک پورت برای SSTP و OpenVPN و WireGuard است. جهت، ردیابی وضعیت و NAT بقیه را تعیین می‌کنند.

از پورتی شروع کنید که کلاینت به آن زنگ می‌زند

هر خانواده یک نقطه ورود دارد که کلاینت نخست با آن تماس می‌گیرد، و قاعده مجاز شما باید همان نقطه ورود را نام ببرد. کلاینت‌های PPTP به TCP 1723 وصل می‌شوند. L2TP/IPsec کار IKE را روی UDP 500 آغاز می‌کند و وقتی عبور از NAT فعال شود به UDP 4500 می‌رود، در حالی که خود قاب L2TP روی UDP 1701 درون تونل است. SSTP نشست را در TLS روی TCP 443 می‌پیچد، IKEv2 روی UDP 500 و 4500 مذاکره می‌کند، OpenVPN به طور پیش‌فرض از UDP 1194 استفاده می‌کند اما اغلب به TCP 443 منتقل می‌شود، و WireGuard روی UDP 51820 گوش می‌دهد.

FamilyRule to add on the gatewayTypical mistake
WireGuardUDP port from ListenPort, for the peer addressAssuming 51820 when the config says otherwise
OpenVPNThe configured UDP or TCP port, often 443Opening 1194 after the server moved
SSTPTCP 443 limited to the gateway IPAllowing 443 to any destination
IKEv2UDP 500 and UDP 4500, plus ESPAllowing only 500 and losing NAT-T
L2TP/IPsecUDP 500, 4500, ESP, and 1701 inside the tunnelExposing 1701 to the internet
PPTPTCP 1723 and IP protocol 47Writing a rule for TCP 47

این اعداد را پیش‌فرض بدانید نه ویژگی ثابت. رابط WireGuard از هر پورت شنودی که پیکربندی‌اش اعلام کند استفاده می‌کند، و سرور OpenVPN می‌تواند روی هر پورتی که مدیر انتخاب کرده بنشیند. پیش از نوشتن قاعده، پیکربندی سرور را بخوانید، چون فایروالی که برای 1194 باز شده برای سروری که به 443 منتقل شده هیچ کاری نمی‌کند.

ستون سوم جایی است که بیشتر تیکت‌های تغییر اشتباه می‌روند. قاعده وجود دارد، اما به مقصد اشتباه، جهت اشتباه یا ترابری اشتباه اشاره می‌کند.

GRE و ESP شماره پروتکل هستند، نه پورت

GRE و ESP اصلاً پورت ندارند، بنابراین فرم فایروالی که فقط شماره پورت می‌پذیرد نمی‌تواند آن‌ها را بیان کند. GRE پروتکل IP شماره 47 و ESP پروتکل IP شماره 50 است و هر دو از طریق فیلد پروتکل در سرآیند IP تطبیق داده می‌شوند. قاعده‌ای که به صورت پورت TCP 47 نوشته شود با هیچ چیز تطبیق نمی‌کند، و این‌گونه سیاست PPTP درست به نظر می‌رسد و با این حال هر بسته را پس از دست‌دادن می‌اندازد.

روترهای خانگی این را پشت یک چک‌باکس عبور پنهان می‌کنند که قاعده پروتکل و در مورد GRE کمک‌کننده NAT لازم برای نگاشت جریان را نصب می‌کند. روی فایروال واقعی خودتان پروتکل را اضافه می‌کنید: پروتکل IP شماره 47 را به سرور PPTP مجاز کنید، پروتکل IP شماره 50 را به دروازه IPsec مجاز کنید. جایی که بستر هیچ فیلد پروتکلی عرضه نمی‌کند، کپسوله‌سازی راه خروج است، به همین دلیل IKEv2 می‌تواند به UDP 4500 بازگردد و به همین دلیل OpenVPN و WireGuard هرگز به مشکل نمی‌خورند.

پیش از سرزنش کلاینت بررسی کنید قاعده واقعاً با چه چیزی تطبیق می‌خورد. شمارنده بسته‌ای که روی دروازه صفر می‌ماند می‌گوید قاعده هرگز شلیک نشده است، و هیچ مقدار نصب مجدد در سمت کلاینت آن را تغییر نمی‌دهد.

جهت، وضعیت و NAT پاسخ را تغییر می‌دهند

کلاینتی که به بیرون زنگ می‌زند و دروازه‌ای که به درون گوش می‌دهد دو نیاز متفاوت‌اند و همان فهرست پورت می‌تواند در یک جهت درست و در جهت دیگر نادرست باشد. فایروال حالت‌دار جریان UDP روی 500 و 4500 را ردیابی می‌کند و پاسخ‌ها را بدون قاعده دوم برمی‌گرداند. ESP و GRE پورتی حمل نمی‌کنند، بنابراین دستگاه NAT چیزی برای تکیه کردن ندارد و برای دنبال کردن نشست به کمک‌کننده یا کپسوله‌سازی نیاز دارد.

عبور از NAT همان بخشی است که از قلم می‌افتد. IKEv2 روی UDP 500 آغاز می‌شود، دستگاه NAT را تشخیص می‌دهد و روی UDP 4500 ادامه می‌دهد، پس سیاستی که فقط 500 را مجاز می‌کند تونلی می‌دهد که برقرار می‌شود و بعد ساکت می‌ماند. L2TP/IPsec همین حرکت را می‌کند. اگر ضبط شما تبادل نخست را نشان می‌دهد اما ترافیک پیوسته را نه، دنبال قاعده‌ای بگردید که در 500 متوقف می‌شود.

جهت را همراه هر قاعده ثبت کنید. «اجازه UDP 4500» تا نگویید از کجا به کجا هیچ معنایی ندارد، و قاعده‌ای که برای کلاینت سیار درست است معمولاً برای همتای سایت-به-سایت نادرست است.

هر مسیر را با ضبط بررسی کنید

ضبط را روی دروازه اجرا کنید، نه روی کلاینت: کلاینت فقط آنچه رسیده را ثبت می‌کند. این فیلترها خانواده‌های بالا را پوشش می‌دهند و نشان می‌دهند کدام مرحله غایب است:

sudo tcpdump -ni any tcp port 1723
sudo tcpdump -ni any udp port 500 or udp port 4500
sudo tcpdump -ni any proto gre
sudo tcpdump -ni any proto 50

خروجی را به عنوان یک توالی بخوانید. وقتی مذاکره پدیدار می‌شود اما پروتکل بار مفید نه، افتادن جایی بین کلاینت و دروازه رخ می‌دهد. وقتی هر دو پدیدار می‌شوند و صفحه هنوز شکست می‌خورد، فایروال دیگر مظنون نیست؛ مسیریابی، DNS یا استخر آدرسی که به کلاینت داده شده را ببینید.

روی ماشینی بدون tcpdump همان شواهد از شمارنده‌های رابط و قاعده به دست می‌آید. بایت‌هایی که وارد می‌شوند اما از رابط تونل خارج نمی‌شوند به مسیر بازگشت اشاره دارند نه به قاعده مجاز اولیه.

مجموعه قواعدی بگذارید که بتوانید از آن دفاع کنید

SSTP روی TCP 443 برای هر فیلتر مبتنی بر پورت از HTTPS معمولی قابل تفکیک نیست، و وقتی شبکه فقط ترافیک وب را مجاز می‌کند همین نکته مورد نظر است. به همین دلیل هم قاعده 443 باید دروازه را به عنوان مقصد نام ببرد نه کل اینترنت. قواعد موقت هر-چیز-به-هر-چیز را به محض کار کردن تونل حذف کنید. بنویسید کدام قاعده تطبیق خورد، شماره پروتکل در جایی که وجود دارد، و جهت، تا نفر بعدی از شواهد شروع کند.

دروازه‌های ابری نقطه-به-سایت انتخاب را آشکار می‌کنند: نمایه دانلودشده یا از SSTP روی 443 یا از IKEv2 روی 500 و 4500 استفاده می‌کند، و باید فقط همان یکی را که نمایه واقعاً برمی‌گزیند باز کنید. PPTP در شبکه‌ای امروزی ارزش استثنای GRE را ندارد، چون اپراتورهای موبایل اغلب پروتکل 47 را بدون توجه به فایروال شما می‌اندازند. پیش از بستن تیکت تأیید کنید که قاعده با پورت در پیکربندی سرور می‌خواند، فیلد پروتکل جایی که خانواده به آن نیاز دارد تنظیم شده است، و مقصد دروازه است نه هر آدرسی.

مقالات مرتبط