UFW verwerft den DNS-Server vun der VPN, soubal den Tunnel steet
D'Standard-Refusspolitik vum UFW deckt och d'Interface vum Tunnel. Sortéier den Trafik no Richtung, erlaab den agedroe Resolver op tun0, an da maach de baussenzege Wee op.
Nimm hale beim Opléisen op in dem Moment, wou d'VPN sech verbënnt, während e Ping op eng ëffentlech Adress nach äntwert an de Firewall-Statu näischt weist, wat falsch ausgesäit. An der Politik huet sech näischt geännert; wat sech geännert huet, ass datt eng nei Interface opgetrueden ass, an de Standard-Refus deckt se vum éischte Pak u of. UFW decidéiert no Richtung an Interface, also seet eng Regel, déi fir d'drahtlos Verbindung geschriwwe gouf, näischt iwwer den Trafik, deen den Tunnel verléisst. D'Reparatur ass eng Handvoll schmuel Regelen, an enger bestëmmter Reihenfolge ugewannt.
D'Symptom erschéngt eréischt, nodeems den Tunnel steet
Eng Standard-Refusspolitik mécht genee dat, wat hir gesot gouf: alles ouni passend Regel gëtt verworf, op all Interface, déi existéiert. Den Tunnel huet net existéiert, wéi d'Regelen geschriwwe goufen, also kann keng vun hinnen en erwëschen, an de Refus, deen ëmmer do war, gëllt elo fir d'Nimm-Opléisen. Direkten Trafik op eng wuertwiertlech Adress kann nach funktionéieren, wann eng méi breet Erlaabnes en deckt, an dofir geet e Ping op en ëffentlechen Resolver duer, während d'Numm-Siche verseeft. D'Lück ass eng Regel fir eng Interface, déi d'Politik ni gesinn huet.
Dat erklärt och, firwat de Feeler sech propper ëmdréit: lue es den Tunnel erof an d'Nimm léisen erëm op, well d'Ufro op eng Interface zréckkënnt, déi Regelen huet. Eng Politik, déi nëmmen feelt, wann den Tunnel steet, ass kee DNS-Problem, an de Resolver selwer ze justéieren verschwënnt hei déi meescht Zäit. Lies d'Interface-Lëscht, ier s de d'Resolvers-Konfiguratioun liest.
Dräi Richtungen, dräi verschidde Regelsätz
Eng eenzeg Sessioun beréiert Regelen a méi wéi enger Richtung, an en Tunnel setzt bal all vun hinnen eng zweet Interface derbäi. Wann s de den Trafik fir d'éischt no Richtung an Interface sortéiers, gëtt de Rescht mechanesch, well all Zeil drënner hir eege Regel op hirem eegene Plaz brauch. D'Beispiller benotze tun0 an e Pool vun 10.8.0.0/24, also ersetz d'Nimm an d'Beräicher duerch déi aus der Ausgab vum Client selwer.
| 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 |
Zwou Zeile ginn dacks verwiesselt, well béid den Tunnel ernimmen. Eng Regel fir de Resolver erlaabt den Trafik, deen de Client an den Tunnel schéckt, während eng Regel fir SSH den Trafik erlaabt, deen de Server vun do kritt; si liewen op verschiddene Maschinnen a feelen onofhängeg. D'Zeil, déi am meeschte vergiess gëtt, ass déi zweet, well de Client den Tunnel guer net kann opbauen, bis säin Trafik op d'ëffentlech Adress vum Server erlaabt ass. Schaff vu uewen no ënnen an all Feeler huet eng eenzeg méiglech Ursaach.
En agedroe Resolver brauch seng eege Regel
Ob den Tunnel DNS dréit, hänkt dovun of, wat de Server schéckt. E Server, deen eng Resolver-Optioun dréckt, installéiert eng privat Adress an der Konfiguratioun vum Client, an déi Adress ass nëmmen iwwer den Tunnel routbar. Wann de Server näischt dréckt, behält de Client de Resolver, deen en schonn hat, an d'Regele drënner hunn näischt z'erlaben. Kontrolléier den agedroe Status an d'aktuellt Resultat vun der Ufro, ier s eppes schreifs:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedD'Ausgab vum Status nennt de Resolver, deen am Gebrauch ass, an d'Verbindung, un déi en gebonnen ass, an d'Rutesich dobannen weist, wéi eng Interface eng Ufro op déi Adress droe géif. Wann de Resolver op enger anerer Verbindung sëtzt, ass de Problem méi fréi wéi de Firewall an eng Regel hëlleft net. Wann béid sech iwwer den Tunnel eens sinn, si zwou Regele noutwenneg, well UDP déi meescht Ufroen dréit an TCP iwwerhëlt, wann eng Äntwert ofgeschnidden gëtt. Notéier béid Wäerter, well dat sinn déi, déi d'Regele nenne wäerten:
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'Maach de baussenzege Wee virum bannenzege op
De Client muss déi ëffentlech Adress vum Server erreechen, ier en Tunnel existéiert, also sëtzt d'Regel dofir op der physescher Verbindung an muss als éischt op hirem Plaz sinn. Eng Politik, déi de Resolver erlaabt awer de Server vergësst, léisst de Client ganz onfäeg den Tunnel ze bauen, an dat Symptom gëtt meeschtens engem Kill Switch zougeschriwwen. Duerno erlaab d'Servicer, déi s de wierklech duerch den Tunnel wollts, eng schmuel Regel nom aneren, amplaz d'Interface am Ganzen opzemaachen. Déi schmuel Reegele sinn de Grond, firwat de Refus ka bleiwen, wou en ass.
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'D'Reihenfolge zielt beim Testen, well déi éischt Regel ass, wat den Tunnel iwwerhaapt eropkënnt. Setz se derbäi, verbann, a bestäteg, datt den Tunnel steet, ier s de d'Serviceregel derbäisetz, well béides gläichzäiteg ze maachen heescht, datt e Feeler dir näischt seet, wéi eng Halschent falsch ass. Ersetz d'Dokumentatiounsadress uewen duerch den Endpunkt, fir deen de Client konfiguréiert ass.
Fäerdeg d'Client-Säit of, andeems s de bewosst trenns. De Refus sollt den Trafik, deen s de bewosst ausgeschloss hues, nach ëmmer verwerfen, well en Resolver, deen äntwert, während den Tunnel steet, nëmmen d'Halschent vun enger Politik deckt, déi am Zweifel verwerft.
E Client, deen sech verbënnt, ass nach net zougelooss
De Server huet seng eege Richtung ze berücksichtegen, an e Client, deen den Handshake fäerdeg mécht, erreecht nach ëmmer näischt, wat um Server leeft, bis de Server en zouloosst. D'Regel vum ëffentlechen Listener erlaabt nëmmen, datt den Tunnel existéiert; si léisst den Trafik vum Tunnel net erbäi. Um Server sinn dat zwou Regele plus eng Kontroll, datt de Service wierklech lauschtert:
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'De Pool an der Regel muss dem Beräich gläich sinn, deen de Server verdeelt, an d'Tunnelnummer muss déi entspriechen, déi de Server ugeluecht huet, well eng Regel fir eng aner Interface net vun enger Regel z'ënnerscheeden ass. limit ass bewosst fir en administrative Port, well et widderholl Verbindungen drosselt, amplaz se onbegrenzt zouzeloossen. D'Kontroll vum Listener trennt en zouenen Port vun engem verworfene Pak, déi vum Client aus identesch ausgesinn. Nummeréiert Reegele sinn och net d'ganzt Bild: dem UFW seng before-Reegele an all handgeschriwwe nftables-Zeile passen méi fréi a kënnen nach e Pak verwerfen, vun deem d'Lëscht schéngt, datt se et erlaabt.