Поўны тунэль 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 нейкай праграмы, і тунэль, які моўчкі ўцякае другое сямейства, горш за той, што гучна адмаўляе. Запытайце імя праз кожнае сямейства, прачытайце інтэрфейс, які выкарыстаў кожны запыт, і праверце лічыльнікі трансляцыі да і пасля, бо правіла, якое ні з чым не супадае, выглядае гэтак жа, як правіла, якое адсутнічае.

Нарэшце, праверце стан, які вы хочаце, калі тунэль спыняецца. Поўны тунэль павінен адмаўляць закрыта для трафіку, на які ён прэтэндуе: калі інтэрфейс падае, а праграмы спакойна працягваюць праз фізічнае злучэнне, дызайн — гэта раздвоены тунэль з дадатковымі крокамі. Запішыце меркаваныя паводзіны пры збоі, праверце іх наўмысна і скончыце запісам чатырох адказаў — які менеджар узнімае інтэрфейс, які маршрут нясе стандарт, хто перадае і трансліруе на шлюзе і які рэзалвер адказвае.