Kaikki portit kattava edelleenohjaus voi niellä WireGuard-kuuntelijasi

Julkinen yhdyskäytävä ajaa jo WireGuardia UDP-portissa 51820, SSH:ta portissa 22 ja yhtä sovellusta, jonka on oltava tavoitettavissa internetistä. Houkutteleva sääntö ohjaa jokaisen portin peerille ja toteaa asian valmiiksi. WireGuard-yhdyskäytävässä tämä sääntö voi napata tunnelin oman kuljetuksen ja lukita sinut ulos koneesta, joka päättää sen. Julkaiseminen on reitityspäätös, jossa on ohjaustason poikkeus, ei yksittäinen DNAT-rivi.

Julkinen sisäänkäynti vai tunnelin sisäänkäynti: valitse yksi

Palvelun julkaiseminen luo uuden internetin sisäänkäynnin. Se ei ole sama kuin VPN-jäsenyyden antaminen peerille, koska vierailija ei koskaan liity tunneliin ja yhdyskäytävästä tulee backendin julkinen kasvo. Tämä ero ratkaisee säännön kohdeyleisön ja sen varmenteen.

Hallintaliittymät kuuluvat harvoin siihen asemaan. Valtuutettujen VPN-asiakkaiden tavoittama hallintasivu pitää hyökkäyspinnan tunnelin sisällä ja välttää kirjautumislomakkeen altistamista mielivaltaiselle skannaukselle. Julkiset sovelluspäätepisteet tarvitsevat silti oman TLS-varmenteen, todennuksen ja nopeuden rajoituksen; salattu WireGuard-hyppy ei suojaa vierailijan osuutta yhdyskäytävälle.

Jos palvelun on todella oltava julkinen, kirjaa isäntänimi, sen kattava varmenne ja vierailijoiden alueet, joiden pitäisi päästä siihen. Nämä kolme tosiseikkaa ratkaisevat myöhemmin säännön muodon ja suodatuskäytännön. Kaikki niiden ulkopuolella on laajuuden leviämistä julkisella kuuntelijalla.

Yksi portti sisään, yksi backend ulos

Käytä yhtä julkista porttia ja yhtä backend-palvelua. Tässä esimerkissä eth0 kantaa julkista osoitetta 198.51.100.20, yhdyskäytävän tunneliosoite on 10.200.0.1 ja peer ajaa sovellusta osoitteessa 10.200.0.7. Julkinen TCP 9443 kartoitetaan peerin TCP:hen 8443:

iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1

SNAT-sääntö vastaa käännettyä backendia ja alkuperäistä julkista kohdetta, joten toinen yhteys samaan backend-palveluun pysyy tämän kartoituksen ulkopuolella. Se myös piilottaa vierailijan osoitteen peeriltä, ja tämä on se kompromissi, joka tekee lähteen säilyttävästä reititetystä paluusta erillisen suunnittelun. iptables-laajennusten viite dokumentoi molemmat kohteet ja niiden vastaavuusvaihtoehdot.

Edelleenohjaus on silti otettava käyttöön, ja suodatusketju tarvitsee sallinnan käännetylle kohteelle ja portille sekä vakiintuneille vastauksille. FORWARD-ketju näkee käännätyn kohteen vasta DNAT:n jälkeen, joten julkista osoitetta vastaan kirjoitettu sääntö ei vastaa edelleenohjattua pakettia. Kirjoita sallinta backendin monikkoa vastaan, älä julkista.

Peerin on hyväksyttävä palveluyhteys yhdyskäytävän tunneliosoitteesta ja lähetettävä vastaus takaisin tunnelin kautta. Sen AllowedIPs:n on valtuutettava lähde, jonka se todella vastaanottaa, mikä lähteen käännöksessä on yhdyskäytävän tunneliosoite, eikä laajaa 0.0.0.0/0-merkintää tarvita jokaisella peerillä tässä suunnittelussa. Paluuliikenteen pudottaa peer, jonka luettelo jättää tämän osoitteen pois, tai lähteen säilyttävä suunnittelu, joka välittää sen sijaan vierailijan oman osoitteen, joten tarkista lähde, jonka peer todella näkee, älä sitä, joka on säännössäsi.

Pidä yhdyskäytävän omat kuuntelijat poissa säännöstä

Korvaa porttivastaavuus säännöllä, joka kattaa jokaisen TCP- ja UDP-kohteen, ja yhdyskäytävän oma WireGuard-soketti jää sen sisään. Kohteen käännös tapahtuu ennen kuin kone päättää, että paketti on paikallinen, joten UDP 51820 voi päätyä peerille eikä prosessille, joka pitää jokaista peer-yhteyttä. Sääntö latautuu onnistuneesti ja tunneli kuolee, mikä on peerin puolelta vaikeasti luettava vika.

SSH:lla, valvonta-agenteilla ja kaikilla muilla yhdyskäytävässä isännöidyillä palveluilla on sama altistus. Sääntö, joka välittää kaiken, ei erota ohjaustasoa julkaistusta sovelluksesta, ja ensimmäinen uudelleenkäynnistys muutoksen jälkeen on hetki, jolloin lukitus tulee ilmeiseksi. Kaiken kattava sääntö ei varoita palvelusta, jonka se hiljaa ottaa haltuunsa. Löydät sen, kun seuraava yhteys epäonnistuu.

Jos laaja edelleenohjaus on todella tarpeen, varaa ohjausportit ennen kaiken kattavaa sääntöä tai käytä julkaisemiseen erillistä julkista osoitetta. Toinen vaihtoehto on siistimpi, koska ohjausosoite säilyttää oman käytäntönsä, mutta tarjoajan on toimitettava kyseinen osoite; DNS-tietueen lisääminen ei kohdista sellaista.

Laaja TCP- ja UDP-edelleenohjaus ei ole myöskään kaikki protokollat. ICMP, IPv6, polun MTU-palaute ja ulompi VPN-kuljetus tarvitsevat oman käytäntönsä, ja TCP:n ja UDP:n kattava sääntö jättää nämä tapaukset oletusketjulle.

Valitse malli ennen sääntöjen kirjoittamista

Neljä muotoa kattaa useimmat yhdyskäytävän julkaisut, ja valinta riippuu siitä, kuinka monta palvelua ajat ja kuinka paljon ohjaustason riskiä siedät. Alla oleva taulukko järjestää ne kapeimmasta laajimpaan.

Aloita kapealla mallilla, vaikka odottaisit myöhemmin lisää palveluita. Se on helpoin tarkastaa, ja kapeiden sääntöjen joukon muuttaminen katsastetuksi kaiken kattavaksi säännöksi on yksinkertaisempaa kuin selvittää, minkä kuuntelijan laaja sääntö nappasi. Minkä mallin valitsetkin, pidä säännöt palomuurin omistajalla. iptables-rivien soveltaminen UFW- tai nftables-kokoonpanon vieressä, joka myös hallinnoi samoja ketjuja, tuottaa käytännön, joka muuttuu käynnistysjärjestyksen mukaan.

Todista sekä julkaisu että ohjauspolku

Testaa valtuutetusta ulkoisesta asiakkaasta hyväksytyllä isäntänimellä ja sille kelvollisella varmenteella. Vahvista, mikä backend vastasi, ja tarkista sitten, että liittymättömät julkiset portit pysyvät kiellettyinä. Pois kytketty varmenteen tarkistus ei ole läpäisty HTTPS-testi, ja väärään backendiin päätyvä yhteys on huonompi kuin epäonnistunut.

Sen jälkeen tarkista itse yhdyskäytävä: yhdistä WireGuard-peer, avaa SSH-istunto ja vahvista, että valvonta raportoi edelleen. Julkaistu palvelu voi toimia, kun ohjaustaso on rikki, joten molemmat tarkistukset kuuluvat samaan muutosikkunaan. Käynnistä kerran uudelleen todistaaksesi, että säännöt sovelletaan uudelleen odotetussa järjestyksessä, poista sitten julkaisu ja vahvista, että poisto todella vastaa lisäystä. Suuri joukko käynnistyksen lisäyksiä ja puutteellinen poisto on se, miten väliaikaisesta testistä tulee pysyvä avaus.