Как да насочите един сайт извън вашия тунел WireGuard

Изключването на име на хост е нещо, което един тунел не може да направи. Маршрутът обаче може да насочи един адрес покрай тунела и през домашния шлюз, и това обикновено е достатъчно за един сайт. Уловката е, че всичко след маршрута трябва да е съгласувано: защитната стена трябва да пусне пакета, DNS трябва да върне адреса, който сте насочили, и сайтът трябва да продължи да използва този адрес. Когато някое от трите се отклони, изключението спира да работи, без да се обявява.

Прочетете адреса на местоназначението, преди да пипате тунела

Заредете сайта веднъж с включен тунел, след което погледнете адреса на партньора, към който браузърът действително се е свързал. В Linux, ss -tunp извежда отдалечения адрес за всеки отворен сокет, а dig +short за същото име показва какво е върнал резолверът. Дръжте двата номера пред себе си.

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

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

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

Да приемем, че интерфейсът се нарича home-wg и LAN рутерът е на 192.168.1.1. NetworkManager приема маршрут, чийто шлюз е този рутер и чиято дължина на префикса покрива пълните 32 бита, а ядрото го предпочита, защото най-дългият префикс печели.

nmcli connection modify home-wg +ipv4.routes "198.51.100.20/32 192.168.1.1"
nmcli connection up home-wg
ip route get 198.51.100.20

Шлюзът трябва да е достъпен без тунела; насочването на следващия хоп към адреса на тунела обезсмисля целта, защото пакетът отново би влязъл в интерфейса, който се опитвате да избегнете. След като връзката се върне, ip route get за изключението трябва да отпечата LAN шлюза, а същата команда за публичен резолвер трябва все още да отпечатва устройството на тунела.

Профилът wg-quick няма поле за маршрути, така че същото изключение живее в ред PostUp , който добавя маршрута за хост към главната таблица с LAN интерфейса като негово устройство. Свалете и вдигнете интерфейса след редактиране, защото работещ интерфейс никога не препрочита файла си. Правилата fwmark, които wg-quick инсталира, насочват само собствените му инкапсулирани пакети, така че обикновеният трафик на браузъра все още следва главната таблица и намира вашия /32.

Kill switch е следващото нещо, което го блокира

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

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

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

DNS решава към кой адрес се обажда браузърът

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

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

Същото изключение на рутера, веднъж, за всяко устройство

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

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

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