iptables-isäntä vain VPN:llä: nimeä tun-laite, älä tun+

-o tun+:n kirjoittaminen tuntuu täsmälliseltä ohjeelta ja on todellisuudessa jokerimerkki, joka kattaa jokaisen ytimen tunnelin. Toinen VPN-asiakas, konttisilta tai kaatuneen istunnon jälkeensä jättämä liitäntä täyttävät sen kaikki, ja silloin isäntä sallii liikenteen, jonka käytäntö oli tarkoitettu estämään. Alla oleva ohje kiinnittää yhden laitenimen, järjestää poikkeukset niin, että tunneli voi todella muodostua, ja jättää sinulle paluutien, jos säännöt osuvat huonosti. Jokainen vaihe on tarpeeksi lyhyt peruttavaksi yksinään.

Vaihe 1: kirjaa säännöt, jotka sinulla on nyt

Ennen oletuskäytännön muuttamista tallenna nykytila, jotta palautus on komento eikä muistikuva. iptables-save > /root/iptables.pre kirjoittaa jokaisen taulun tiedostoon, jonka voit palauttaa, ja toinen pääte, jossa on avoin root-istunto, ei ole vainoharhaisuutta, kun asetettava käytäntö pudottaa sen kuljettaman yhteyden. Jos työskentelet etänä, ajasta myös flush hätäkatkaisimeksi.

Listaa sitten liitännät, sillä nimi, jonka oletit, on nimi, joka sinun olisi pitänyt lukea: ip -br link näyttää, mitä juuri nyt on olemassa, eikä tunneli näy ennen kuin se on ylhäällä. Kirjoita laitteiden nimet muistiin sitä mukaa kun luet niitä.

Vaihe 2: anna tunnelille oma nimi

OpenVPN hyväksyy asiakasasetuksissa dev tun_work, ja silloin Linux luo liitännän täsmälleen sillä nimellä sen sijaan, että varaisi tun0. Nimi pysyy vakaana uudelleenyhdistämisten yli, kunhan mikään muu ei vaadi sitä, ja juuri se tekee laitteen nimeävästä säännöstä merkityksellisen.

Missä nimeä ei voi hallita, sovita sen sijaan tunnelin osoitteeseen tai pakettimerkkiin. Molemmat toimivat, molemmat ovat vaikeampia lukea ja molemmat epäonnistuvat hiljaisemmin, kun tunneli numeroi itsensä uudelleen. Sovita joka tapauksessa yhteen asiaan ja kerro selvästi mihin.

Vaihe 3: kirjoita käytäntö niin, että endpoint-poikkeus on ensin

Vain VPN:llä toimiva isäntä on oletuskiellon isäntä ja lyhyt poikkeuslista, ja tärkein poikkeus on se, joka antaa tunnelin olla olemassa. Rakenna se tässä järjestyksessä, endpoint-sääntö ennen tunnelilaitesääntöä, jotta kättelyllä on minne mennä:

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Endpointin kirjaimellinen osoite ja portti kuuluvat palveluntarjoajallesi, eivät tälle sivulle. Jos endpoint on isäntänimi, selvitä se kerran ja kiinnitä tulos, koska sääntö ei voi hakea nimeä ja pyörivä vastaus rikkoo käytännön hiljaa seuraavan DNS-muutoksen jälkeen. Tarkista myös portti, sillä palveluntarjoajat, jotka siirtävät sinut TCP 443:een, tarvitsevat muuten säännön, jota kukaan ei kirjoittanut. Tunneli, joka toimii vain yhdellä protokollalla, on yleensä juuri tämä puute eikä palomuurin vika.

Reitittimellä sama muoto menee FORWARD-ketjuun sen takana oleville asiakkaille, ja reitittimen oma liikenne tarvitsee omat sääntönsä. Sääntöjoukko, joka kattaa vain edelleenlähetetyt paketit, jättää SSH:n ja DNS:n vanhalle polulle, ja niin reitittimestä tulee tavoittamaton sinä hetkenä, kun tunneli nousee.

Vaihe 4: tarkista järjestys, ei vain olemassaolo

Säännöt arvioidaan järjestyksessä, joten aikaisempi ACCEPT yksinkertaisesti kätkee myöhemmin lisäämäsi REJECTin. established- ja related-vastaavuus on se, mikä päästää vastaukset omiin lähteviin pyyntöihisi palaamaan avaamatta yleistä saapuvan liikenteen polkua, ja sen sijoittaminen tunnelin hyväksynnän jälkeen tarkoittaa, että pudonnut tunneli päästää yhä paluuliikennettä omalla liitännällään.

Pidä sääntöjen määrä niin pienenä, että ne voi lukea yhdeltä näytöltä. Sääntöjoukko, jota et voi auditoida, on se, jota paikkaat lisäämällä poikkeuksia yläreunaan, ja niin oletuskiellon käytännöt saavat vähitellen oletussallinnuksen reunan. Laske ACCEPTit ennen muutosta ja sen jälkeen.

Vaihe 5: tee siitä käynnistyksen ja osoiteperheen kestävä

Käsin syötetyt säännöt katoavat uudelleenkäynnistyksessä, joten lataa ne jakelun palomuuripalvelusta tai unitista, joka käynnistyy sen jälkeen kun tunneliliitäntä on olemassa. tun_work:een viittaaminen skriptissä, joka suoritetaan ennen OpenVPN:n käynnistymistä, on tavallinen tapa tuottaa pudonneen liikenteen käynnistyssilmukka.

Tarkista sitten IPv6 erikseen, sillä hyvä IPv4:n oletuskiellon käytäntö ei kerro toisesta perheestä mitään. ip -6 route kertoo, onko isännällä reitti, joka voisi kuljettaa liikennettä sellaisen tunnelin ohi, joka käsittelee vain IPv4:n, ja ip6tables tai nftables tarvitsee omat vastaavat sääntönsä. Testaa IPv6-only-kohteella sen sijaan, että luottaisit sääntöjoukon symmetriaan.

Vaihe 6: varmista ja ole valmis palauttamaan

Nosta tunneli, varmista että aiottu palvelu toimii, ja kokeile sitten jotain, minkä käytännön pitäisi hylätä. Palauta iptables-restore < /root/iptables.pre:lla, jos vastaus yllättää sinut, ja aloita sääntöjen muokkaaminen vasta sitten. Pysyvyys ja testattu palautuspolku tekevät tästä muutoksen, jonka voit tehdä kahdesti.