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, което предоставя.

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