AllowedIPs е списък за маршрутизиране, а не правило на защитна стена

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

Едно поле, двама читатели: избор за изходящ и проверка на източника

При клиента префиксите решават кои дестинации пътуват до този партньор и кои остават в обикновената мрежа. Запис за 0.0.0.0/0 следователно обхваща всяка дестинация IPv4, поради което импортирането на профил за пълен тунел изпраща обикновеното сърфиране през отдалечената машина. Тесните записи правят обратното: маршрутизират само мрежите, които сте изброили, и оставят всичко останало там, където е било. Разделът за маршрутизиране на криптоключове в документацията на WireGuard описва двете задачи на едно място: избор на изходящ партньор и проверка на входящия източник.

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

Блокът на клиента е мястото, където започва повечето от това объркване. Разделеният тунел изброява отдалечените мрежи, а пълният тунел е същото поле с префикс по подразбиране:

[Peer]
# split tunnel: only these networks
AllowedIPs = 10.77.0.0/24, 192.168.30.0/24

[Peer]
# full tunnel: everything, both families
AllowedIPs = 0.0.0.0/0, ::/0

И двете форми са самодостатъчни и са алтернативи, а не стъпки. Първата изпраща само тези две мрежи през тунела; втората изпраща всяка дестинация, като записът ::/0 добавя IPv6 към стандартния IPv4. Което и да изберете, тези префикси са цялото решение за маршрутизиране на този партньор, щом wg-quick започне да инсталира маршрути.

Хъбът се нуждае от различен списък

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

[Peer]
# laptop: tunnel address 10.77.0.2, office LAN behind it
AllowedIPs = 10.77.0.2/32, 192.168.30.0/24

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

Пропускането на инсталирането на маршрути оставя празнина

wg-quick, помощникът, който вдига интерфейс от конфигурационен файл, инсталира адреси на интерфейса и маршрути като част от тази работа. Задаването на Table = off казва на помощника да пропусне работата по маршрутите, което не инсталира заместители и не прави частната мрежа достъпна. Когато автоматичните маршрути вече вършат работата, посочването на нужните префикси е по-ясната конфигурация. Изключването на управлението на маршрутите и оставянето на заместителя ненаписан не е дизайн, а пропуск.

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

DNS и IPv6 се решават отделно

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

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