Как да различим маршрутна примка от разклащане на маршрут при VPN обекти
Маршрутната примка и разклащащият се маршрут причиняват същата периодична загуба. Три проверки на шлюзовете ги разграничават, преди да промените каквото и да е.
Два обекта, един тунел и отдалечен префикс, който известно време отговаря, а после замлъква. Рефлексът е да го наречем маршрутна примка и понякога това е точно така. Но примката и разклащащият се маршрут дават една и съща жалба, а изискват противоположни поправки: едното е решение за препращане, което никога не завършва, другото е префикс, който непрекъснато напуска таблицата. Три наблюдения ги разделят и можете да съберете и трите от командната линия на шлюза, преди да пипнете филтър или да рестартирате тунел.
Примката се решава хоп по хоп. Обект A избира B за следващ хоп към дестинацията, B избира A за същата дестинация и пакетът изтича по TTL след два курса напред и назад. Разклащането пък се решава от протокола за маршрутизация: префиксът се оттегля, инсталира наново или се заменя с алтернативен следващ хоп, така че някои пакети нямат никакъв маршрут, докато други следват напълно добър.
Трите проверки, които решават въпроса
Не ви е нужен захват на пакети, за да вземете първото решение. Нужни са ви състоянието на префикса в двата края, следващият хоп, който всяка страна избира, и брой хопове, който или се повтаря, или не. Ако префиксът остава инсталиран със същия следващ хоп, докато трафикът се проваля, примката живее в пътя за препращане. Ако префиксът изчезва и се връща, повредата е над препращането и поправката принадлежи на протокола за маршрутизация, а не на статичен маршрут.
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
Едно предупреждение, преди да започнете. Ако четете това през тунела, който прави примка, сесията ви умира в момента, в който смените маршрута. Отворете конзола или път за управление, който не зависи от префикса, който ще поправяте.
Проверка първа: префиксът стабилен ли е или се мята
Питайте ядрото какво е инсталирало, а не какво обещава конфигурационният файл. На Linux шлюз ip route get 10.20.30.40 изпълнява същото търсене, което изпълнява пътят за препращане, включително таблиците с правила, докато ip route show 10.20.30.0/24 показва самия запис. ip monitor route предава всяка промяна в момента на случване, което е най-бързият начин да наблюдавате как префикс пристига и си отива.
На маршрутизатор с FRR или BIRD интересната не е таблицата за препращане. show ip bgp 10.20.30.0/24 връща избрания път и времето му на работа; време на работа, което се нулира на всеки няколко минути, е разклащане, което можете да назовете, а не примка. show ip bgp summary показва състоянието на съседите и броя префикси, така че съсед, който непрекъснато пада, снема вината от пътя за препращане.
Запишете отговора, преди да промените каквото и да е. Стабилност десет минути, докато пинговете се проваляха, и изчезване четири пъти за десет минути водят до различни следващи стъпки. Второто прави всяка теория за статичен маршрут без значение.
Проверка втора: сочи ли следващият хоп обратно в тунела на пристигане
Примката изисква два шлюза да се съгласят. На обекта, който получава пакета, погледнете маршрута, по който пакетът ще излезе: ip route get 10.20.30.40 from 10.10.5.20 с истинския адрес на източника, защото правило за политика може да отговори различно от основната таблица. След това повторете търсенето на обекта, който го е изпратил. Ако всяка страна избере другата за следващ хоп за същия префикс, примката е доказана и никакъв захват няма да добави нищо.
Причината почти винаги е обявление, което не е трябвало да пресича тунела. Маршрут по подразбиране, преразпределен в тунела, агрегат, който покрива собствената подмрежа на отдалечения обект, или статичен маршрут към партньора просто за всеки случай — всички създават същия взаимен следващ хоп. Тунелът може да е напълно установен и пак да пренася трафик в кръг; бележките за препращане на strongSwan описват маршрутната страна на това изискване.
WireGuard заслужава отделна бележка, защото няма обявление, което да обвиним. wg show изброява AllowedIPs за всеки партньор и ядрото приема дестинация за партньор само ако тя попада в този диапазон. Примка там е припокриващ се диапазон AllowedIPs или статичен маршрут, който сочи обратно през интерфейса, така че поправката живее само на тези две места.
Проверка трета: четете броя хопове, не звездичките
traceroute -n -I 10.20.30.40 и mtr -n -r -c 20 10.20.30.40 показват пътя и режимът ICMP често оцелява при филтриране, което изяжда UDP сондите. Примката изглежда като кратка повтаряща се последователност от същите два адреса на шлюзове, като TTL се качва всеки път. А отпадането изглежда като звездички след последния шлюз, който е отговорил, и един тих хоп не е доказателство за нищо.
Когато пътят е двусмислен, четете TTL по жицата. tcpdump -ni any -vv icmp на двата шлюза показва TTL на всеки пакет и адреса на източника на всеки отговор за изтекло време. Ако пакет стигне до отдалечения обект с TTL по-нисък от броя хопове, които пътят може да съдържа, нещо добавя хопове, които traceroute не ви показва, а това се случва, когато защитната стена на един обект отговаря на сонди от името на друг.
Поправете собственика на префикса, после проверете двете посоки
Решете кой обект създава дестинацията и кои транзитни пътища са разрешени, после сменете обявлението или статичния маршрут при този собственик. Да поправите приемащия обект е изкушаващо и обикновено грешно: това скрива примката за един префикс и оставя лошото обявление на мястото му за следващия. Таговете за маршрути, списъците за разпределение и правилата split-horizon съществуват, за да спрат това при източника, и са по-евтини от филтър, който съвпада с един префикс.
След промяната проверете правата и обратната посока поотделно, защото примката може да бъде заменена с черна дупка без видимо подобрение на симптома. Пуснете ip route get от двата края, изпратете трафик от хост, който не е шлюзът, и оставете ip monitor route да работи поне един таймер за задържане, за да не се вземе разклащането за поправка.
Преди да промените каквото и да е, потвърдете тези пет точки: префиксът е стабилен или се мята, следващият хоп в двата края сочи към тунел, броят хопове се повтаря или не, един обект притежава префикса и имате път за управление, който оцелява след промяната. Ако дори една от петте е неизвестна, останалите четири са догадки.