Адреса peer у PPP чи кінцева точка VPN: що писати в via

Порівняйте читання PPP-інтерфейсу як підмережі з читанням його inet і peer як двох кінців каналу та подивіться, який наступний перехід може прийняти таблиця політик.

Один рядок на PPP-інтерфейсі вирішує більшу частину суперечки про маршрутизацію на машині VPN: внутрішня адреса і peer, надрукований поруч. Прочитайте цю пару як крихітну підмережу, і ви шукатимете шлюз, якого не існує. Прочитайте її як два кінці одного каналу, і наступний перехід стане очевидним. Порівняння тут між цими двома читаннями, бо кожна таблиця, збудована потім, успадковує обране. Нічого про зовнішню кінцеву точку VPN не вирішує жодне з них.

Два читання одного рядка інтерфейсу

Візьміть сеанс, у якому інтерфейс повідомляє inet 10.64.3.9 peer 10.64.3.1/32. Читання як підмережі поводиться з 10.64.3.9 як з самотнім хостом на острові /32, а потім шукає маршрутизатор, щоб досягти чогось за його межами. Оскільки єдина інша адреса на каналі — це peer, таке читання зрештою пропонує сам 10.64.3.9 як шлюз, що є замкненим колом.

Читання як кінцевої точки — документоване. На інтерфейсі «точка-точка» peer називає віддалений кінець цього єдиного каналу, тому 10.64.3.1 є придатним наступним переходом, а 10.64.3.9 завжди лише адреса джерела.

Ця різниця визначає, що може стояти в via. Запис туди локальної адреси дає маршрут, який ядро не може зіставити із сусідом, тому запис або не проходить перевірку, або ковтає трафік, виглядаючи при цьому в списку цілком здоровим. Peer працює тому, що це справжній пункт призначення на каналі. Обидва читання згодні щодо зовнішньої кінцевої точки VPN, яка є цілком окремою сутністю: до неї дістаються через underlay, а не через тунель, який вона завершує.

Що сеанс уже встановив

Перш ніж писати власну таблицю, виведіть те, що прийшло разом із каналом. Підтримувана інтеграція PPP зазвичай встановлює маршрут пристрою та маршрут до peer під час налаштування сеансу, і ці два записи вже містять правильне читання.

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

Маршрут пристрою вигляду 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 не несе шлюзу, бо сам інтерфейс є шляхом. Маршрут, що називає peer через via, — це інший об'єкт з іншим часом життя, і він зникає, коли сеанс падає. Копіювання будь-якої з двох форм у постійну таблицю без перевірки того, як вона перевстановлюється, — звичайна причина, чому робочий тунель втрачає маршрут після перепідключення.

Порівняйте два списки, а не покладайтеся на пам'ять. Якщо маршрут до peer є в main, а ваша додаткова таблиця порожня, ви дізналися те, чого рядок адреси вам ніколи не казав.

Правило і таблиця — окремі рішення

Вибір таблиці та її заповнення — незалежні кроки, і порівняння тут важливе, бо під час налагодження ці двоє часто плутають. Правило, що надсилає позначений трафік до таблиці 100, нічого не робить, якщо в таблиці 100 немає відповідного маршруту, а добре заповнена таблиця недосяжна, якщо на неї не вказує жодне правило.

Половина маршруту за замовчуванням — не маршрут за замовчуванням. Один 0.0.0.0/1 покриває нижню половину простору IPv4, тому політиці, яка має намір захопити все, потрібен і відповідний 128.0.0.0/1, або справжній default. Прочитати робочу конфігурацію та скопіювати одну з двох половин — так люди й отримують петлю маршрутизації, що ламається лише на певних адресах.

Залиште навмисні винятки для адрес, які мають залишитися в LAN, і вирішіть, що станеться, коли пошук нічого не знаходить у вибраній таблиці. Явний резервний маршрут легше осмислити, ніж порожня таблиця, яка повертає недосяжний результат і змушує застосунок виглядати зламаним, а не спрямованим не туди.

Задайте пошуку те питання, яке задає ваш застосунок

ip route get розв'язує шлях; ip route show виводить збережені записи, і ці двоє можуть розходитися, хоч жоден не є хибним. Укажіть контекст джерела, бо правила на основі джерела збігаються лише тоді, коли пошук несе джерело.

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

Перша команда ставить питання з боку хоста. Друга додає вхідний інтерфейс, що ближче до того, що переживає перенаправлений трафік, і відповідь часто вказує на іншу таблицю. Жодна з адрес не є живим тестовим сервісом; 198.51.100.23 — це адреса для документації, тож замініть її на хост, який вам дозволено перевіряти.

Навіть правильний пошук доводить лише те, що шлях було обрано. Він нічого не каже про те, чи приймає протилежна сторона трафік або чи може відповідь повернутися тими самими міркуваннями.

Де порівняння перевертається

Трафік хоста і перенаправлений трафік обирають не лише різні пошуки; на зворотному шляху вони зустрічають різні фільтри. Linux застосовує перевірку зворотного шляху за суворішим із значень для всіх інтерфейсів і для приймального інтерфейсу, тому зміна значення одного інтерфейсу може не дати видимого ефекту. Маршрутизація за міткою додає відношення src_valid_mark, у якому мітка має збігатися, щоб джерело вважалося допустимим.

Якщо відповіді зникають, а вихідна маршрутизація виглядає правильно, прочитайте чинні значення, перш ніж їх чіпати, і змінюйте їх лише із заявленої причини політики.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

Обирайте між двома схемами на підставі доказів: якщо застосунок прив'язаний до адреси PPP, достатньо правила джерела й таблиці з маршрутом до peer. Якщо машина перенаправляє трафік для LAN позаду себе, потрібно ще, щоб вхідний контекст і зворотний шлях збігалися. Коли вони не збігаються, виправте належність маршруту, а не послаблюйте перевірку для всієї машини.

Схожі статті