Два сайты, адна падсетка, адзін хаб WireGuard: як гэта запусціць

Абедзве LAN знаходзяцца на 10.10.7.0/24, таму хаб не можа выбраць сайт па прызначэнні. Дайце кожнай службе псеўданім і пераўтварайце на яе шлюзе.

Абодва сайты выкарыстоўваюць адзін і той жа дыяпазон LAN, і менавіта не супадзенне ламае архітэктуру. Хаб павінен выбіраць сайт толькі па адрасе прызначэння, а два аднолькавыя прызначэнні не даюць яму нічога для выбару. Перанумараваць працуючы офіс дзеля тунеля звычайна горш, чым даць кожнай апублікаванай службе асобны адрас, які тунель можа пранесці. Архітэктура ніжэй публікуе адну службу HTTPS на сайт і нічога больш.

Чаму супадзенне не з'яўляецца сапраўднай праблемай

WireGuard перасылае па прызначэнні: AllowedIPs піра вызначаюць, які пір атрымае пакет. Два піры не могуць адначасова абвяшчаць 10.10.7.0/24, каб адзін з іх не выйграваў кожны пошук. Гэта ўласцівасць табліцы піраў, а не тунеля, таму рашэнне тут — план адрасоў, а не трук з маршрутызацыяй.

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

Карыстальнік маршрутызуе два ўнікальныя адрасы, ніколі не бачыць неадназначны прэфікс, і ў абодвух офісах нічога не змяняецца. Гэта таксама сумленна акрэслівае мяжу: вы публікуеце адну службу HTTPS з кожнага сайта, а не аб'ядноўваеце дзве сеткі. Правілы ніжэй застаюцца малымі, бо сцвярджэнне вузкае. Шырэйшае сцвярджэнне патрабавала б шырэйшых правілаў, і менавіта так гэтыя архітэктуры ўскладняюцца.

Дайце кожнаму сайту псеўданім, па якім карыстальнік можа маршрутызаваць

Выбірайце адрасы з дыяпазону, які ні з чым не канфліктуе на машыне карыстальніка, на хабе ці ў любой з сетак LAN. Тут хаб — 10.66.0.1, карыстальнік — 10.66.0.10, шлюзы — 10.66.0.21 і 10.66.0.22, а два псеўданімы — 10.77.1.20 і 10.77.2.20. Хаб абвяшчае кожны псеўданім праз пір, які ім валодае, таму зыходны пакет, адрасаваны аднаму псеўданіму, можа выйсці толькі праз адпаведны сайт:

[Interface]
Address = 10.66.0.1/32
ListenPort = 51820
PrivateKey = HUB_KEY

[Peer]
PublicKey = USER_PUBLIC_KEY
AllowedIPs = 10.66.0.10/32

[Peer]
PublicKey = SITE_A_PUBLIC_KEY
AllowedIPs = 10.66.0.21/32, 10.77.1.20/32

[Peer]
PublicKey = SITE_B_PUBLIC_KEY
AllowedIPs = 10.66.0.22/32, 10.77.2.20/32

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

[Interface]
Address = 10.66.0.10/32
PrivateKey = USER_KEY

[Peer]
PublicKey = HUB_PUBLIC_KEY
Endpoint = hub.example.net:51820
AllowedIPs = 10.77.1.20/32, 10.77.2.20/32
PersistentKeepalive = 25

Кожны шлюз абвяшчае хаб і крыніцу карыстальніка, больш нічога, таму сайт ніколі не даведаецца пра LAN іншага сайта. Keepalive падтрымлівае адлюстраванне NAT на ўзыходзячай лініі сайта; ён не дае дазволу на трафік, і міжсеткавы экран па-ранейшаму вырашае, што дапушчана. Капіраваць канфігурацыю аднаго шлюза ў другі можна, пакуль прыватны ключ, адрас інтэрфейса і псеўданім усе змяняюцца.

Што хаб павінен дазваляць паміж двума сваімі пірамі

Хаб перасылае пакеты паміж двума сваімі пірамі, і гэта рашэнне ў ланцугу forward, а не рашэнне на ўваходзе. Уключыце перасылку IPv4 звычайным механізмам платформы, затым дазвольце менавіта тыя пары, якія патрабуе архітэктура.

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

nft add table inet hub_transit
nft add chain inet hub_transit forward '{ type filter hook forward priority 0 ; policy drop ; }'
nft add rule inet hub_transit forward ct state established,related accept
nft add rule inet hub_transit forward iifname wg0 oifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 accept

Дзве дэталі варта назваць, бо яны выклікаюць ціхія збоі. Accept у адным базавым ланцугу не перамагае drop у іншым, таму зліце гэта з існуючай палітыкай, а не загружайце побач. І адрас крыніцы ідэнтыфікуе прыладу, а не чалавека; трымайце аўтэнтыфікацыю праграмы асобна ад дапуску ў сетку.

Дзе псеўданім становіцца рэальным адрасам

Сайт A атрымлівае запыт на 10.77.1.20, перапісвае прызначэнне на сапраўдную праграму і перапісвае крыніцу на свой адрас LAN, каб адказ мог вярнуцца без маршруту ў тунель. Выкананне абодвух пераўтварэнняў у адным месцы пакідае астатнюю сетку ў няведанні пра псеўданім. Правілы ніжэй — гэта ўвесь механізм:

nft add table ip site_a_nat
nft add chain ip site_a_nat pre '{ type nat hook prerouting priority -100 ; policy accept ; }'
nft add chain ip site_a_nat post '{ type nat hook postrouting priority 100 ; policy accept ; }'
nft add rule ip site_a_nat pre iifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 dnat to 10.10.7.20:443
nft add rule ip site_a_nat post iifname wg0 oifname lan0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.10.7.20 snat to 10.10.7.2

Палітыка forward сайта A павінна затым дапусціць ператвораны паток з інтэрфейса тунеля ў інтэрфейс LAN, а таксама адваротны кірунак. Хук forward бачыць прызначэнне пасля пераўтварэння прызначэння і да перапісвання крыніцы, таму правіла называе адрас сапраўднай праграмы. Чытайце гэтыя два хукі ў такім парадку, калі правіла выглядае так, нібы нічому не адпавядае. Правіла forward, напісанае супраць псеўданіма, не можа супасці ніколі, бо псеўданіма ўжо няма на гэтым хуку.

Сайт B паўтарае гэта са сваім псеўданімам і сваім ключом. Ён не павінен выкарыстоўваць прыватны ключ сайта A, бо два піры з адной ідэнтычнасцю — гэта памылка канфігурацыі, якую цяжка ўбачыць і лёгка стварыць капіраваннем файла. Трымайце абодва дакументы шлюза аднолькавымі, акрамя значэнняў, якія павінны адрознівацца, каб розніца кідалася ў вочы пры аглядзе. Скапіяваны файл — звычайная крыніца гэтай непалады.

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

Як даказаць, што абодва апублікаваныя імёны адказваюць

Дайце кожнаму псеўданіму імя DNS і наладзьце праграму і сертыфікат для гэтага імя, бо пераўтварэнне не перапісвае перанакіраванні і ўбудаваныя абсалютныя URL. Выкарыстоўвайце адно імя на сайт, каб неадпаведнасць сертыфіката ніколі не прынялі за збой маршрутызацыі.

Тэстуйце з сапраўднага кліента, пацвердзіце, які сайт адказаў, і праверце таксама недазволены порт. Выкарыстоўвайце новыя злучэнні пасля любога змянення NAT, бо ўсталяваны стан захоўвае старое адлюстраванне:

wg show wg0 allowed-ips
sudo nft list ruleset
curl -sS -o /dev/null -w "%{http_code}\n" https://site-a.example.net/

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

Падобныя артыкулы