Estä yksi kohdeala jokaiselta VPN-asiakaspoolilta

Yksi sääntö voi pitää hyväksytyn VPN-poolin poissa kohdealueelta häiritsemättä mitään muuta, mitä yhdyskäytävä tekee. Sääntö itsessään on lyhyt; sen toimivuuden ratkaisevat koukku, jossa se elää, ja sen sijainti ketjussa. Näiden kahden kanssa erehtyminen tuottaa palomuurin, joka näyttää oikealta ja käyttäytyy epäjohdonmukaisesti. Aloita siitä, mitä paketti tekee, kun sääntö näkee sen.

Mitä sääntö todella täsmäyttää

Sääntö täsmäyttää kolme asiaa kerralla: tuloliittymän, lähdeprefiksin ja kohdeprefiksin. Kaikkien kolmen on oltava tosia ennen kuin drop toteutuu, ja juuri se pitää sen kapeana. Sen lukeminen yhtenä lausekkeena on helpompaa kuin kolmena erillisenä käytäntönä.

Liittymän täsmäytys erottaa välitetyn asiakasliikenteen yhdyskäytävän omista yhteyksistä. Ilman sitä sääntö, joka nimeää vain lähdepoolin, vaikuttaisi myös paketteihin, joita yhdyskäytävä itse tuottaa kyseisestä osoitteesta, jos se koskaan niin tekee. Lähdeprefiksi rajaa käytännön hyväksyttyihin asiakkaisiin ja kohdeprefiksi yhteen alueeseen. Lue sääntö leikkauksena, älä listana.

Kirjoita kolme arvoa ennen kuin muutat mitään: tunneliliittymän nimi, pool, jonka palvelin jakaa, ja prefiksi, jonka aiot evätä. Kirjoitusvirhe missä tahansa niistä tuottaa säännön, joka jäsennetään puhtaasti eikä suojaa mitään. Pidä nämä kolme arvoa muutosmerkinnässä säännön vieressä.

Koukku päättää, keihin sääntö kohdistuu

netfilter-ketju kiinnitetään koukkuun, ja koukku päättää, mitkä paketit ketju ylipäätään näkee. forward-koukku näkee liikenteen, joka reititetään yhdyskäytävän kautta, ja juuri sitä asiakkaalta kohteeseen -liikenne on. Kaikki muu ketjussa on suunnattu toiselle yleisölle.

input-koukku näkee liikenteen, joka on osoitettu yhdyskäytävälle itselleen, joten sinne sijoitettu sääntö ohjaa pääsyä sen omiin palveluihin eikä transit-liikennettä. output-koukku näkee liikenteen, jonka yhdyskäytävä itse tuottaa, ja se on päinvastainen siihen, mitä asiakaspoolin käytäntö tarvitsee. Ketjujen nimet ovat mielivaltaisia tunnisteita, jotka sääntökokonaisuuden kirjoittaja valitsi, joten älä päättele koukkua nimestä. Tarkista, mihin ketju on kiinnitetty, ennen kuin oletat, mitä se voi täsmäyttää.

Kiinnityksen lukeminen on yhden rivin tarkistus, joka estää sääntöä päätymästä ketjuun, joka ei näe pakettia koskaan.

Sijoita sääntö ennen laajaa acceptia

Säännöt arvioidaan järjestyksessä ja ensimmäinen päätös voittaa. Laaja accept aiemmin ketjussa lopettaa arvioinnin niiden pakettien osalta, jotka se täsmäyttää, joten myöhemmin lisätty drop ei koskaan suoritu niille. Tämä järjestyssääntö on koko syy siihen, miksi oikealta näyttävä sääntö voi olla vaikuttamatta.

Lisää sääntö ennen acceptia sen sijaan, että liittäisit sen loppuun. Jos ketju jo sisältää yleisen acceptin tunneliliittymälle, uuden säännön on oltava sitä ennen, muuten se on vain koriste. Tarkista syntyvä järjestys, älä muokkaamaasi tiedostoa, koska useasta tiedostosta koottu sääntökokonaisuus ei välttämättä vastaa mitään yksittäistä niistä. Vahvista sitten poolista tulevalla testipaketilla.

sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.conf

Kolmas komento jäsentää tiedoston sitä soveltamatta, mikä nappaa syntaksivirheet ennen kuin niistä tulee katkos. Käytä käyttöönottosuunnitelmalla, sillä väärä sääntö forward-ketjussa voi katkaista tunnelin, jonka yli työskentelet.

Olemassa olevat vuot eivät välitä uudesta säännöstäsi

Ennen säännön olemassaoloa luotu conntrack-merkintä täsmää edelleen aiempaan acceptiin. Siksi uusi drop näyttää joskus toimivan uusille yhteyksille ja tekevän tyhjän testattavalle.

Lue tilan täsmäytys ketjun alussa. Jos se hyväksyy established- ja related-liikenteen ennen sääntöäsi, jokainen jo käynnissä oleva vuo jatkaa virtaamistaan, kunnes sulkeutuu. Yleensä se on käyttäytyminen, jonka haluat hätäsäännölle, ja se on hämmentävää, kun odotat välitöntä katkaisua. Päätä ennen käyttöönottoa, mitä vaikutusta haluat. Testi, joka käyttää avointa yhteyttä uudelleen, kertoo sinulle väärän tarinan.

sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'

Ensimmäinen komento näyttää, onko vuo olemassa, ja toinen näyttää, hyväksyykö varhainen tilasääntö sen edelleen. Molemmat ovat vain luku -komentoja ja turvallisia tapahtuman aikana.

Mitä tämä sääntö ei ole

Sääntö ei ole verkkotunnusten musta lista, IPv6-käytäntö eikä yksittäisen sovellustilin rajoitus.

Jokainen niistä tarvitsee oman mekanisminsa. Verkkotunnuksen esto joutuu ratkaisemaan nimiä, mitä pakettisuodatin ei tee. IPv6-liikenne tarvitsee oman täsmäytyksensä, koska ip-lauseke ei kerro mitään ip6-paketeista. Sovellustason rajoitus kuuluu palvelulle tai todennetulle välityspalvelimelle, ei prefiksin täsmäytykselle. Juuri näiden vaatimusten erillään pitäminen estää yhden kapean säännön kuormittamisen neljällä tehtävällä.

Sopimus, jonka tämä sääntö antaa, on täsmällinen: liikenne hyväksytystä poolista yhteen kohdeprefiksiin evätään, kun taas liittymätön yhdyskäytävän liikenne säilyttää nykyisen käytäntönsä. Kirjoita se lause säännön viereen, niin seuraava tietää, mihin se oli tarkoitettu.