Rajaa OpenVPN-yhdyskäytävä yhteen lähiverkkoon UFW-säännöillä
Anna tunneliasiakkaiden tavoittaa yksi aliverkko eikä mitään muuta. Vartijaketjut ennen UFW:n varhaisia hyväksyntöjä, reittilupa ja testit, jotka todistavat rajan.
Päätä lupa ennen kuin avaat palomuuritiedoston: todennetut asiakkaat saavat avata yhteyksiä yhteen tiettyyn aliverkkoon, ja yhdyskäytävän on hylättävä kaikki muut läpikulkureitit, vaikka asiakas asentaisi lisäreittejä. Se lause on suunnitelma, ja jokainen alla oleva sääntö on olemassa sen toteuttamiseksi. Jokin laajempi, kuten koko yksityinen osoiteavaruus, internet-yhteys tunnelin kautta tai vertaisten välinen liikenne, on eri suunnitelma, joka tarvitsee oman päätöksensä. Säännöt ovat myös tahallisen tylsiä, koska älykäs palomuuri on sellainen, jota kukaan ei voi myöhemmin auditoida.
Kirjoita topologia ja lupa ensin
Esimerkki käyttää Community OpenVPN -palvelinta, jossa on käyttäjäavaruuden TUN-laite nimeltä tun0, asiakaspooli 10.77.0.0/24, ja yksi liitetty aliverkko 192.168.60.0/24 verkossa lan0. IPv4-edelleenvälitys toimii jo ja lähiverkolla on jo paluureitti pooliin, joten mikään täällä ei riipu niiden välisestä käännöksestä.
UFW omistaa tämän isännän palomuurin, eikä mikään konttisääntöjoukko tai erillinen nftables-taulu saa asentaa aikaisempaa hyväksymisreittiä. Virtauksen purkuohitus, joka ohittaa suodattimen, tekisi vartijaketjuista koristeellisia, joten varmista, ettei mikään ole käytössä. Jätä OpenVPN:n oma client-to-client -edelleenvälitys pois päältä, koska vertaisten välistä liikennettä, joka ei koskaan ylitä käyttöjärjestelmän suodatinta, ei voi rajata sillä. Ulkoinen kuuntelija ja hallintasäännöt pysyvät ennallaan, koska tämä muutos ohjaa purettua tunneliliikennettä sen sijaan, että korvaisi palomuurin.
Sijoita vartijat ennen UFW:n varhaisia hyväksyntöjä
Reittilupa ja sen perään hylkäys ei riitä tiukkaan rajaan. Vakiosäännöt before hyväksyvät vakiintuneen liikenteen ja valitut ICMP:t ennen kuin mitään käyttäjäsääntöä katsotaan, joten viime viikolla sallittu virtaus voi jäädä uuden kohderajoituksen ulkopuolelle vain siksi, että sillä on yhä tila. Varmuuskopioi UFW-tiedostot ja pidä kaistan ulkopuolinen konsoli auki ennen muokkausta.
Osion *filter tiedostossa /etc/ufw/before.rules kohdalla julista kaksi ketjua olemassa olevien julistusten viereen ja ennen mitä tahansa sääntöriviä.
:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]Heti julistusten jälkeen ja ennen syötteen ja edelleenvälityksen lupia hyppää niihin ja määrittele, mitä ne päästävät läpi.
-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard
-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP
-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROPSäilytä osion loppuosa ja sen COMMIT -rivi. Toisen suodatintaulun liittäminen tai liittymättömien sääntöjen poistaminen on se tapa, jolla palomuurimuutos muuttuu katkokseksi, ja tiedosto on yhden uudelleenkäynnistyksen päässä siitä, että se on ainoa merkityksellinen kopio.
Lue, mitä kukin vartija päästää läpi ja hylkää
Ensimmäinen ketju jatkaa käsittelyä vain, kun lähde on poolissa, kohde on se yksi aliverkko, lähtöliitäntä on lähiverkko ja paketti kulkee virtauksensa alkuperäisessä suunnassa. Kaikki muu tunnelista saapuva pudotetaan, mukaan lukien poolin ulkopuolinen lähde ja mikä tahansa kohde sallitun aliverkon ulkopuolella.
Vertaispaketti tulee sisään tun0 ja lähtee siitä, joten se epäonnistuu lähiverkon liitäntätestissä jo ennen kuin kohdetarkistukseen päästään. Uudet yhteydet lähiverkosta asiakkaita kohti epäonnistuvat myös vastaussuunnan testissä, mikä sulkee käänteisen takaisinkutsupolun oletuksena.
Kohde RETURN pitää tavallisen UFW-käytännön pelissä. Nämä ketjut suodattavat, ja seuraavaksi lisäämäsi reittilupa ratkaisee yhä, hyväksytäänkö henkiin jäänyt paketti. Juuri tämä erottelu mahdollistaa sallitun aliverkon muuttamisen yhdessä paikassa myöhemmin. Jos vartijat hyväksyisivät paketit suoraan, jokainen tuleva sääntö olisi lisättävä kahdesti.
Valtuuta aliverkko ja sulje sivuovet
Esikatsele ensin reittilupa ja poista sitten esikatselumerkintä sen käyttämiseksi: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Tarkista sen jälkeen käyttäjäsääntöjen järjestys, koska aikaisempi hylkäys voittaa yhä myöhemmän luvan. Koko aliverkon lupa on myös väärä muoto, kun vain yhden isännän HTTPS-portin pitäisi olla tavoitettavissa.
Huomaa, mitä syötteen pudotus tekee: tunneliasiakkaat eivät tavoita mitään palvelua itse yhdyskäytävällä, mukaan lukien sen lähiverkko-osoitteeseen sidottu DNS-kuuntelija. DNS:n isännöinti siellä vaatii tarkoituksellisen poikkeuksen ennen pudotusta ja tarkistetun lupasopimuksen. Jos UFW hallinnoi IPv6:ta, lisää vastaavat pudotukset myös tun0 -laitteelle tiedostossa before6.rules, koska IPv4-kohdeluettelo ei kerro mitään IPv6-paketeista.
Tarkista ladattu käytäntö, älä esikatselu
Esikatsele uudelleenlataus, ota se käyttöön huoltoikkunassa ja lue elävä sääntöjoukko.
sudo ufw --dry-run reload
sudo ufw show rawVarmista, että tunnelivartijat näkyvät ennen oletusarvoisia tila- ja ICMP-lupia. Tavallinen ufw status ei näytä käsin muokattuja before-sääntöjä, minkä vuoksi ylläpitäjät päättelevät säännön puuttuvan, vaikka se on todella ladattu. Lue raakalista ylhäältä alas sen sijaan, että etsisit katkelmaa. Jos vartijat näkyvät tila luvan jälkeen, raja ei tee sitä, mitä tiedosto antaa ymmärtää.
Testaa sitten käyttäytymistä, ei tekstiä. Avaa tuore yhteys sallittuun isäntään ja seuraa vastausta, ohjaa harmiton pyyntö aliverkon ulkopuoliseen kohteeseen ja varmista, että se kuolee, kokeile vertaisyhteyttä, kokeile yhdyskäytävässä paikallista palvelua ja kokeile pyytämätöntä lähiverkosta asiakkaaseen -yhteyttä. Sisällytä yksi rajauksen ulkopuolinen virtaus, joka oli olemassa ennen muutosta, ja tyhjennä vain se virtaus sen sijaan, että tyhjentäisit koneen koko seurantataulun.
Kirjaa rajat sääntöjen viereen: tämä rajaa läpikulkua eikä mitään muuta. Se ei estä asiakasta käyttämästä omaa internet-yhteyttään, ei estä sallittua lähiverkkoisäntää välittämästä liikennettä eteenpäin eikä korvaa todennusta sallittujen palvelujen sisällä.