Два WireGuard 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-а. Управо та тројка чини преклапање проверивим касније и много је кориснија од снимка екрана конфигурације.