VPN між майданчиками на основі маршрутів і на основі політик: у чому різниця
IPsec на основі політик вибирає трафік селектором; на основі маршрутів надсилає його через інтерфейс тунелю. Обидва досі потребують правил брандмауера й зворотного маршруту.
Обидва проєкти захищають той самий трафік тією самою машинерією IPsec і різняться тим, що вирішує, який пакет увійде в тунель. У з’єднанні на основі політик це роблять узгоджені селектори трафіку; у з’єднанні на основі маршрутів — маршрут, що вказує на інтерфейс тунелю. Змішування двох дає знайому гілку підтримки, де тунель повідомляє про встановлення, а застосунок нікуди не дістається. Різниця найважливіша, коли ви додаєте мережу, запускаєте протокол маршрутизації або зневаджуєте шлях, який тихо виходить через неправильний вихід.
Два способи вирішити, що потрапляє в тунель
VPN на основі політик будує політику безпеки, що відповідає префіксам джерела й призначення, а потім шифрує все, що підходить. Партнер має узгодити сумісні селектори, тому дійсний обсяг зрештою стає перетином того, що запропонували обидві сторони. Ніщо за межами цього перетину не захищене, хоч би що казала таблиця маршрутизації.
VPN на основі маршрутів створює інтерфейс, що представляє тунель, і дозволяє таблиці маршрутизації надсилати в нього трафік. Демон IKE досі встановлює стан і політику для кожного інтерфейсу, і це та деталь, яку пропускають, коли вирішують, що маршрути замінили шифрування. Обидва проєкти шифрують за допомогою IPsec; різниться лише механізм вибору.
Читайте порівняння нижче як набір ознак збою, а не як турнірну таблицю, бо жоден стовпець не перемагає сам по собі.
| Aspect | Policy-based | Route-based |
|---|---|---|
| What selects traffic | Negotiated selectors | A route into the tunnel interface |
| Adding a network | Edit selectors on both peers | Add a route, widen the selector once |
| Dynamic routing | Awkward to run over the tunnel | Runs over the interface directly |
| Typical failure | Tunnel up, host outside the selector | Tunnel up, no route or wrong source |
На основі політик: селектор — це договір
Селектори узгоджують, а не просто налаштовують. Запропонуйте 10.10.0.0/16 з одного боку і 10.10.1.0/24 з іншого, і асоціація охопить те, на чому зупинилися переговори, а всі інші хости залишаться зовні.
Читайте встановлений стан, а не файл конфігурації. На партнері Linux власні таблиці ядра є основною істиною, і вони показують, що пережило переговори. Політика, яка називає правильні префікси без відповідного стану, означає, що асоціація так і не піднялася. Стан у парі з політикою для неправильного префікса — це протилежна проблема, і вона дає тунель, який виглядає здоровим, поки одна підмережа нікуди не дістається.
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sasПорівняйте обидва виводи з префіксами, які, на вашу думку, ви захищаєте. Це єдине порівняння вирішує більшість повідомлень про робочий тунель із недосяжним сервером. Воно також указує, якого партнера змінювати, бо невідповідність зазвичай видно лише в одному напрямку.
На основі маршрутів: інтерфейс — це договір
Інтерфейс XFRM дає тунелю ім’я та ідентичність, і трафік досягає його, бо так каже таблиця маршрутизації. Кілька віддалених префіксів тоді стають проблемою маршрутизації, а не проблемою селектора, і протокол маршрутизації може їх анонсувати. Це справжній виграш, а не шифрування.
Інтерфейс не усуває потреби в політиці. Демон встановлює правила для кожного інтерфейсу, прив’язані до ідентичності інтерфейсу, тому пакет, що прийшов на неправильний інтерфейс, усе одно не проходить. Адреса джерела, яку партнер не прийме, теж не проходить, навіть із ідеальним маршрутом. На основі маршрутів означає, що маршрут вирішує вхід, а не що політика зникла.
sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10Стежте за лічильниками інтерфейсу, коли маршрут уже на місці. Маршрут існує, а лічильники стоять на нулі — це означає, що ніщо не зіставляється в тунель, і зазвичай указує на відсутній стан, а не на відсутній маршрут.
Де ці два проєкти справді розходяться
Додавання мережі — найчистіша перевірка того, яка модель вам підходить. Проєкт на основі маршрутів додає маршрут і розширює селектор щонайбільше один раз, тоді як проєкт на основі політик редагує пари префіксів на обох партнерах і повторно узгоджує. Дві стабільні підмережі роблять це редагування тривіальним, а двадцять перетворюють його на проєкт.
Жодна модель не замінює брандмауер, і порівняння зазвичай зупиняються до цього моменту. Широкий селектор або широкий маршрут вирішують, що шифрується, а не що дозволено.
Поведінка MTU на практиці теж різниться. Інкапсуляція зменшує корисне навантаження, а інтерфейс на основі маршрутів несе власний MTU, тому обмеження MSS на обох шлюзах уникає симптому чорної діри, коли малі відповіді приходять, а великі зникають. Тунелі на основі політик упираються в ту саму стіну з іншого боку, бо селектор нічого не каже про розмір пакета. Задавайте обмеження свідомо, а не звинувачуйте партнера.
Перехід без втрати зворотного шляху
Запишіть наявні пари префіксів, перш ніж щось змінювати, потім перенесіть один шлях застосунку і простежте його від початку до кінця. Встановлений тунель — не той самий тунель, що пересилає, і різниця проявляється в напрямку відповіді.
Коли партнери з’єднуються, а хости LAN ні, перевірте зворотний маршрут і адресу джерела, яку використає віддалений хост. Хост із двома інтерфейсами може відповісти не з того, і жодна зміна селектора це не виправить. Захопіть трафік на обох кінцях, перш ніж редагувати алгоритми.
ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-connsТримайте шлях керування, що не залежить від тунелю, поки працюєте. Відкат легший, коли власний доступ шлюзу не їде тим з’єднанням, яке ви зневаджуєте.