Kaksi toimipistettä, yksi aliverkko, yksi WireGuard-hub: saakaa se toimimaan

Molemmat toimipisteet käyttävät samaa LAN-aluetta, eikä päällekkäisyys ole se, mikä suunnitelman oikeasti rikkoo. Hubin on valittava toimipiste vain kohdeosoitteen perusteella, eikä kaksi samanlaista kohdetta anna sille mitään valittavaa. Toimivan toimiston uudelleennumeroiminen tunnelin vuoksi on yleensä huonompi vaihtokauppa kuin antaa jokaiselle julkaistulle palvelulle erillinen osoite, jonka tunneli voi kuljettaa. Alla oleva suunnitelma julkaisee yhden HTTPS-palvelun toimipistettä kohden eikä mitään muuta.

Miksi päällekkäisyys ei ole varsinainen ongelma

WireGuard välittää kohteen perusteella: peerin AllowedIPs määrää, mikä peer paketin saa. Kaksi peeriä ei voi molemmat ilmoittaa 10.10.7.0/24:ää ilman, että toinen niistä voittaa jokaisen haun. Tämä on peer-taulun eikä tunnelin ominaisuus, minkä vuoksi ratkaisu tässä on osoitesuunnitelma eikä reitityskikka.

Suunnitelma on lopettaa LANin ilmoittaminen kokonaan. Ilmoita sen sijaan alias palvelua kohden, yksi osoite toimipistettä kohden, ja anna kunkin toimipisteen yhdyskäytävän kääntää alias todelliseksi sovelluksekseen.

Käyttäjä reitittää kaksi ainutlaatuista osoitetta, ei koskaan näe monitulkintaista etuliitettä, eikä kummassakaan toimistossa muutu mikään. Tämä ilmaisee myös rajan rehellisesti: julkaiset yhden HTTPS-palvelun kustakin toimipisteestä, et yhdistä kahta verkkoa. Seuraavat säännöt pysyvät pieninä, koska väite on kapea. Laajempi väite vaatisi laajempia sääntöjä, ja juuri niin nämä suunnitelmat monimutkaistuvat.

Anna jokaiselle toimipisteelle alias, jonka käyttäjä voi reitittää

Valitse osoitteet alueelta, joka ei ole ristiriidassa minkään kanssa käyttäjän koneella, hubissa tai kummassakaan LANissa. Tässä hub on 10.66.0.1, käyttäjä 10.66.0.10, yhdyskäytävät 10.66.0.21 ja 10.66.0.22, ja kaksi aliasta 10.77.1.20 ja 10.77.2.20. Hub julkaisee kunkin aliaksen sen omistavan peerin kautta, joten yhteen aliakseen osoitettu lähtevä paketti voi poistua vain vastaavasta toimipisteestä:

[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

Käyttäjän puoli tarvitsee vain kaksi aliasta, mikä pitää asiakasasetukset vapaana kummastakin LAN-etuliitteestä. Mikään siinä asetuksessa ei mainitse kumpaakaan todellista LANia:

[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

Jokainen yhdyskäytävä ilmoittaa hubin ja käyttäjän lähteen, ei mitään muuta, joten toimipiste ei koskaan opi toisen toimipisteen LANia. Keepalive ylläpitää NAT-määritystä toimipisteen uplinkissä; se ei valtuuta liikennettä, ja palomuuri päättää edelleen, mitä päästetään. Yhden yhdyskäytävän asetusten kopioiminen toiseen on kunnossa, kunhan yksityinen avain, liitännän osoite ja alias kaikki vaihtuvat.

Mittä hubin on sallittava kahden peerinsä välillä

Hub välittää paketteja kahden oman peerinsä välillä, mikä on forward-ketjun päätös eikä syötteen päätös. Ota IPv4-edelleenvälitys käyttöön alustan tavallisella mekanismilla ja salli sitten täsmälleen ne parit, joita suunnitelma tarvitsee.

Alla oleva sääntö sallii käyttäjälle yhden aliaksen ja yhden portin ja sallii paluuliikenteen yhteyksien seurannan kautta. Se pudottaa kaiken muun forward-polulta, ja se on tarkoitus:

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

Kaksi yksityiskohtaa kannattaa mainita, koska ne aiheuttavat hiljaisia vikoja. Accept yhdessä perusketjussa ei ohita dropia toisessa, joten sulata tämä olemassa olevaan käytäntöön sen sijaan että lataisit sen rinnalle. Ja lähdeosoite yksilöi laitteen, ei henkilöä; pidä sovelluksen todennus erillään verkon päästämisestä.

Missä aliasesta tulee todellinen osoite

Toimipiste A vastaanottaa pyynnön osoitteeseen 10.77.1.20, kirjoittaa kohteen uudelleen todelliseksi sovellukseksi ja kirjoittaa lähteen uudelleen omaksi LAN-osoitteekseen, jotta vastaus voi palata ilman reittiä tunneliin. Molempien käännösten tekeminen yhdessä paikassa pitää muun verkon tietämättömänä aliaksesta. Alla olevat säännöt ovat koko mekanismi:

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

Toimipisteen A forward-käytännön on sitten sallittava käännetty virtaus tunnelin liitännästä LAN-liitäntään sekä paluusuunta. Forward-koukku näkee kohteen kohdekäännöksen jälkeen ja ennen lähdekirjoitusta, minkä vuoksi sääntö nimeää todellisen sovelluksen osoitteen. Lue ne kaksi koukkua siinä järjestyksessä, kun sääntö näyttää, ettei se vastaa mitään. Aliasesta kirjoitettu forward-sääntö ei voi koskaan vastata, koska aliasta ei enää ole siinä koukussa.

Toimipiste B toistaa tämän omalla aliaksellaan ja omalla avaimellaan. Se ei saa käyttää uudelleen toimipisteen A yksityistä avainta, koska kahden peerin yhden identiteetin jakaminen on asetusvirhe, joka on vaikea nähdä ja helppo luoda kopioimalla tiedosto. Pidä molemmat yhdyskäytävädokumentit identtisinä paitsi niiden arvojen osalta, joiden on erottava, jotta ero pistää silmään tarkistuksessa. Kopioitu tiedosto on tuon vian tavallinen lähde.

Lähteen uudelleenkirjoituksella on hintansa. Sovellus näkee yhdyskäytävän asiakkaanaan, joten sen lokit eivät enää näytä, kuka käyttäjä yhdisti. Säilytä yhdyskäytävän auditointijälki, äläkä heikennä sovelluksen kirjautumista kompensoidaksesi verkkoidentiteettiä, jonka käännös poisti.

Miten todistat, että molemmat julkaistut nimet vastaavat

Anna jokaiselle aliakselle DNS-nimi ja määritä sovellus ja varmenne sille nimelle, koska käännös ei kirjoita uudelleen uudelleenohjauksia tai upotettuja absoluuttisia URL-osoitteita. Käytä yhtä nimeä toimipistettä kohden, jotta varmenteen epäsopivuutta ei voi koskaan luulla reititysvirheeksi.

Testaa todelliselta asiakkaalta, vahvista mikä toimipiste vastasi ja testaa myös luvaton portti. Käytä uusia yhteyksiä jokaisen NAT-muutoksen jälkeen, koska vakiintunut tila pitää vanhan määrityksen:

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

Tyhjä tai odottamaton alias ensimmäisessä komennossa tarkoittaa, että peer-valinta on väärä ennen kuin yksikään palomuurisääntö merkitsee. Jos alias on oikea ja nimi silti epäonnistuu, ongelma on siirtynyt DNS:ään ja varmenteisiin. Kun molemmat nimet vastaavat ja kolmas portti pysyy suljettuna, suunnitelma tekee sen, mitä se väittää: kaksi kapeasti julkaistua palvelua, ei kahta yhdistettyä LANia.