ufw allow 443 ei tehnyt mitään VPN:n takana olevalle palvelulle

Ping onnistuu VPN-asiakkaalta, TCP-palvelu aikakatkeaa eikä ufw allow 443/tcp muuta yhtään mitään. Kun sovellus pyörii yhdyskäytävän takana olevalla isännällä eikä itse yhdyskäytävällä, tuo lupa kirjoitettiin väärälle liikennepolulle. Pakettia ei ole osoitettu palomuurille eikä sitä toimiteta paikalliselle prosessille, joten saapuvien sääntöjen silmiin se ei koskaan tule. Korjaus on välitettyyn virtaan kohdistuva reittisääntö, ja todiste siitä on jo lokissa.

Ratkaise, onko kohde paikallinen vai välitetty

Lue paketti niin kuin ydin sen näkee. Yhdyskäytävällä olevalle palvelulle toimitettu liikenne on paikallista saapuvaa liikennettä. Liikenne, jonka yhdyskäytävä reitittää edelleen toiselle isännälle, on välitettyä, ja UFW pitää kahdelle polulle erillisiä sääntöjoukkoja. Eron ratkaisevat kohdeosoite ja reittihaku, ei se liitäntä, jolta paketti saapui.

Lokirivi, joka näyttää saman liitännän sekä IN- että OUT-kentässä, voi silti kuvata reititettyä pakettia, koska yhdestä laitteesta asiakkaita sisään ja ulos kuljettava tunneli näyttää täsmälleen tuolta. Kohdeosoite ratkaisee kysymyksen nopeammin kuin liitäntöjen nimet. Saman nimen näkeminen kahdesti ei todista paikallista toimitusta, eikä sellaisen tunneliliitännän keksiminen, jota käyttöönotto ei koskaan luonut, auta myöskään.

Lue esto ennen minkään säännön lisäämistä

Toista yksi valtuutettu yhteysyritys ja kirjaa sen lähde, kohde, protokolla ja kohdeportti niin kuin yhdyskäytävä ne tallensi. Vertaa näitä neljää arvoa lokimerkintään ja palvelun todelliseen sijaintiin. Aiempi onnistunut ping todistaa vain, että sen oma vaihto oli sallittu, ja palomuuri voi kohdella sovellukseen menevää TCP SYN -pakettia aivan eri tavalla.

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

Ensimmäinen komento palauttaa tuomion kenttineen ja toinen näyttää, mitä on jo ladattu ja missä järjestyksessä. Lue molemmat ennen kuin muutat mitään, sillä aiempi esto sääntösi yläpuolella selittää saman oireen ilman mitään puuttuvaa sääntöä.

Kirjoita kapein sopiva reittisääntö

Tässä esimerkissä asiakkaat saapuvat liitännälle tun0 osoitteesta 172.20.8.0/24, palvelu kuuntelee osoitteessa 10.30.0.15 portissa 8443 ja yhdyskäytävä poistuu liitännän ens5 kautta. Nämä arvot valittiin, jotta ne eivät näytä lainkaan pilven VPC:n oletukselta 10.0.0.0/16 tai kodin verkolta 192.168.0.0/16, ja 8443 pitää esimerkin erossa yhdyskäytävän omasta 443-kuuntelijasta.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

Koeajo tulostaa sääntöjoukon, joka syntyisi, ja se on halvin tapa nähdä, laskeutuuko sääntösi ennen olemassa olevaa estoa vai sen jälkeen. Varmista liitäntöjen nimet ja sisäiset osoitteet käyttöönottoa vasten, älä esimerkkiä, ja muista, että kun kohde-NAT ajetaan ensin, suodatin näkee käännetyn kohteen.

Pidä paluupolku tilatietoisena

UFW seuraa sallittuja yhteyksiä, joten sallitun välitetyn virran vastaukset hyväksytään ilman nimenomaista käänteistä sääntöä. Rajoittamattoman säännön lisääminen vastakkaiseen suuntaan asioiden toimimiseksi laajentaa käytäntöä paljon yhden palvelun ulkopuolelle eikä sitä tarvita tavallisessa pyyntö-vastaus-vaihdossa. Pidä paluupolku implisiittisenä ja sääntöjoukko luettavana.

Ota sääntö käyttöön vasta kun koeajo vastaa aikomustasi, ja varmista sitten, että järjestetty luettelo näyttää sen odotetussa kohdassa. Pidä VPN-kuuntelija ja hallintasäännöt erillisinä asioina, sillä niiden muuttaminen on eri päätös kuin yhden sovelluksen päästäminen läpi. Merkitse muutos samaan paikkaan, johon topologia on kirjattu, jotta seuraavan insinöörin ei tarvitse löytää sitä uudelleen pakettikaappauksesta.

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

Tarkista, mitä UFW ei voi valvoa puolestasi

Oikea sääntö tarvitsee silti ytimen välityksen ja reitin, joka saavuttaa palvelun. Varmista molemmat ennen kuin syytät palomuuria toisen kerran.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Katso sitten isännän ulkopuolelle. Pilvi-instanssissa vieraan UFW-käytäntö ei korvaa tietoturvaryhmiä, aliverkon ACL:itä tai tarjoajan omaa välitysmääritystä, joten paikallinen esto on todiste yhdestä kerroksesta eikä todiste siitä, että kaikki muut kerrokset sallivat palvelun.

Lopeta testaamalla uusi yhteys palomuurin ollessa päällä, sallitusta lähteestä ja asiasta riippumattomasta lähteestä. UFW:n poistaminen käytöstä poistaa oireen ja tuhoaa todisteen samassa komennossa, minkä vuoksi sen pitäisi olla viimeinen koe eikä ensimmäinen.