کاربر MikroTik VPN بیش از اندازه دسترسی میگیرد: دامنه را به یک میزبان و یک درگاه محدود کنید
یک پروفایل PPP میتواند نشانی تونل تخصیصیافته را در فهرست نشانی قرار دهد و یک زنجیرهٔ پرش میتواند پیش از حذف، یک میزبان و یک درگاه را مجاز کند.
تونل بالا میآید، ورود موفق میشود و هر میزبان روی شبکه پاسخ میدهد. این یک VPN خراب نیست؛ این یک VPN بدون مدل مجوز است. RouterOS حساب را احراز هویت میکند و سپس بستههای آن را مانند بستههای هر کس دیگری مسیریابی میکند، بنابراین دیوار آتش باید محدودیت را فراهم کند. افزودن این محدودیت بدون شکستن ورود، تمام کار است.
احراز هویت جایی پایان مییابد که مجوز آغاز میشود
وقتی نشست PPP بالا باشد، بستههای کارخواه مانند ترافیک هر رابط دیگری وارد زنجیرهٔ forward میشوند. اگر خطمشی forward روتر سهلگیرانه باشد، مشاور در هنگام ورود همان سهلگیری را به ارث میبرد. حساب هرگز دامنهای نداشت، پس چیزی روی حساب برای تغییر نیست. مجموعهٔ قواعد برای کارمندان نوشته شده بود و نشست جدید بهسادگی به آن پیوست.
پیش از نوشتن هر چیزی بررسی کنید درخواست به کدام مسیر مربوط است. ترافیک به میزبانهای پشت روتر از forward میگذرد، در حالی که ترافیک به خود روتر، از جمله winbox و SSH، از input میگذرد. دامنهای که تنها forward را پوشش میدهد، دستگاه را برای همان کارخواه باز میگذارد.
هر دو زنجیره به تصمیم نیاز دارند، حتی اگر تصمیم بستن input باشد. این انتخاب به درخواست دسترسی تعلق دارد، نه به اندیشهای پس از آن.
نشست را به یک فهرست نامدار پیوند دهید
یک پروفایل PPP میتواند نشانیای که میدهد را هنگام آغاز نشست در فهرست نشانی نامدار قرار دهد. این کار نشانی موقت تونل را به چیزی تبدیل میکند که دیوار آتش میتواند با نام تطبیق دهد، و ورودی هنگام پایان نشست ناپدید میشود. سپس حساب دامنه را از پروفایل خود به ارث میبرد، نه از قاعدهای که نشانی را سختکد میکند.
نخست پروفایل را بسازید، سپس secret را صریحاً به آن پیوند دهید. secret که هنوز به پروفایل پیشفرض اشاره میکند، مشکل اصلی را بازتولید میکند.
پروفایل و فهرست را طوری نامگذاری کنید که وظایفشان آشکار باشد و هر دو را با ارجاع درخواست توضیح دهید. یک پروفایل میتواند به چند نفر با همان دامنه خدمت کند، در حالی که فهرست هنوز هر نشست زنده را مشخص میکند. بازبینی این ارزانتر از یک قاعده به ازای هر نفر است.
/ppp profile add name=scoped-consultant remote-address=consultant-pool address-list=vpn-scoped-clients
/ppp secret add name=consultant password=... service=ovpn profile=scoped-consultant
سرویس مجاز را در یک فهرست ثبت کنید
سرور مجاز را در فهرست نشانی خودش بگذارید، بهجای جاسازی نشانی در یک قاعدهٔ فیلتر. فهرست را میتوان بازرسی، گسترش و اظهارنظر کرد، و قاعدهای که از آن استفاده میکند با جابهجایی سرور تغییر نمیکند. یک ورودی واحد زیادهروی به نظر میرسد تا وقتی میزبان دوم بیاید، که معمولاً میآید.
وقتی نشانی پویا یا متعادلشده است فهرست را تطبیق دهید، و وقتی رزرو و پایدار است خود نشانی را مستقیم تطبیق دهید. هر دو انتخاب اگر توضیح نام سرویس و مالک را ببرد روشن خوانده میشود.
پروتکل و درگاه را نیز به همراه میزبان محدود کنید. accept برای میزبانی بدون محدودیت درگاه همهٔ سرویسهایی که آن میزبان اجرا میکند را باز میکند، که از آنچه بیشتر درخواستهای دسترسی میخواهند گستردهتر است. درگاه بخشی از مجوز است، نه جزئیاتی که بعداً افزوده شود.
/ip firewall address-list add list=vpn-targets address=10.0.0.10 comment="consultant RDP target"
پرش را پیش از هر accept گسترده بچینید
یک قاعدهٔ پرش ترافیک ارسالشده از فهرست محدود را به زنجیرهای خصوصی میفرستد که کل خطمشی در سه خط جا میشود. قاعدهٔ نخست مقصد و درگاه مجاز را میپذیرد و قاعدهٔ آخر بقیه را حذف میکند. پرش باید بالاتر از هر accept گسترده در forward باشد، زیرا پذیرش زودتر یعنی پرش هرگز اجرا نمیشود. accept مربوط به established و related را پیش از پرش نگه دارید تا ترافیک بازگشت همچنان جریان یابد.
بررسی کنید هیچ قاعدهٔ fasttrack نتواند این ترافیک را از زنجیرهٔ محدود عبور دهد. fasttrack بقیهٔ مسیر فیلتر را دور میزند و نشست محدودی که fasttrack شود اصلاً محدود نیست.
اگر سرویسهای خود روتر باید دسترسناپذیر باشند، تصمیم را برای زنجیرهٔ input تکرار کنید. دامنهای که ترافیک ارسالشده را مسدود میکند و winbox را باز میگذارد تنها نیمهکاره است.
/ip firewall filter
add chain=forward action=jump jump-target=scoped-vpn src-address-list=vpn-scoped-clients
add chain=scoped-vpn action=accept protocol=tcp dst-address-list=vpn-targets dst-port=3389
add chain=scoped-vpn action=drop
با شمارندهها و عضویت در فهرست بررسی کنید
از کارخواه، سرویس مجاز و سرویسی را که باید شکست بخورد بیازمایید، سپس آمار قواعد را روی روتر بخوانید. شمارندههای accept و drop نشان میدهند هر بسته کدام مسیر را رفته است، چیزی که کارخواه نمیبیند. همچنین تأیید کنید نشانی نشست زنده در فهرست محدود پدیدار شده است.
فهرست خالی یعنی حساب روی پروفایل دیگری است یا پروفایل تنظیم فهرست نشانی خود را از دست داده است. شمارندهٔ drop که بالا میرود در حالی که سرویس مجاز شکست میخورد یعنی مقصد یا درگاه با آنچه کارخواه میفرستد مطابقت ندارد.
پیش از نتیجهگیری، همان سرویس را با نام و با نشانی بیازمایید. شکست در تفکیک نام از سمت کارخواه دقیقاً مانند درگاه مسدود دیده میشود. سپس پروفایل، هر دو فهرست و تنها سرویس مجاز را در درخواست دسترسی ثبت کنید تا بازبینی بعدی مقایسه کند نه بازسازی.
/ip firewall filter print stats where chain=scoped-vpn
/ip firewall address-list print where list=vpn-scoped-clients