Насочването на клон към център е лесната половина на този дизайн, когато клонът стои зад променящ се мобилен адрес, а центърът държи стабилно име. Тогава центърът научава клона от удостоверен трафик, вместо от запис, който трябва да поддържате актуален. Договорът е прост: клонът винаги започва.

Настройте го нарочно, после проверете частта, за която хората предполагат, че работи. Двете стъпки отнемат минути и именно на втората тези дизайни обикновено се провалят.

Коя страна държи стабилната крайна точка

Конфигурацията на клона посочва крайната точка на центъра и неговия публичен ключ. Конфигурацията на центъра посочва публичния ключ на клона и разрешените му вътрешни префикси и може изобщо да не носи крайна точка, защото идентичността идва от ключа, а не от адреса на източника на последния пакет. Тази асиметрия е целият механизъм и тя премахва цял клас проблеми с откриването от страната на центъра.

Когато клонът изпрати удостоверен пакет, центърът записва източника, от който е пристигнал, и използва това съответствие за отговорите. Преназначаването на номера на мобилната връзка тогава не струва нищо освен следващото ръкостискане и всеки компонент, който вече не ви е нужен, е такъв, който не може да се провали при преминаване. Това свойство си струва да се тества при планирана промяна, а не при инцидент. Направете го, докато някой може да наблюдава двата края едновременно.

Дайте на клона конфигурация, която оцелява при преназначаване на адреси

Дръжте крайната точка и поддържането на връзката на клона, а записът за партньора в центъра дръжте свободен от твърдо зададен адрес. Поддържането на връзката държи преобразуваното съответствие отворено достатъчно дълго, за да може центърът да изпрати непоискан трафик след период на бездействие.

[Peer]
PublicKey = HUB_PUBLIC_KEY_BASE64
Endpoint = hub.example.net:51820
AllowedIPs = 10.60.0.0/24, 10.60.10.0/24
PersistentKeepalive = 25

Двадесет и пет секунди е често цитираният пример за поддържане на NAT съответствие живо, а не изискване за всеки партньор. Задайте го според таймаута на съответствието, който реално наблюдавате, и помнете, че той генерира трафик по връзка с ограничение на данните, докато интерфейсът е включен.

В центъра разрешените префикси за партньора на клона трябва да покриват всичко, което клонът ще изпраща. Липсващият префикс се държи като отказ на маршрутизация в далечния край и не дава предупреждение на нито една страна, затова си струва да се прегледа преди първия реален пакет. Сравнете разрешените префикси на центъра с адресите на интерфейсите на клона преди първата връзка.

Проверете съответствието и превключването

Потвърдете, че ръкостискането завършва, че центърът изброява текущата крайна точка на клона и че вътрешните адреси на клона са достъпни през тунела. Това е базовата линия и тя трябва да се запише, преди някой да пипне мобилната връзка. Два реда изход са достатъчни. Пазете ги в заявката заедно с времевия печат.

wg show wg0
wg show wg0 latest-handshakes
ip route show default
ping -c 3 10.60.10.1

След това тествайте отказа, за който съществува дизайнът. Извадете основния WAN и потвърдете, че подлежащият маршрут на клона към центъра сега излиза през мобилния интерфейс. Тунелът не може да поправи счупен физически път, затова външен маршрут, който още сочи към мъртва връзка нагоре, дава таймаут на ръкостискането, който изглежда точно като проблем на центъра.

Ако външният път е изрично обвързан или рутиран по политика, превключването трябва да го включва. Тази разлика между дизайн, който се чете правилно, и такъв, който оцелява при прекъсване, обикновено е единственото липсващо.

Какво този дизайн не решава

Тук нищо не допуска входяща връзка към клона. Ако нещо в централата трябва да се свърже към мобилния обект, посоката на тунела е грешна за това изискване, а динамичният DNS обновява само име. Преобразуването на доставчика, входящата политика и обновяването на крайната точка от клиента остават на пътя и променен запис не може да отвори NAT от операторски клас.

Дръжте префикса на клона отделен от всеки друг обект и ограничете какво ще препраща шлюзът му. Стабилната крайна точка на центъра опростява откриването и не прави нищо за дизайна на маршрутизацията, планирането на адреси или въпроса кои маршрути на приложения оцеляват при превключване.

Запишете четири неща в процедурата: кой започва, кои префикси са разрешени, колко дълго е поддържането на връзката и какво се случва, когато основната връзка падне. Именно тези редове са това, което бъдещият оператор наистина се нуждае в три часа през нощта.

Подобни статии