چرا یک مسیر OpenVPN در برابر خطمشی XFRM در strongSwan میبازد
یک مسیر مشخص OpenVPN خطمشی XFRM را نقض نمیکند: مسیر و انتخابگرهای خطمشی را بخوانید، سپس باریک کنید، استثنا بگذارید یا به یک واسط XFRM بروید.
بستهها میتوانند مسیر OpenVPN را دنبال کنند و همچنان توسط یک خطمشی IPsec گرفته شوند، و این ترکیب از هر زاویهای جز زاویه درست مانند یک ایراد مسیریابی به نظر میرسد. Linux مسیر را حل میکند و سپس یک پایگاه داده خطمشی امنیتی جداگانه را مشورت میکند، بنابراین یک مسیر مقصد مشخصتر جای خطمشی XFRM منطبق را نمیگیرد. نشانه آشکار ترافیکی است که میزبان را ترک میکند و هرگز نمیرسد، در حالی که هر دو تونل خود را سالم گزارش میکنند. سه گزینه آن را حل میکند، و اینکه کدام را انتخاب کنید به این بستگی دارد که کدام یک از دو مسیر قرار است آن پیشوند را حمل کند.
دو تصمیم، نه یکی
انتخاب مسیر به یک پرسش تنگ پاسخ میدهد: کدام گام بعدی و کدام نشانی مبدأ باید این بسته را حمل کنند. پایگاه داده خطمشی امنیتی به پرسش دیگری پاسخ میدهد: آیا این بسته به حفاظت IPsec نیاز دارد، و زیر کدام انتخابگرها. هر دو برای همان بسته اجرا میشوند، و برآورده کردن اولی چیزی درباره دومی نمیگوید. به همین دلیل تغییر یک متریک یا افزودن یک مسیر ایستا میتواند نشانه را دستنخورده بگذارد.
یک انتخابگر گسترده IPsec علت معمول است. خطمشیای که از 172.16.0.0/12 حفاظت میکند 172.20.8.0/24 را نیز پوشش میدهد، که مدیر ممکن است قصد داشته باشد از طریق تونل OpenVPN به آن برسد. قصد فقط در جدول مسیریابی وجود دارد، و پایگاه داده خطمشی هرگز از آن خبر نداشت.
این را به عنوان تعارض بین دو مسیر حفاظتی پیکربندیشده ببینید، نه مسابقه بین دو متریک. اصلاح به همان مؤلفهای تعلق دارد که با دامنه اشتباه پیکربندی شده بود.
مسیری را بخوانید که هسته واقعاً انتخاب میکند
با جستجویی که هسته انجام میدهد شروع کنید، شامل نشانی مبدأ و هر قاعده خطمشی که میتواند آن را به جدول دیگری منحرف کند. ممکن است مسیری در جدول اصلی هرگز بررسی نشود اگر قاعدهای قبلی جدول دیگری را انتخاب کند، و تطبیق طولانیترین پیشوند فقط در جدولی اعمال میشود که یک قاعده انتخاب میکند.
ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15
دستور آخر مهم است، زیرا مسیر انتخابشده را همراه با نشانی مبدأیی که هسته استفاده میکرد چاپ میکند. آن خروجی را با انتخابگری که خطمشی IPsec با آن تطبیق مییابد مقایسه کنید. وقتی مسیر به واسط OpenVPN اشاره میکند و خطمشی هنوز با همان جفت تطبیق مییابد، تعارض را بدون حدس بازتولید کردهاید.
دامپها را پیش از رسیدن به یک تیکت از نشانیهای نامرتبط پاک نگه دارید. جدول مسیریابی یک میزبان تولیدی توپولوژی داخلی را حمل میکند، و فقط خطوطی که به پرسش پاسخ میدهند ارزش چسباندن دارند.
خطمشیای را نیز بخوانید که اعمال میشود
فهرست خطمشی جهت، انتخابگرها و قالبی را نشان میدهد که تعیین میکند با بسته منطبق چه میشود. اول جهت خروجی را بخوانید، سپس سمت ورودی را برای ترافیک بازگشت، زیرا یک استثنای یکطرفه اتصالی میسازد که شروع میشود و هرگز کامل نمیشود.
ip -s xfrm policy
swanctl --list-sas
انتخابگرهای فهرست را با پیشوندهایی که اتصال مذاکره کرده مقایسه کنید. غیرفعال کردن نصب مسیر در strongSwan آن خطمشیها را حذف نمیکند، و تغییر یک متریک تغییر نمیدهد که یک خطمشی از کدام جفت مبدأ و مقصد حفاظت میکند. این دو اصلاح نادرست ارزش کنار گذاشتن زودهنگام را دارند، چون مردم اول آنها را امتحان میکنند.
اگر فهرست هیچ خطمشیای برای پیشوند مورد انتظار شما ندارد، مشکل جای دیگری است و جدول مسیریابی احتمالاً راست میگوید. اگر خطمشی گستردهتری دارد که پیشوند را میپوشاند، گیر را پیدا کردهاید.
سه گزینه وقتی هر دو مسیر مشروعاند
باریک کردن انتخابگر IPsec تمیزترین گزینه است وقتی پیشوند گسترده یک راحتی بود نه یک الزام. کاهش انتخابگر ترافیک دور به زیرشبکههایی که واقعاً پشت IPsec هستند تعارض را برای همه میزبانها همزمان برمیدارد، و هزینهاش مذاکره مجدد کلید است نه یک مؤلفه جدید.
استثنای عبور، گزینه جراحی است وقتی انتخابگر گسترده باید بماند. strongSwan از یک اتصال جداگانه پشتیبانی میکند که child آن از حالت pass استفاده میکند، که به هسته میگوید ترافیک منطبق نباید توسط IPsec پردازش شود. نشانی دور loopback آن اتصال را از انتخاب شدن برای همتایان ورودی باز میدارد، و انتخابگرها باید جفت مجاز واقعی را توصیف کنند نه همهچیز.
connections {
openvpn-exception {
remote_addrs = 127.0.0.1
children {
openvpn-exception {
local_ts = 10.44.7.0/24
remote_ts = 172.20.8.0/24
mode = pass
start_action = trap
}
}
}
}
نمونههای پیکربندی strongSwan این نوع خطمشی و قرارداد همتای loopback را مستند میکنند. گزینه سوم یک طراحی مبتنی بر مسیریابی با واسطهای XFRM است که خطمشی را به ترافیک مسیریابیشده از یک واسط نامدار گره میزند نه به یک انتخابگر سراسری. این یک مهاجرت است نه یک تنظیم، و ترافیک باید همچنان انتخابگرهای مذاکرهشده را برآورده کند.
| Option | Use it when | Cost |
|---|---|---|
| Narrow the selector | The broad prefix was convenience | A rekey and a policy review |
| Passthrough child | The broad selector must stay | One exception per intended pair |
| XFRM interface | Policy should follow routing | A design migration |
استثنا را بدون تضعیف بقیه اثبات کنید
پس از بارگذاری تغییر، استثنا و یک مقصد عادی را که باید محافظتشده بماند آزمایش کنید. هر دو جهت را بررسی کنید، سپس تونل OpenVPN را قطع کنید و تأیید کنید با ترافیک استثناشده چه میشود. استثنایی که آن پیشوند را وقتی تونل قطع است بیصدا بهصورت باز میفرستد، تصمیم خطمشیای است که باید آگاهانه بگیرید، نه در میانه یک حادثه کشف کنید.
ثبت کنید کدام پیشوند از کدام مسیر استفاده میکند و چرا. وگرنه مهندس بعدی که یک انتخابگر گسترده ببیند همان بررسی را دوباره باز میکند، و پاسخ در پیام commitای خواهد بود که هیچکس نمیخواند.