کلید قطع pf در macOS برای OpenVPN: قواعدی که بسته می‌شوند

در macOS، یک کلید قطع تنها به اندازه سیاست فیلتر بسته پشت آن خوب است، و pf همان بخشی است که آن سیاست را اجرا می‌کند. سیاست باید همزمان دو کار متضاد انجام دهد: بگذارد کلاینت به سرورش برسد تا تونلی بتواند وجود داشته باشد، و جلوی خروج مستقیم هر چیز دیگر را بگیرد. بیشتر مجموعه‌های قواعد منتشرشده دومی را انجام می‌دهند و اولی را فراموش می‌کنند، بنابراین دستگاه به جای به دست آوردن محافظت، اتصال را از دست می‌دهد. نسخه‌ای که کار می‌کند نقطه پایانی، حل‌کننده و تونل را نام می‌برد، و نه چیز بیشتری.

فیلتر بسته چه چیزی را می‌تواند تعیین کند و چه چیزی را نمی‌تواند

pf به واسط‌ها، نشانی‌ها، شماره پروتکل‌ها و درگاه‌ها نگاه می‌کند و همان‌جا می‌ایستد. هرگز نمی‌فهمد کدام فرایند یک سوکت باز کرده است، بنابراین اجازه‌ای که برای یک برنامه نوشته شده به اجازه‌ای برای هر برنامه‌ای تبدیل می‌شود که می‌تواند به همان درگاه برسد. این‌گونه یک استثنای سخاوتمندانه UDP کلید قطع را به شبکه‌ای معمولی بازمی‌گرداند. انسداد آگاه از برنامه متعلق به کلاینت یا یک افزونه سیستم است، نه این فایل.

فیلتر مسیر هم نمی‌سازد. وقتی کلاینت می‌افتد، مسیر پیش‌فرض ممکن است هنوز به تونلی مرده اشاره کند، و pf آن را به بسته‌های مسدود تبدیل می‌کند نه بازگشتی خاموش به Wi-Fi. انسداد نتیجه مطلوب است، نه نقصی که باید دورش زد.

ترتیب بیش از متن قاعده نتیجه را تعیین می‌کند. بدون quick، pf پس از یک تطابق به ارزیابی ادامه می‌دهد و آخرین قاعده منطبق برنده می‌شود، بنابراین یک عبور گسترده در پایین، استثناهای دقیق بالای خود را باطل می‌کند. علامت‌گذاری عبورها با quick نخستین تطابق را نهایی می‌کند، که نویسنده سیاست معمولاً منظور دارد.

ابتدا واقعیت‌های واسط و نقطه پایانی را بخوانید

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

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

route -n get default
ifconfig -l
scutil --nc list

فرمان اول واسطی را نام می‌برد که اکنون برنده است، دومی هر دستگاه شناخته‌شده برای هسته را فهرست می‌کند، و سومی پیکربندی‌های VPN را که سیستم می‌تواند اجرا کند نشان می‌دهد. آن پاسخ‌ها را بنویسید، سپس نشانی و درگاه سرور را از پیکربندی خود کلاینت بخوانید.

مجموعه قواعد را حول مسیر تونل بنویسید

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

set skip on lo0
block all
pass out quick on utun0
# maintain this line when the server address changes
pass out quick on en1 inet proto udp to 203.0.113.10 port 1194
# only the resolver the client uses before the tunnel exists
pass out quick on en1 inet proto udp to 192.0.2.53 port 53
pass out quick on en1 inet proto udp from any port 68 to any port 67
pass out quick on en1 inet proto udp to 224.0.0.251 port 5353

خط DHCP وجود دارد چون Mac پیش از داشتن نشانی، نشانی می‌خواهد، بنابراین درخواست از درگاه 68 به سمت درگاه 67 بدون نشانی مبدأ قابل استفاده خارج می‌شود. خط multicast به سیستم اجازه می‌دهد قضاوت کند که پیوند بی‌سیم ارزش استفاده دارد یا نه، و حذف آن دستگاهی می‌سازد که در شبکه‌ای سالم هیچ اتصالی گزارش نمی‌کند. خط نقطه پایانی چیزی است که به OpenVPN اجازه می‌دهد اصلاً به سرورش برسد؛ بدون آن، block all دست‌دادن بیرونی را می‌اندازد و تونل هرگز بالا نمی‌آید. خط حل‌کننده باریک‌تر از یک اجازه عمومی DNS است، چون یک نشانی و یک درگاه را نام می‌برد نه هر پرس‌وجویی که دستگاه انجام می‌دهد.

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

تونل را پایین بیاورید، سپس راه‌اندازی مجدد کنید

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

sudo pfctl -n -v -f /etc/pf.conf
sudo pfctl -f /etc/pf.conf
sudo pfctl -e
sudo pfctl -s rules
sudo pfctl -s Anchors
sudo pfctl -a <anchor> -s rules
sudo pfctl -s info

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

راه‌اندازی مجدد همان بخشی است که مردم از آن می‌پرند. macOS در بوت /etc/pf.conf را می‌خواند، اما خواندن فایل با روشن کردن فیلتر یکی نیست، بنابراین مجموعه قواعدی که اکنون کار می‌کند ممکن است پس از راه‌اندازی مجدد غیرفعال باشد. سپس sudo pfctl -s info را اجرا کنید و تأیید کنید که خط وضعیت فیلتر را فعال گزارش می‌کند.

خروج و مسیر راه‌اندازی مجدد را صادق نگه دارید

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

sudo pfctl -d
sudo pfctl -f /etc/pf.conf.previous
sudo pfctl -s rules

ماندگاری به یک daemon راه‌اندازی نیاز دارد که pfctl -e را اجرا کند و فایل شما را در بوت بارگذاری کند. با آن مثل هر کار ممتاز دیگری رفتار کنید: مسیرهای مطلق، گزارشی که بعداً بخوانید، و آزمونی روی دستگاهی که از نظر فیزیکی به آن دسترسی دارید. daemonی که بی‌صدا شکست می‌خورد دستگاه را بی‌محافظ و عادی‌نما رها می‌کند.

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