pull-filter در OpenVPN بیشتر از مسیری که در نظر داشتهاید تطبیق میدهد
pull-filter متن شما را بهصورت پیشوند با گزینههای فشاردادهشده مقایسه میکند، بنابراین route هم route-gateway و route-ipv6 را میگیرد. اول فعلها را بررسی کنید، بعد مسیرها.
یک خط اضافه میکنید تا مسیر پیشفرض محلی خود را نگه دارید، و بعد از آن تونل دیگر به سرور DNS داخلی نمیرسد. آن خط pull-filter ignore "route" بود، که معنایش «این مسیر را نادیده بگیر» نیست. معنایش «هر گزینهٔ فشاردادهشدهای که متنش با آن پنج حرف شروع میشود را دور بریز» است، و روی یک سرور معمولی این شامل route-gateway، route-metric و route-ipv6 همراه با خود مسیرها میشود. فهرست بررسی زیر همان چیزی است که پیش از دستزدن به پروفایلی که فرد دیگری باید استفاده کند، اجرا میکنم.
فیلتر فقط بر گزینههای فشاردادهشده اثر میگذارد
pull-filter فقط روی خطوط گزینهای کار میکند که سرور پس از برقراری تونل میفرستد، و روی هیچ چیز دیگری. گزینههای نوشتهشده در فایل محلی شما از آن تأثیر نمیگیرند، و ترافیک برنامهها هم. اگر امید داشتید جلوی استفادهٔ یک فرایند از تونل را بگیرید، این کاملاً ابزار اشتباهی است و هیچ ترکیبی از فیلترها آن کار را نمیکند.
این دامنه مفید است، چون یعنی میتوانید پیکربندی سرور را دستنخورده بگذارید و با این حال بخشی از آن را محلی رد کنید. این هم محدودیتی است که ارزش نوشتن در تیکت را دارد: فیلتر تغییر میدهد این کلاینت چه چیزی را میپذیرد، نه سرور چه چیزی را ارائه میدهد. روی کاربران دیگر همان پروفایل اثری ندارد. با رفتن به کلاینتی که این گزینه را پیادهسازی نمیکند هم دوام نمیآورد، که پیش از ساختن یک گردش کار روی آن ارزش دانستن دارد.
پیش از نوشتن الگو تأیید کنید سرور واقعاً چه میفرستد. در سطح جزئیات بالا کلاینت رشتهٔ گزینههای فشاردادهشدهای را که دریافت کرده چاپ میکند، و این تنها منبع صادق برای متن دقیقی است که با آن تطبیق میدهید:
sudo openvpn --config /etc/openvpn/corp.ovpn --verb 4
sudo grep -n 'pull-filter' /etc/openvpn/corp.ovpn
خط فشاردادهشده را فهرستی از گزینههای جداشده با کاما بخوانید، و توجه کنید که نام گزینهها و آرگومانهایشان با فاصله جدا میشوند. متن فیلتر شما با همان جریان مقایسه میشود، به همین دلیل در گام بعد فاصلهها اینقدر مهماند.
تطبیق یک پیشوند است، پس فاصلهها همهٔ بازی هستند
مقایسه یک پیشوند رشتهای است، نه نام گزینهٔ تجزیهشده. بنابراین "route" با route-gateway 10.8.0.1، route-ipv6 2001:db8::/32 و route-metric 100 تطبیق مییابد. افزودن یک فاصله در انتها آن را به خانوادهای که احتمالاً منظورتان است محدود میکند، و پیشوند کامل آن را بیشتر به یک مقصد مشخص محدود میکند.
| Filter text | What it actually matches | Typical outcome |
|---|---|---|
"route" | Every option beginning with those letters | Routes, gateway, metric and IPv6 routes all dropped |
"route " | Route entries only, not the hyphenated siblings | The routes go, the rest survives |
"route 10.60." | A single destination range | The narrowest rule, and the easiest to audit |
"dhcp-option DNS" | Pushed DNS settings | Resolver stays local, internal names stop resolving |
ردیف آخر همانی است که آدمها را در کار تونل تقسیمشده گیر میاندازد. نگهداشتن resolver خودتان انتخاب مشروعی است، و یعنی هر نام داخلی اکنون به resolverی وابسته است که منطقهٔ خصوصی را نمیبیند. این پیامدی است که آگاهانه پذیرفته میشود، نه عارضهای که در تولید کشف شود.
تطبیق پیشوندی همچنین یعنی یک قاعده میتواند بعداً بیصدا گسترده شود. وقتی سرور گزینهٔ تازهای اضافه میکند که با متن شما شروع میشود، فیلتر شما بدون اینکه کسی پروفایل را ویرایش کند بر آن اعمال میشود. این همان حالت شکستی است که باید در برابر آن طراحی کرد، و کاهش آن تطبیق دادن هرچه بیشتر گزینه است، نه هرچه کمتر.
سه فعل با سه نتیجهٔ متفاوت
accept، ignore و reject سه املای یک ایده نیستند. آنها در اینکه کلاینت با یک تطبیق چه میکند و اینکه کسی بویی میبرد یا نه تفاوت دارند.
ignore گزینهٔ منطبق را بیصدا دور میریزد، که برای تنظیمی که آگاهانه جایگزین کردهاید میخواهید. reject آن را دور میریزد و کلاینت را به شکایت وامیدارد، که وقتی میخواهید نبودنش در گزارش دیده شود نه بعداً کشف شود میخواهید. accept شکل مثبت است، وقتی فهرست مجاز میسازید نه وقتی گزینههای جداگانه را حذف میکنید.
هر فعلی که به کار ببرید، فیلترها به ترتیب ظهورشان اعمال میشوند، پس دو قاعدهٔ همپوشان نتیجهای وابسته به ترتیب میدهند که بازبینیاش بسیار سخت است. برای هر نیت یک قاعده نگه دارید و مشخصترین متن را در هرکدام بگذارید. اگر فهرست مجاز میخواهید، چند قاعدهٔ accept را به تودهای از قاعدههای ignore که همان را جمع میزنند ترجیح دهید. آنگاه بازبینها میتوانند فایل را از بالا به پایین بخوانند و نتیجه را پیشبینی کنند، و این تنها آزمونی است که مقیاس میگیرد.
مسیر و resolver اعمالشده را بررسی کنید، نه پروفایل را
فیلتری که در فایل درست به نظر میرسد باز هم میتواند تونلی برایتان بگذارد که هیچ چیز مفیدی مسیریابی نمیکند. اثر را روی سیستم در حال اجرا بررسی کنید، جایی که گزینههای فشاردادهشده از قبل اعمال یا دور ریخته شدهاند:
ip route show default
ip route show | grep -c 'proto static'
resolvectl status | grep -A4 'Link.*tun0'
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://intranet.example.internal/
دو خط اول به شما میگویند آیا مسیر پیشفرض فشاردادهشده رسیده است و چند ورودی ایستا جان سالم به در برده است. پرسوجوی resolver نشان میدهد رابط تونل واقعاً از کدام سرور استفاده میکند، و معمولاً همانجاست که غافلگیری DNS ظاهر میشود. خط آخر به تنها پرسشی پاسخ میدهد که برای کاربر اهمیت دارد.
وقتی آنجا هستید هر دو جهت را آزمایش کنید. قاعدهای که اینترنت محلی شما را کار میاندازد اما حل نام داخلی را بیصدا میشکند از بررسی سطحی میگذرد و در نخستین کار واقعی شکست میخورد، پس یک منبع داخلی و یک سایت عمومی را در همان آزمون بگنجانید.
استثنا و صاحبش را ثبت کنید
فیلتر استثنایی بر طراحی اپراتور است، پس آن را با دلیل و نقطهٔ بازبینی بنویسید. «مسیرهای فشاردادهشده را برای حفظ پیشفرض محلی نادیده میگیرد» قابل بازبینی است؛ خطی خالی در پروفایل نه، و نفر بعدی آن را پاک میکند یا با حدس گسترش میدهد.
نسخه اینجا هم مهم است. رفتار تطبیق و نحو دقیق پذیرفتهشده در OpenVPN 2.4، 2.5 و 2.6 اصلاح شدهاند، پس الگو را با راهنمای نسخهای که توزیع میکنید تأیید کنید نه با نوشتهٔ انجمن دربارهٔ نسخهٔ قدیمیتر. راهنمای OpenVPN 2.6 این گزینه و قاعدهٔ تطبیقش را مستند میکند.
در پایان، استثنا را با کسی که سرور را اداره میکند توافق کنید. فیلتری در سمت کلاینت که با سیاست عامدانهٔ سرور تناقض دارد یک رخداد پشتیبانی است که منتظر بازرسی بعدی است، و حل آن پیش از ارسال پروفایل بسیار ارزانتر از بعد از آن است که کسی متوجه شود مسیرها غایباند.