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, якія ён забяспечвае.