Адрес peer в PPP или крайна точка на VPN: кое влиза във via

Един ред на 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 зад нея, трябва и входният контекст и обратният път да съвпадат. Когато не съвпадат, поправете собствеността на маршрута, вместо да разхлабвате проверката за цялата машина.