WireGuard: розділений тунель без маршруту за замовчуванням

Розділений тунель визначається тим, що ви виключаєте, і WireGuard ухвалює це рішення в одному полі. AllowedIPs на боці клієнта одночасно вибирає, які призначення йдуть через тунель, і фільтрує, які внутрішні адреси джерела приймаються, а wg-quick перетворює той самий список на маршрути хоста. Помилитеся зі списком — і тунель або проковтне все, або нічого не понесе.

Спершу визначте список префіксів

Запишіть призначення, які повинні використовувати тунель, перш ніж торкатися файлу конфігурації. Офісні підмережі, діапазон бази даних, мережа керування: кожен — це префікс із причиною. Усе, чого немає в списку, залишається на фізичному шляху, і в цьому весь сенс схеми.

Якщо список містить 0.0.0.0/0 або ::/0, ви збудували повний тунель і повинні це сказати, бо режими відмови та очікування від DNS різняться.

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

Конфігурація клієнта: пір, AllowedIPs, DNS

Блок інтерфейсу клієнта містить його власну адресу тунелю та закритий ключ. Блок піра містить відкритий ключ сервера, кінцеву точку та префікси з першого кроку:

[Interface]
Address = 10.9.0.2/32
PrivateKey = <client-private-key>
DNS = 10.20.0.53

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16, 10.30.0.0/24
PersistentKeepalive = 25

AllowedIPs на клієнті — це набір віддалених призначень, а не власна адреса клієнта. Рядок DNS діє лише через інтеграцію резолвера в wg-quick, тому хост без підтримки resolvconf або systemd-resolved його проігнорує. PersistentKeepalive підтримує зіставлення NAT живим і не потрібен на прямому шляху.

Прокоментуйте кожен префікс сервісом, якому він служить, інакше наступна правка стане здогадкою.

Конфігурація сервера: протилежний погляд

На сервері запис піра представляє клієнта, тому його AllowedIPs — це адреса тунелю клієнта, зазвичай /32. Це не офісна підмережа. Копіювання списку клієнта в запис сервера — найпоширеніша помилка розділеного тунелю, і вона або розширює доступ, або ламає внутрішню перевірку джерела під час рукостискання.

Власна адреса інтерфейсу сервера та маршрути, які йому потрібні в бік офісу, відокремлені від будь-якого запису піра.

Два файли, два погляди, один набір префіксів, поділений між ними.

Підніміть його та прочитайте маршрути

Запустіть інтерфейс підтримуваним менеджером, а потім подивіться, що він установив, а не що ви задумали. wg-quick виводить маршрути з AllowedIPs; якщо профіль задає Table = off, нічого не встановлюється і маршрутизація залишається за вами. Прочитайте маршрут для кожного префікса й переконайтеся, що він указує на інтерфейс WireGuard. Порожній список маршрутів зазвичай означає, що застосований профіль — не той, який ви редагували.

Перевірте також лічильники рукостискань, бо в піра без рукостискання проблема з ключем, кінцевою точкою або доступністю, а не з маршрутизацією.

Запишіть точну команду, яку використовували, бо наступна людина запустить її під тиском.

Перевірте обидві сторони, потім зафіксуйте відкат

Перевірте приватну адресу, її внутрішнє ім'я та призначення, яке має залишатися прямим. Якщо приватна адреса працює, а пряме призначення тепер виходить через тунель, список префіксів занадто широкий. Якщо ім'я не працює, а адреса працює, рядок DNS не набрав чинності. Відкат — одна команда, і він належить до тієї ж нотатки.

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

Тримайте одного власника конфігурації, бо два менеджери, що створюють той самий інтерфейс, рано чи пізно розійдуться. Посібник wg-quick описує поведінку маршрутів і DNS, яку він забезпечує.