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

Стартирането на два клиента в някакъв ред не постига това. Маршрутизирането го прави.

Сравнете двата възможни реда

Изберете външния слой като тунела, чиято крайна точка е достъпна от публичния интернет. Вътрешният слой е тунелът, чийто сървър отговаря само през този изход. В Windows практическото разделение е WireGuard отвън и корпоративният клиент отвътре. Решаващият фактор е контролът.

Официалният клиент на WireGuard прилага пълен конфигурационен файл, включително маршрути и DNS. Търговските корпоративни клиенти обикновено крият и двете. Поставянето на скрит клиент отвън ви оставя да гадаете какъв е пътят под него.

Обратният ред не е невъзможен. Просто е по-труден за обмисляне, защото външният клиент пренаписва маршрути по график, който никога не виждате.

Нека AllowedIPs именува само корпоративния диапазон

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

Външен слой с пълен тунел се нуждае от 0.0.0.0/0 минус локалните диапазони. Форматът не може да изрази изключване, затова допълнението трябва да се изчисли и постави на ръка.

[Interface]
PrivateKey = ...
Address = 10.99.4.2/32

[Peer]
PublicKey = ...
Endpoint = 198.51.100.44:51820
AllowedIPs = 198.51.100.44/32, 10.20.0.0/16, 10.21.0.0/16

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

Ред, метрики и вторият адаптер

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

# which interface currently claims the corporate prefix?
Find-NetRoute -RemoteIPAddress 10.20.10.5 | Select-Object -First 1

# prefer the corporate interface for its own prefixes
Set-NetIPInterface -InterfaceAlias 'Corp VPN' -InterfaceMetric 3
Set-NetIPInterface -InterfaceAlias 'wg-personal' -InterfaceMetric 40

wg show interfaces

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

Клиентите, изградени върху OpenVPN 2.6, добавят свой капан. Когато адаптерът за разтоварване на канала за данни вече е зает, втори екземпляр просто отказва да стартира. Добавянето на disable-dco към профила се връща към по-стария път TAP и тогава двата работят един до друг.

Къде се чупи вграденият път

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

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

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

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