Dau safle, un is-rwydwaith, un canolbwynt WireGuard: gwnewch iddo weithio

Mae'r ddau safle'n defnyddio'r un amrediad LAN, a'r gorgyffwrdd nid yw'r hyn sy'n torri'r cynllun mewn gwirionedd. Rhaid i'r canolbwynt ddewis safle gan ddefnyddio'r cyfeiriad cyrchfan yn unig, ac nid yw dau gyrchfan unfath yn rhoi dim iddo i ddewis ag ef. Mae ailrifo swyddfa sy'n gweithio er mwyn bodloni twnnel fel arfer yn fargen waeth na rhoi cyfeiriad gwahanol i bob gwasanaeth cyhoeddedig y gall y twnnel ei gario. Mae'r cynllun isod yn cyhoeddi un gwasanaeth HTTPS y safle a dim byd arall.

Pam nad y gorgyffwrdd yw'r gwir broblem

Mae WireGuard yn anfon yn ôl cyrchfan: AllowedIPs cymar sy'n penderfynu pa gymar sy'n derbyn pecyn. Ni all dau gymar gyhoeddi 10.10.7.0/24 ill dau heb i un ohonynt ennill pob chwiliad. Priodwedd o'r tabl cymar yw hyn, nid o'r twnnel, a dyna pam mai cynllun cyfeiriadau yw'r ateb yma, nid tric llwybro.

Y cynllun yw rhoi'r gorau i gyhoeddi'r LAN yn gyfan gwbl. Cyhoeddwch alias fesul gwasanaeth yn lle hynny, un cyfeiriad y safle, a gadewch i borth y safle hwnnw gyfieithu'r alias at ei wir gymhwysiad.

Mae'r defnyddiwr yn llwybro dau gyfeiriad unigryw, byth yn gweld y rhagddodiad amwys, ac nid oes dim yn newid yn y naill swyddfa na'r llall. Mae hyn hefyd yn datgan y ffin yn onest: rydych yn cyhoeddi un gwasanaeth HTTPS o bob safle, nid yn uno dwy rwydwaith. Mae'r rheolau sy'n dilyn yn aros yn fach oherwydd bod y datganiad yn gul. Byddai datganiad ehangach angen rheolau ehangach, a dyna sut mae'r cynlluniau hyn yn mynd yn gymhleth.

Rhowch alias i bob safle y gall y defnyddiwr ei lwybro

Dewiswch gyfeiriadau o amrediad nad yw'n gwrthdaro â dim ar beiriant y defnyddiwr, y canolbwynt na'r naill LAN. Yma'r canolbwynt yw 10.66.0.1, y defnyddiwr yw 10.66.0.10, y pyrth yw 10.66.0.21 a 10.66.0.22, a'r dau alias yw 10.77.1.20 a 10.77.2.20. Mae'r canolbwynt yn cyhoeddi pob alias drwy'r cymar sy'n berchen arno, felly dim ond drwy'r safle cyfatebol y gall pecyn allan gyfeiriedig at un alias adael:

[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

Dim ond y dau alias sydd eu hangen ar ochr y defnyddiwr, sy'n cadw ffurfweddiad y cleient yn rhydd o'r ddau ragddodiad LAN. Nid oes dim yn y ffurfweddiad hwnnw'n sôn am y naill LAN go iawn na'r llall:

[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

Mae pob porth yn cyhoeddi'r canolbwynt a ffynhonnell y defnyddiwr, dim byd arall, felly nid yw safle byth yn dysgu LAN y safle arall. Mae keepalive yn cynnal mapiad NAT ar uplink y safle; nid yw'n awdurdodi traffig, ac mae'r wal dân yn dal i benderfynu beth a dderbynnir. Mae copïo ffurfweddiad un porth i'r llall yn iawn cyn belled â bod yr allwedd breifat, cyfeiriad y rhyngwyneb a'r alias i gyd yn newid.

Beth sy'n rhaid i'r canolbwynt ei ganiatáu rhwng dau o'i gymarau

Mae'r canolbwynt yn anfon pecynnau rhwng dau o'i gymarau ei hun, sy'n benderfyniad yng nghadwyn forward yn hytrach na phenderfyniad mewnbwn. Galluogwch anfon IPv4 drwy fecanwaith arferol y platfform, yna caniatáu'n union y parau sydd eu hangen ar y cynllun.

Mae'r rheol isod yn caniatáu i'r defnyddiwr un alias ac un porth, ac yn caniatáu traffig dychwelyd drwy olrhain cysylltiadau. Mae'n gollwng popeth arall ar lwybr forward, a dyna'r pwynt:

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

Mae dau fanylyn yn werth eu nodi oherwydd eu bod yn achosi methiannau tawel. Nid yw accept mewn un gadwyn sylfaenol yn trechu drop mewn un arall, felly cyfunwch hyn â'r polisi presennol yn hytrach na'i lwytho ochr yn ochr. Ac mae'r cyfeiriad ffynhonnell yn adnabod y ddyfais, nid y person; cadwch ddilysu'r cymhwysiad ar wahân i dderbyn y rhwydwaith.

Lle mae alias yn dod yn gyfeiriad go iawn

Mae safle A yn derbyn cais am 10.77.1.20, yn ailysgrifennu'r gyrchfan at y gwir gymhwysiad, ac yn ailysgrifennu'r ffynhonnell at ei gyfeiriad LAN ei hun fel y gall yr ateb ddychwelyd heb lwybr i'r twnnel. Mae gwneud y ddau gyfieithiad mewn un lle yn cadw gweddill y rhwydwaith yn anwybodol o'r alias. Y rheolau isod yw'r mecanwaith cyfan:

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

Yna rhaid i bolisi forward safle A dderbyn y ffrwd gyfieithiedig o ryngwyneb y twnnel i ryngwyneb y LAN, ynghyd â'r cyfeiriad dychwelyd. Mae hook forward yn gweld y gyrchfan ar ôl cyfieithu cyrchfan ac o flaen ailysgrifennu'r ffynhonnell, a dyna pam mae'r rheol yn enwi cyfeiriad y gwir gymhwysiad. Darllenwch y dau hook hynny yn y drefn honno pryd bynnag y mae rheol yn ymddangos fel pe na bai'n cyfateb i ddim. Ni all rheol forward a ysgrifennwyd yn erbyn yr alias byth gyfateb, oherwydd nid yw'r alias yn bodoli mwyach yn y hook hwnnw.

Mae safle B yn ailadrodd hyn gyda'i alias ei hun a'i allwedd ei hun. Ni chaiff ailddefnyddio allwedd breifat safle A, oherwydd mae dau gymar yn rhannu un hunaniaeth yn gamgymeriad ffurfweddu sy'n anodd ei weld ac yn hawdd ei greu drwy gopïo ffeil. Cadwch y ddau ddogfen porth yn unfath ac eithrio'r gwerthoedd sy'n rhaid iddynt fod yn wahanol, fel bod y gwahaniaeth yn sefyll allan wrth adolygu. Ffeil a gopïwyd yw tarddiad arferol y nam hwnnw.

Mae pris i ailysgrifennu'r ffynhonnell. Mae'r cymhwysiad yn gweld y porth fel ei gleient, felly nid yw ei logiau'n dangos mwyach pa ddefnyddiwr a gysylltodd. Cadwch ôl archwilio'r porth, a pheidiwch â gwanhau mewngofnodi'r cymhwysiad i wneud iawn am hunaniaeth rwydwaith a dynnwyd gan y cyfieithu.

Sut i brofi bod y ddau enw cyhoeddedig yn ateb

Rhowch enw DNS i bob alias a ffurfweddwch y cymhwysiad a'r dystysgrif ar gyfer yr enw hwnnw, oherwydd nid yw cyfieithu yn ailysgrifennu ailgyfeiriadau nac URLau absoliwt sydd wedi'u mewnosod. Defnyddiwch un enw y safle fel na all anghysondeb tystysgrif byth gael ei gamgymryd am nam llwybro.

Profwch o'r gwir gleient, cadarnhewch pa safle a atebodd, a phrofwch borth heb awdurdod hefyd. Defnyddiwch gysylltiadau newydd ar ôl unrhyw newid NAT, oherwydd mae cyflwr sefydledig yn cadw'r hen fapiad:

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

Mae alias gwag neu annisgwyl yn y gorchymyn cyntaf yn golygu bod y dewis cymar yn anghywir cyn i unrhyw reol wal dân fod o bwys. Os yw'r alias yn iawn ac mae'r enw'n dal i fethu, mae'r broblem wedi symud i DNS a thystysgrifau. Unwaith y bydd y ddau enw'n ateb ac mae'r trydydd porth yn parhau ar gau, mae'r cynllun yn gwneud yr hyn y mae'n ei honni: dau wasanaeth a gyhoeddwyd yn gyfyng, nid dwy LAN wedi'u huno.