UFW pudottaa VPN:n DNS-palvelimen heti, kun tunneli nousee
UFW:n oletusestokäytäntö kattaa myös tunnelin rajapinnan. Lajittele liikenne suunnan mukaan, salli työnnetty ratkaisija tun0:ssa ja avaa sitten ulompi polku.
Nimet lakkaavat ratkeamasta sillä hetkellä, kun VPN yhdistyy, kun taas ping julkiseen osoitteeseen vastaa yhä eikä palomuurin tila näytä mitään väärältä. Käytännössä mikään ei muuttunut; muuttui se, että uusi rajapinta ilmestyi, ja oletusesto kattaa sen ensimmäisestä paketista lähtien. UFW päättää suunnan ja rajapinnan mukaan, joten langattomalle yhteydelle kirjoitettu sääntö ei kerro mitään tunnelista lähtevästä liikenteestä. Korjaus on kourallinen kapeita sääntöjä tietyssä järjestyksessä.
Oire ilmaantuu vasta, kun tunneli on pystyssä
Oletusestokäytäntö tekee täsmälleen sen, mitä sille on sanottu: kaikki ilman vastaavaa sääntöä hylätään, jokaisella olemassa olevalla rajapinnalla. Tunnelia ei ollut, kun säännöt kirjoitettiin, joten mikään niistä ei voi osua siihen, ja esto, joka oli aina siellä, koskee nyt nimien ratkaisua. Suora liikenne kirjaimelliseen osoitteeseen voi yhä toimia, kun laajempi lupa kattaa sen, ja siksi ping julkiseen ratkaisijaan onnistuu, kun taas nimen haku epäonnistuu. Aukko on sääntö rajapinnalle, jota käytäntö ei ole koskaan nähnyt.
Se selittää myös, miksi vika kääntyy siististi: pudota tunneli ja nimet ratkeavat taas, koska kysely palaa rajapinnalle, jolla on säännöt. Käytäntö, joka epäonnistuu vain tunnelin ollessa pystyssä, ei ole DNS-ongelma, ja itse ratkaisijan säätäminen tuhlaa täällä eniten aikaa. Lue rajapintaluettelo ennen ratkaisijan kokoonpanon lukemista.
Kolme suuntaa, kolme erilaista sääntöjoukkoa
Yksi istunto koskee sääntöjä useammassa kuin yhdessä suunnassa, ja tunneli lisää toisen rajapinnan lähes jokaiseen niistä. Kun liikenne lajitellaan ensin suunnan ja rajapinnan mukaan, lopusta tulee mekaanista, koska jokainen alla oleva rivi tarvitsee oman sääntönsä omalle paikalleen. Esimerkit käyttävät tun0:aa ja 10.8.0.0/24-poolia, joten korvaa nimet ja vaihteluvälit asiakkaan omasta tulosteesta otetuilla.
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
Kaksi riviä sekoitetaan usein, koska molemmat mainitsevat tunnelin. Ratkaisijan sääntö sallii liikenteen, jonka asiakas lähettää tunneliin, kun taas SSH:n sääntö sallii liikenteen, jonka palvelin vastaanottaa sieltä; ne elävät eri koneilla ja epäonnistuvat toisistaan riippumatta. Useimmin unohdettu rivi on toinen, koska asiakas ei voi rakentaa tunnelia lainkaan ennen kuin sen liikenne palvelimen julkiseen osoitteeseen on sallittu. Työskentele ylhäältä alas, ja jokaisella vikalla on yksi mahdollinen syy.
Työnnetty ratkaisija tarvitsee oman sääntönsä
Kantaako tunneli DNS:ää, riippuu siitä, mitä palvelin lähettää. Palvelin, joka työntää ratkaisijavalinnan, asentaa yksityisen osoitteen asiakkaan kokoonpanoon, ja se osoite on reititettävissä vain tunnelin kautta. Jos palvelin ei työnnä mitään, asiakas pitää ratkaisijan, joka sillä jo oli, eikä alla olevilla säännöillä ole mitään sallittavaa. Tarkista työnnetty tila ja nykyinen kyselytulos ennen kuin kirjoitat mitään:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedTilatuloste nimeää käytössä olevan ratkaisijan ja linkin, johon se on sidottu, ja sen takana oleva reittihaku näyttää, mikä rajapinta kuljettaisi kyselyn siihen osoitteeseen. Kun ratkaisija istuu toisella linkillä, ongelma on palomuuria aiempi eikä mikään sääntö auta. Kun molemmat ovat yhtä mieltä tunnelista, tarvitaan kaksi sääntöä, koska UDP kuljettaa useimmat kyselyt ja TCP ottaa vastuun, kun vastaus katkaistaan. Kirjaa molemmat arvot, koska juuri ne säännöt nimeävät:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'Avaa ulompi polku ennen sisempää
Asiakkaan on päästävä palvelimen julkiseen osoitteeseen ennen kuin tunnelia on olemassa, joten sen sääntö istuu fyysisellä linkillä ja sen on oltava paikallaan ensin. Käytäntö, joka sallii ratkaisijan mutta unohtaa palvelimen, jättää asiakkaan täysin kyvyttömäksi rakentamaan tunnelin, ja tämä oire laitetaan yleensä kill switchin syyksi. Salli sitten palvelut, jotka todella halusit tunnelin kautta, yksi kapea sääntö kerrallaan sen sijaan, että avaisit rajapinnan kokonaan. Kapeat säännöt ovat syy siihen, miksi esto voi pysyä paikallaan.
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'Järjestys on tärkeä testatessa, koska ensimmäinen sääntö on se, joka ylipäätään päästää tunnelin nousemaan. Lisää se, yhdistä ja varmista, että tunneli on pystyssä ennen palvelusäännön lisäämistä, koska molempien tekeminen kerralla tarkoittaa, ettei vika kerro sinulle mitään siitä, kumpi puolisko on väärin. Korvaa yllä oleva dokumentaatio-osoite päätepisteellä, jota varten asiakas on määritetty.
Viimeistele asiakaspuoli katkaisemalla yhteys tarkoituksella. Esto ei saisi silti sallia liikennettä, jonka jätit tarkoituksella pois, koska ratkaisija, joka vastaa tunnelin ollessa pystyssä, kattaa vain puolet käytännöstä, joka epäselvässä tapauksessa estää.
Yhdistävä asiakas ei ole vielä päästetty sisään
Palvelimella on oma suuntansa harkittavana, eikä kättelyn suorittava asiakas silti tavoita mitään palvelimella ajettavaa ennen kuin palvelin päästää sen sisään. Julkisen kuuntelijan sääntö sallii vain tunnelin olemassaolon; se ei päästä tunnelin liikennettä sisään. Palvelimella se on kaksi sääntöä plus yksi tarkistus siitä, että palvelu todella kuuntelee:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'Säännön poolin on oltava yhtä suuri kuin alue, jonka palvelin jakaa, ja tunnelin numeron on vastattava sitä, jonka palvelin loi, koska toisen rajapinnan sääntöä ei erota säännön puuttumisesta. limit on tarkoituksellinen hallintaportille, koska se rajoittaa toistuvia yhteyksiä sen sijaan, että hyväksyisi ne rajatta. Kuuntelijatarkistus erottaa suljetun portin hylätystä paketista, jotka näyttävät asiakkaan puolelta samoilta. Numeroidut säännötkään eivät ole koko kuva: UFW:n before-säännöt ja kaikki käsin kirjoitetut nftables-rivit osuvat aiemmin ja voivat yhä hylätä paketin, jonka luettelo näyttää sallivan.