UFW viskab VPN-i DNS-serveri välja, kui tunnel püsti tõuseb
UFW vaikimisi keelav poliitika katab ka tunneli liidese. Sorteeri liiklus suuna järgi, luba tõugatud lahendaja tun0-l ja ava seejärel välimine tee.
Nimed lakkavad lahendamast hetkel, mil VPN ühendub, samal ajal kui ping avalikule aadressile vastab endiselt ja tulemüüri olek ei näita midagi valesti näivat. Poliitikas ei muutunud miski; muutus see, et ilmus uus liides, ja vaikimisi keeld katab selle juba esimesest paketist. UFW otsustab suuna ja liidese järgi, seega traadita lingi jaoks kirjutatud reegel ei ütle midagi tunnelist väljuva liikluse kohta. Parandus on peotäis kitsaid reegleid, mida rakendatakse kindlas järjekorras.
Sümptom ilmneb alles pärast seda, kui tunnel on püsti
Vaikimisi keelav poliitika teeb täpselt seda, mida talle öeldi: kõik, millel pole sobivat reeglit, lükatakse tagasi, igal olemasoleval liidesel. Tunnelit polnud reeglite kirjutamise ajal olemas, seega ei saa ükski neist seda tabada, ja keeld, mis oli alati olemas, kehtib nüüd nimede lahendamisele. Otsene liiklus otsesele aadressile võib ikkagi töötada, kui laiem luba seda katab, ja seetõttu õnnestub ping avalikule lahendajale, samal ajal kui nime otsimine ebaõnnestub. Lünk on reegel liidese jaoks, mida poliitika pole kunagi näinud.
See selgitab ka, miks rike puhtalt pöördub tagasi: lase tunnel alla ja nimed lahendatakse jälle, sest päring naaseb liidesele, millel on reeglid. Poliitika, mis ebaõnnestub ainult siis, kui tunnel on püsti, pole DNS-probleem, ja lahendaja enda häälestamine raiskab siin kõige rohkem aega. Lugege liideste loendit enne lahendaja konfiguratsiooni lugemist.
Kolm suunda, kolm erinevat reeglistikku
Üks seanss puudutab reegleid rohkem kui ühes suunas, ja tunnel lisab teise liidese peaaegu igale neist. Kui sorteerite liikluse esmalt suuna ja liidese järgi, muutub ülejäänu mehaaniliseks, sest iga allolev rida vajab oma reeglit oma kohas. Näited kasutavad tun0 ja 10.8.0.0/24 kogumit, seepärast asendage nimed ja vahemikud kliendi enda väljundist saadutega.
| 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 |
Kaks rida aetakse sageli segi, sest mõlemad mainivad tunnelit. Lahendaja reegel lubab liiklust, mille klient saadab tunnelisse, samas kui SSH reegel lubab liiklust, mille server sealt vastu võtab; need elavad eri masinates ja ebaõnnestuvad sõltumatult. Kõige sagedamini unustatud rida on teine, sest klient ei saa tunnelit üldse üles ehitada, kuni tema liiklus serveri avalikule aadressile on lubatud. Töötage ülalt alla ja igal rikkel on üks võimalik põhjus.
Tõugatud lahendaja vajab oma reeglit
Kas tunnel kannab DNS-i, sõltub sellest, mida server saadab. Server, mis tõukab lahendaja valiku, paigaldab kliendi konfiguratsiooni privaatse aadressi, ja see aadress on marsruuditav ainult läbi tunneli. Kui server ei tõuka midagi, jätab klient alles lahendaja, mis tal juba oli, ja allolevatel reeglitel pole midagi lubada. Kontrollige tõugatud olekut ja praegust päringu tulemust enne, kui midagi kirjutate:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedOlekut väljund nimetab kasutatava lahendaja ja lingi, millega see on seotud, ja selle taga olev marsruudiotsing näitab, milline liides kannaks päringu sellele aadressile. Kui lahendaja asub teisel lingil, on probleem tulemüürist varasem ja ükski reegel ei aita. Kui mõlemad tunnelis kokku lepivad, on vaja kahte reeglit, sest UDP kannab enamikku päringuid ja TCP võtab üle, kui vastus kärbitakse. Märkige üles mõlemad väärtused, sest need on need, mida reeglid nimetavad:
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'Avage välimine tee enne sisemist
Klient peab jõudma serveri avaliku aadressini enne, kui tunnel olemas on, seega selle reegel istub füüsilisel lingil ja peab olema kohal esimesena. Poliitika, mis lubab lahendaja, aga unustab serveri, jätab kliendi tunnelit üldse ehitada suutmatusse olekusse, ja seda sümptomit süüdistatakse tavaliselt kill switch-i. Seejärel lubage teenused, mida te tegelikult tunnelist tahtsite, üks kitsas reegel korraga, selle asemel et liidest tervikuna avada. Kitsad reeglid on põhjus, miks keeld saab paigale jääda.
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ärjekord on testimisel oluline, sest esimene reegel on see, mis laseb tunnelil üldse tõusta. Lisage see, ühenduge ja kinnitage, et tunnel on püsti, enne teenuse reegli lisamist, sest mõlema korraga tegemine tähendab, et rike ei ütle teile midagi selle kohta, milline pool on vale. Asendage ülalolev dokumentatsiooni aadress lõpp-punktiga, mille jaoks klient on konfigureeritud.
Lõpetage kliendi pool, ühendades meelega lahti. Keeld peaks ikkagi tagasi lükkama liikluse, mille te meelega välistasite, sest lahendaja, mis vastab tunneliga püsti, katab ainult poole poliitikast, mis kahtluse korral keeldub.
Ühenduv klient pole veel lubatud
Serveril on oma suund, mida arvestada, ja klient, kes lõpetab kätluse, ei jõua ikkagi millenigi, mis serveril töötab, kuni server ta lubab. Avaliku kuulaja reegel laseb tunnelil ainult olemas olla; see ei lase tunneli liiklust sisse. Serveril on see kaks reeglit pluss üks kontroll, et teenus tõesti kuulab:
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'Reegli kogum peab olema võrdne vahemikuga, mille server eraldab, ja tunneli number peab vastama sellele, mille server lõi, sest teise liidese reeglit ei erista olematust reeglist. limit on meelega administratiivse pordi jaoks, sest see piirab korduvaid ühendusi, selle asemel et neid piiramatult lubada. Kuulaja kontroll eristab suletud porti äravisatud paketist, mis kliendi poolelt paistavad identsed. Nummerdatud reeglid pole samuti kogu pilt: UFW before-reeglid ja kõik käsitsi kirjutatud nftables-read vastavad varem ja võivad ikkagi tagasi lükata paketi, mida loend näiliselt lubab.