WireGuard: няма маршруту да партнёра пасля змены падсеткі — два шляхі

Рукапаціск свежы ў wg show, канцавы пункт правільны, ключы ніколі не мяняліся — а ping усё яшчэ кажа, што маршруту да партнёра няма. Вы змянілі падсетку тунеля гадзіну таму. Гэты сімптом — подпіс неадпаведнасці прэфікса, а не праблемы з ключамі: WireGuard завяршыў рукапаціск, а затым скінуў даныя, бо адрас крыніцы больш не адпавядае таму, што прыме партнёр-атрымальнік. Ёсць два разумныя шляхі ўвесці змену падсеткі, і яны ламаюцца ў розных месцах.

Два шляхі ўвесці змену і што кожны каштуе

Варыянт A — перанумарацыя на месцы: адрэдагаваць адрас інтэрфейса, дыяпазоны партнёра, маршруты і кожную копію канфігурацыі, затым перазагрузіць. Варыянт B — пабудаваць другі інтэрфейс на новым прэфіксе побач са старым, перавесці партнёраў і выдаліць стары інтэрфейс пасля таго, як трафік сапраўды пераедзе.

Менавіта напалову ўжыты стан робіць варыянт A небяспечным, бо ён не выглядае зламаным. Інтэрфейс узнімаецца, рукапаціск праходзіць, і толькі шлях даных падае. Варыянт B каштуе больш працы, але трымае працоўны шлях жывым, пакуль вы шукаеце кожную спасылку.

Што павінна рухацца разам на вашым баку

Чатыры рэчы на лакальным хосце апісваюць адну і тую ж падсетку, і змена адной — гэта змена ўсіх: адрас інтэрфейса, AllowedIPs кожнага партнёра, маршрут, які сістэма выкарыстоўвае для гэтых прызначэнняў, і ўсё, што мэнэджар усталёўвае ад вашага імя. З wg-quick апошнія дзве генеруюцца з канфігурацыі кожны раз, калі інтэрфейс узнімаецца, таму састарэлая копія моўчкі вяртае стары прэфікс.

Параўнайце тое, што наладжана, з тым, што жывое, замест таго каб давяраць чамусьці аднаму:

wg show
wg showconf wg0
ip addr show wg0
ip route get 10.90.0.5

Пошук маршруту — гэта крок, які людзі прапускаюць. Ён адказвае, што ядро насамрэч зробіць для прызначэння, уключаючы больш канкрэтны маршрут, які пакінуў мэнэджар або асяроддзе кантэйнераў. Калі ён паказвае іншы інтэрфейс, чым тунель, праблема не ў канфігурацыі.

Для працуючага інтэрфейса ўжывіце адрэдагаваны файл, не разбіраючы тунель:

wg syncconf wg0 <(wg-quick strip wg0)

Гэта абнаўляе партнёраў і дыяпазоны на месцы. Яно не абнаўляе адрас інтэрфейса або маршруты, бо гэта не налады WireGuard — таму перанумарацыя ўсё яшчэ патрабуе перастварэння інтэрфейса або змены адраса праз ip, а затым паўторнай праверкі маршрутызацыі.

Што павінна рухацца разам на далёкім баку

Менавіта тут змена падсеткі звычайна памірае. AllowedIPs — гэта не толькі падказка для маршрутызацыі; гэта таксама спіс адрасоў крыніцы, якія партнёр мае права прадставіць. Калі вы перанумароўваеце кліентаў і пакідаеце AllowedIPs сервера на старым прэфіксе, сервер прымае рукапаціск, атрымлівае зашыфраваныя пакеты і адкідвае іх, бо ўнутраная крыніца не адпавядае ніводнаму дыяпазону, які ён звязвае з гэтым партнёрам. Памылка не запісваецца, а кліент бачыць тайм-аўт.

Таму абнаўляйце бок атрымальніка свядома: запіс партнёра на серверы павінен пералічваць новы прэфікс кліента, уласны зваротны маршрут сервера павінен паказваць на тунель для гэтага прэфікса, і любая ніжэйшая сетка за серверам павінна вывучыць новы шлях. Палітыка файрвола, якая называла стары дыяпазон, патрабуе таго ж, як і ўсё, што робіць выбар па крыніцы.

Дыягностыка, якая аддзяляе два збоі, танняя. Свежы рукапаціск без даных азначае, што тунель узняты і ўнутраная адрасацыя не згаджаецца. Поўная адсутнасць рукапаціску азначае, што вы глядзіце на дасяжнасць або ключы. Не круціце ключы з-за праблемы прэфікса; гэта скідвае адзінае, што працавала.

Састарэлыя копіі, якія перажываюць вашу праўку

Рэдагаваць файл — не тое ж самае, што змяніць працуючую сістэму, і копій больш, чым людзі чакаюць: юніт або мэнэджар, якому належыць інтэрфейс, другі профіль з той жа назвай у іншай дырэкторыі, кантэйнер з канфігурацыяй, запечанай у вобраз, інтэрфейс роўтара са сваёй адрэдагаванай версіяй і кліенцкая праграма, якая пры запуску паўторна імпартуе захаваны тунель. Кожная можа вярнуць стары прэфікс пасля таго, як ваша змена выглядае завершанай.

Назвы таксама падарожнічаюць. Калі лікавы маршрут працуе, а імя хоста не, унутраны запіс DNS або канфігурацыя службы ўсё яшчэ паказвае на стары адрас тунеля. Выпраўце спасылку замест пашырэння кожнага дыяпазону партнёра, бо гэта замаскіравала б сапраўдную праблему і адначасова павялічыла б ACL крыніц.

Трымайце адкрытым адзін шлях аднаўлення, пакуль працуеце: другі спосаб увайсці на хост, паслядоўная кансоль або запланаваны адкат файлаў канфігурацыі. Змена тунеля, якая замыкае вас ад машыны, якую вы змяняеце, — самы часты спосаб ператварыць гэтую задачу ў вечар.

Выбар паміж двума і праверка пераключэння

Выбірайце A, калі вы валодаеце кожным партнёрам, колькасць малая і кароткі перапынак прымальны. Выбірайце B, калі партнёры — гэта аддаленыя рукі, якімі вы не кіруеце, калі сувязь паміж пляцоўкамі павінна заставацца, або калі вы не можаце гарантаваць, што кожная копія будзе абноўлена за адзін праход. У такім разе дадайце новы прэфікс на абодва інтэрфейсы, пераносьце партнёраў па адным, назірайце за трафікам на новым і толькі потым выдаляйце стары інтэрфейс і яго маршруты.

Пры любым варыянце змена завершана, калі праходзяць чатыры праверкі: рукапаціск свежы, пошук маршруту для прызначэння з новым прэфіксам называе тунель, карысная нагрузка ў некалькі сотняў байтаў перадаецца ў абодвух кірунках, і тое ж захоўваецца пасля перазапуску хоста або мэнэджара. А кіраўніцтва wg(8) — гэта даведнік пра тое, што AllowedIPs значыць у кожным кірунку, і яго варта перачытаць, перш чым пашыраць дыяпазон, каб сімптом знік.

• Рукапаціск свежы, даных няма: паглядзіце на AllowedIPs у атрымальніка, перш чым чапаць ключы.
• Пошук маршруту паказвае на няправільны інтэрфейс: маршрутам валодае мэнэджар або кантэйнер, а не ваш файл.
• Лікавы адрас у парадку, а імя хоста зламанае: старая спасылка, а не пятля маршрутызацыі.
• Змена завершана толькі тады, калі пасля перазапуску ўсё яшчэ выкарыстоўваецца новы прэфікс.