Два WireGuard peer-а споделят диапазон: кой получава пакета
Припокриващите се диапазони се решават от най-специфичния префикс, а не от реда. Проверете маршрута първо, после списъка с peer, преди да разширявате каквото и да е.
Два peer-а изброяват диапазони, които се допират, и трафикът стига до грешния. Нищо не е повредено: WireGuard избира peer, като съпоставя дестинацията с конфигурираните диапазони, и най-специфичното съвпадение печели. Преди да разширите нещо, решете кой peer трябва да притежава кой префикс.
Най-дългият префикс печели в WireGuard
Всеки запис на peer носи набор от префикси за дестинация. Когато пакет бъде насочен към интерфейса, реализацията търси записа с най-специфичния съвпадащ префикс — същото правило, което прилага таблицата за маршрутизация. Затова /24 побеждава /16, който го съдържа, и по-тесният peer получава трафика.
Конфигурациите road-warrior използват това умишлено. Един peer притежава широк диапазон за даден обект, а отделните хостове се изрязват със записи /32, които принадлежат на други peer-и. Моделът работи, защото изрязванията са по-специфични, а не заради подредбата.
Запишете собствеността като таблица от префикс и peer. Ако два записа описват един и същ префикс, конфигурацията вече не изразява намерение, а изразява надпревара.
Операционната система избира първо интерфейса
WireGuard избира само сред peer-ите на един интерфейс. Кой интерфейс получава пакета се решава по-рано, от таблицата за маршрутизация на хоста, и втори маршрут по подразбиране или остарял маршрут може да изпрати трафика някъде, където списъкът с peer-и никога не го вижда. Затова диагностика на ниво peer може да е вярна и пак да не обяснява отказа. Проверете маршрута за дестинацията, преди да четете конфигурацията на peer-а, защото маршрут, сочещ към физическия интерфейс, заобикаля целия въпрос.
Инструментът обикновено инсталира тези маршрути от диапазоните на peer-ите, което означава, че промяна в списъка на един peer може тихо да пренасочи трафик, който преди е принадлежал на друг. Редакцията на peer следователно е промяна в маршрутизацията под прикритие. Прегледайте двете наведнъж, иначе ще поправите едното и ще счупите другото.
Входящите пакети се проверяват по източник
Списъкът с диапазони изпълнява двойна роля. За изходящия трафик избира peer по дестинация, а за входящия разрешава адрес на източник. Пакет, пристигнал от адрес извън диапазоните на този peer, се отхвърля, преди която и да е защитна стена да го види.
Тази асиметрия лесно се пропуска, когато четете едната страна на конфигурацията. Peer, който може да достигне подмрежа, не получава с това право да изпраща от тази подмрежа, и двете посоки се налагат от различни проверки.
Тясната собственост на източника превръща това в предимство. Дайте на всеки peer /32 за собствения му адрес и защитната стена по-надолу ще има надежден източник за съпоставяне, вместо общ за групата диапазон, който всеки член би могъл да претендира.
Дублиращите се диапазони не са failover
Присвояването на един и същ префикс на два peer-а не създава балансьор на натоварването или резервен път. Няма проверка на здравето и няма сесийна принадлежност: печелещият запис се определя от вътрешната подредба на реализацията, което не е договор, на който да проектирате. Ако ви трябват алтернативни изходи, изразете ги там, където е дефиниран изборът. Политика за маршрутизация, метрика или двойка различни префикси с документиран собственик на всеки дават поведение, което можете да предвидите и тествате.
Разширяването на диапазон, за да се поправи несвързан отказ, е другата честа грешка. То отмества трафика от peer-а, който е работел, и новият симптом идва, преди старият да е разбран.
Проверете избора преди редакция
Три команди отговарят на трите въпроса по ред. Първата изброява диапазоните, които всеки peer претендира. Втората показва кой интерфейс хостът би използвал за дадена дестинация. Третата показва живото състояние на peer-ите, след като трафикът е протекъл.
wg show wg0 allowed-ips ip route get 10.66.8.20 wg show wg0 ip rule show
Изпълнете ги преди и след промяна и сравнете. Ако изходът на маршрута се е променил, но трафикът все още пристига при грешния peer, списъците с префикси се припокриват по начин, който още не сте описали. Ако изходът на маршрута не се е променил, конфигурацията на peer-а никога не е била това, което се е разглеждало.
Запишете дестинацията, избрания интерфейс и избрания peer в заявката. Тази тройка прави припокриването проверимо по-късно и е много по-полезна от екранна снимка на конфигурацията.