Minne VPN-NAT kuuluu UFW:n before.rules-tiedostossa ja miten se testataan

NAT-sääntö, joka toimii komentotulkkiin kirjoitettuna, epäonnistuu, kun se liitetään before.rules-tiedostoon, koska tiedosto ei ole skripti. Se on palautusmuotoinen asiakirja, jossa on taulukko-osiot, ketjujen esittelyt ja COMMIT-merkki jokaista taulukkoa varten. Väärässä paikassa oleva rivi joko keskeyttää koko palautuksen tai pudottaa hiljaa sääntöjä, joiden luulit olevan siellä. Alla oleva toimintaohje sijoittaa katkelman sinne, missä kehys odottaa sitä, ja todentaa tuloksen ennen seuraavaa uudelleenlatausta.

Komentotulkin komento ei ole palautustiedosto

iptables -t nat -rivillä alkava rivi on ohje iptables-binäärille, kun taas tiedosto, jonka UFW lukee, on kuvaus täydellisestä sääntöjoukosta. Ero ei ole kosmeettinen: palautusmuodon on tiedettävä, missä taulukossa se on, mitkä ketjut ovat olemassa ja mihin taulukko päättyy. Asiakirjaan liitetty komento on joko syntaksivirhe tai, pahempaa, väärään taulukkoon liitetty sääntö. Kehys lataa nämä tiedostot palautustyökalujen kautta juuri siksi, että ne ovat deklaratiivisia eivätkä peräkkäisiä.

Asiakirja ladataan myös kokonaisuutena, joten yksi virheellinen osio voi estää muun tiedoston käyttöönoton. Siksi pieni virhe NAT-katkelmassa vie mukanaan myös suodatussäännöt, ja niin palomuurin muutoksesta tulee käyttökatko.

Sijoita katkelma olemassa olevaan taulukko-osioon

NAT-katkelmalla on muoto, ja muoto on tärkeämpi kuin sen sisällä oleva säännön teksti. Taulukon otsikko avaa osion, ketjujen esittelyt asettavat laskurit, säännöt seuraavat ja COMMIT sulkee osion.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

Yllä oleva pooli ja liitäntä ovat paikkamerkkejä omillesi; rakenne on osa, joka kannattaa kopioida. Jos tiedostossa on jo *nat-osio, lisää sääntö sen osion sisään sen sijaan että avaisit toisen, koska muoto odottaa yhtä COMMITia taulukkoa kohden ja kaksi osiota samalle taulukolle on korjaus, joka odottaa tapahtumistaan. Pidä jakelun ketjumääritelmät ehjinä, mukaan lukien ne, jotka toimittaja lisäsi omaa integraatiotaan varten. UFW-kehyksen käsikirja dokumentoi before-, user- ja after-tiedostot sekä vaatimuksen vastaavasta COMMITista.

Jos tiedosto osoittautuu tyhjäksi, älä täytä sitä opetusohjelmasta. Vahvista, mikä paketti sen omistaa ja mikä käytössä oleva käytäntö todella on, koska tyhjä pysyvä tiedosto ei todista, ettei ytimessä ole sääntöjä, eikä ladattu sääntöjoukko todista, että seuraavalla uudelleenlatauksella on täydellinen tiedosto luettavaksi. Palauta ensin tuettu perustaso ja ota sitten sivuston muutokset uudelleen käyttöön sen päälle.

Testaa ehdokas soveltamatta sitä

Palautustyökalu voi jäsentää ja rakentaa sääntöjoukon soveltamatta sitä, mikä on halvin saatavilla oleva testi. Aja se suojatulle kopiolle, älä live-tiedostolle, ja lue virheteksti, älä vain poistumistilaa. Jäsennysvirhe nimeää rivin ja yleensä taulukon, mikä on enemmän kuin epäonnistunut uudelleenlataus kertoo.

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

Tämän tarkistuksen läpäisy todistaa, että asiakirja jäsennetään, eikä mitään muuta. Se ei todista, että ehdokas sisältää edelleen jokaisen ketjun, josta UFW riippuu, että se sallii vain aiottujen lähteiden käytön tai että etähallinta pysyy tavoitettavissa. Ne ovat erillisiä tarkistuksia, ja viimeinen ansaitsee toisen istunnon, joka avataan ennen aloittamista.

Valitse työkalu, joka vastaa asennettua taustajärjestelmää ja osoiteperhettä. Isäntä, joka ajaa nft-taustajärjestelmää yhteensopivuuskerroksen kautta, tarvitsee vastaavan komennon, ja IPv6-säännöt asuvat aivan eri tiedostossa.

Pidä edelleenlähetys, NAT ja käyttöoikeuskäytäntö erillään

Lähteen käännös ratkaisee osoitteistusongelman eikä anna mitään. Edelleenlähetys on erillinen lupa, jota sysctl ja suodatustaulu ohjaavat, ja se on se, mikä unohdetaan, kun tunneli reitittää mutta ei välitä liikennettä. Käyttöoikeuskäytäntö on kolmas päätös siitä, mitkä lähteet voivat saavuttaa mitkä palvelut, eikä mikään NAT-sääntö ilmaise sitä. Juuri näiden kolmen erillään pitäminen tekee vianselvityksestä mahdollista yhden epämääräisen oireen sijaan.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

Lue nämä kolme tulosta yhdessä, älä yksi kerrallaan. Masquerade-sääntö, jonka edelleenlähetys on pois päältä, tuottaa asiakkaan, joka yhdistää eikä saavuta mitään, mikä asiakkaan puolelta näyttää täsmälleen reititysviidalta ja lähettää ihmiset väärään tiedostoon. Suodatustaulu on myös paikka, johon liian laaja accept kätkeytyy, joten tarkista sen oletuskäytäntö siellä ollessasi.

Vahvista uudelleenlataus, hylkäys ja VPN:n menetys

Kolme havaintoa muodostavat täydellisen hyväksymistestin: uudelleenlataus onnistuu, sallittu asiakastoimenpide toimii ja pyyntö, joka pitäisi hylätä, todella hylätään. Kolmas niistä ohitetaan, ja se on ainoa todiste siitä, että käytäntö tekee ylipäätään mitään.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

Testaa sitten vika, jota varten suunnittelit. Pudota tunneli ja katso, mitä isäntä tekee, koska käytäntö, joka toimii vain VPN:n ollessa päällä, on käytäntö, jolla on lausumaton riippuvuus. Lataa vielä kerran uudelleen sen jälkeen todistaaksesi, että toimivan tuloksen tuottaa tiedosto eikä jokin jäljelle jäänyt ajonaikainen tila.

IPv4:n NAT ei kerro mitään IPv6:sta, joten ilmoita aiottu kattavuus molemmille perheille samassa muistiinpanossa kuin sääntö. Tavoitteena on johdonmukainen hallittu käytäntö, eikä katkelma, joka sattui jäsentymään, ole todiste siitä.