Пълен тунел WireGuard: AllowedIPs 0.0.0.0/0 не е достатъчно

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

Какво избира префиксът на партньора и какво не

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

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

Маршрутизиране на клиента, не само на списъка с партньори

Мениджъри като wg-quick програмират таблицата за маршрутизация на хоста вместо вас, затова два еднакви конфигурационни файла се държат различно в зависимост от това как е стартиран интерфейсът. Минималният профил е достатъчно кратък, за да се прочете наведнъж:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

Два детайла носят работата. Полето Address е един префикс за хост, а не подмрежа, която клиентът смята, че притежава, и именно мениджърът превръща стандартния AllowedIPs в действителен маршрут по подразбиране. Вдигнете същия файл с ip link и wg setconf и няма да се появи нито един маршрут, което изглежда като счупен тунел, а всъщност е здрав тунел с пропусната стъпка по маршрутизация. wg-quick ръководството документира маршрутизацията и Table поведението, което тези мениджъри добавят.

Четете резултата, а не файла: ip route get 1.1.1.1 трябва да посочи интерфейса на тунела, а wg show трябва да покаже скорошен ръкостискан с брояч на прехвърлянето, който се движи. Ръкостискане без маршрут означава, че мениджърът никога не е стартирал, и повторното редактиране на профила няма да го поправи. Стартирайте интерфейса така, както потребителят ще го стартира, иначе тестът измерва вашата обвивка вместо внедряването.

Задържане на крайната точка извън тунела

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

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

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

Препращане и обратен път на шлюза

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

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

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

DNS и състоянието при отказ, тествани отделно

Самият протокол не настройва резолвера на никое приложение. wg-quick прилага реда DNS чрез интеграцията на резолвера на дистрибуцията, контейнерите и браузърите със свои собствени стекове може да го пренебрегнат, и затова име може да се провали, докато тунелът пренася пакети безупречно. Тествайте с име на хост, а не с адрес, и отбележете кой сървър е отговорил, вместо да предполагате, че това е сървърът от профила.

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

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