VPS-palomuuri: avaa vain VPN-portti ja todista se sitten

Palomuuri, joka päästää läpi vain VPN-portin, ei ole yksi sääntö. Se on kolme erillistä päätöstä, jotka sattuvat koskemaan samaa porttinumeroa: syöteketju päättää, mikä voi päästä paikalliseen prosessiin, välitysketju päättää, mikä voi kulkea isännän läpi tunneliasiakkaiden puolesta, ja NAT-taulu kirjoittaa lähdeosoitteen uudelleen ulospäin. Yhden niistä saa väärin, ja tulos on harvoin siisti katkos. Saat isännän, joka hyväksyy asiakkaita mutta ei lataa mitään, tai isännän, joka näyttää suljetulta kunnes joku lukee ketjujen järjestyksen.

Ainoa portti, jota ei voi sulkea

VPN-kuuntelijan on hyväksyttävä yhteyksiä osoitteista, joita et voi ennustaa, joten se on määritelmällisesti julkinen palvelu. Se on ainoa poikkeus, jonka varaan suunnittelu on rakennettu: yksi UDP-portti OpenVPN:lle, yksi UDP-portti WireGuardille, yksi TCP-portti SSL VPN:lle. Kaikki muu kuuluu tunnelin taakse, eli sovelluspalvelujen pitäisi sitoa tunnelin osoitteeseen tai loopbackiin eikä kaikkiin rajapintoihin.

Sitominen ei kuitenkaan ole valvontaa. 0.0.0.0:aan sidottu prosessi on tavoitettavissa vain, jos sääntö päästää sen läpi, ja oletuskäytäntö on varareitti liikenteelle, jota mikään sääntö ei vastannut, ei porttia ohjaava sääntö. Pudotuksesi yläpuolelle sijoitettu hyväksyntä on yhä hyväksyntä, ja palvelun siirtäminen pois julkisesta osoitteesta on itsenäinen parannus eikä ketjun korvike.

Syöte, välitys ja NAT vastaavat eri kysymyksiin

Syöteliikenne on osoitettu isännälle itselleen, joten siellä asuvat VPN-kuuntelija ja hallintareitti. Välitysliikenne kulkee isännän läpi, ja tunneliasiakkaat tarvitsevat sitä sekä net.ipv4.ip_forward=1. Klassinen puoliksi rikki oleva kokoonpano sallii lähtevän virtauksen ja unohtaa paluusuunnan, joten asiakas saa kättelynsä valmiiksi ja sitten ei lataudu mitään; conntrack-sääntö vakiintuneelle ja liittyvälle liikenteelle kattaa sen suunnan.

NAT on kolmas kysymys. Ilman postrouting-uudelleenkirjoitusta välitetyt paketit lähtevät tunnelin yksityisellä lähteellä ja pudotetaan ylempänä, koska mikään isännän ulkopuolinen verkko ei osaa reitittää poolia takaisin. Sen säännön lähdeprefiksin on vastattava VPN-poolia, ei isännän omaa osoitetta, ja sama koskee välityssääntöä, joka nimeää asiakasaliverkon.

IPv6 on toinen käytäntö, ei jälkiajatus. Isäntä, jolla on tiukka IPv4-ketju ja avoin ip6tables-käytäntö, ei ole sulkenut mitään; palvelut ovat yhä tavoitettavissa toisen perheen kautta. Joko peilaa sääntöjoukko ip6tables:lla tai poista IPv6 tarkoituksella käytöstä julkisella rajapinnalla, ja kirjoita muistiin, kumman valitsit.

Perusta, jonka voi lukea yhdellä silmäyksellä

Aloita pudotuksesta ja lisää sitten vain se, mitä isäntä tarvitsee. Ensin loopback ja vastaukset, sitten hallintareitti, sitten tunnelikuuntelija, sitten välityskäytäntö asiakkaille:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -m conntrack --ctstate NEW -j ACCEPT
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Rajapintojen nimet, portti ja pooli ovat paikkamerkkejä; lue ne palvelimelta sen sijaan että kopioit. Tuloksen tallentaminen on yhtä tärkeää kuin sen kirjoittaminen, koska vain muistissa elävä sääntöjoukko katoaa seuraavassa uudelleenkäynnistyksessä ja avaa isännän hiljaa uudelleen. Tee siitä pysyvä jakelun mekanismilla ja pidä kopio koneen ulkopuolella sitä päivää varten, jolloin kone ei käynnisty.

Viimeisen portin sulkeminen isäntää menettämättä

Suunnittelussa on koukku. Jos SSH on olemassa vain tunnelin kautta, epäonnistunut VPN-palvelu vie SSH:n mukanaan, ja ainoa tie takaisin voi olla konsoli, jota et ole koskaan avannut. Ennen kuin suljet viimeisen julkisen portin, varmista että se konsoli on olemassa ja että todella pystyt käyttämään sitä, tai pidä yksi kapea hallintareitti, joka ei riipu tunnelista: SSH kiinteästä osoitteesta, vain avaimet, salasanatunnistus pois päältä.

Tee muutos jo muodostetusta istunnosta, älä yhteyden kautta, jota olet suodattamassa. Ajoita palautus, jotta virhe vanhenee eikä muutu pysyväksi, esimerkiksi systemd-run --on-active=10min-työ, joka palauttaa edellisen sääntöjoukon, ja pidä toinen SSH-istunto auki, kun testaat ensimmäistä. Tarkista sitten, että palautustyö todella käynnistyy, koska testaamaton palautuminen on sama kuin ei palautumista.

Tarkista reitti, älä skriptiä

Lue ladatut säännöt, älä tiedostoa, jonka piti ladata ne. Valtuutetusta ulkoisesta isännästä varmista, että vain aiotut portit vastaavat; tunnelin sisältä varmista, että palvelut, jotka halusit julkaista, ovat tavoitettavissa. Oletuksena hylkäävä käytäntö, joka estää myös tunneliliikenteen, näyttää täsmälleen samalta kuin toimiva lukitus, kunnes joku yrittää käyttää sitä.

iptables -S
iptables -t nat -S
ss -lntup
ip -4 addr show

Kirjaa sallittu portti, asiakaspooli, tunnelirajapinta, hallintalähde ja konsolimenettely kokoonpanon viereen. Seuraava poolin tai rajapinnan nimen muutos on sovitettava sekä suodattimeen että NAT-sääntöön, tai isäntä palaa puoliavoimeen tilaan kenenkään huomaamatta.

Yksi tapa on arvokkaampi kuin sääntöjoukko: todista jokaisen muutoksen jälkeen välitysreitti asiakaspyynnöllä ja palautumisreitti toisella istunnolla. Lukitus, jota et ole käyttänyt, on hypoteesi.