UFW smyt de DNS-tsjinner fan 'e VPN fuort sadree't de tunnel omheech is
It standertwegeringsbelied fan UFW dekt ek it ynterface fan 'e tunnel. Sortearje it ferkear op rjochting, lit de prodde resolver op tun0 ta en iepenje dan it bûtenste paad.
Nammen hâlde op mei oplossen op it stuit dat de VPN ferbynt, wylst in ping nei in iepenbier adres noch antwurdet en de firewallstatus neat sjen lit dat ferkeard liket. Der is neat feroare yn it belied; wat feroare is, is dat in nij ynterface ferskynd is, en de standertwegering dekt dat fan it earste pakket ôf. UFW beslút op rjochting en ynterface, dus in regel skreaun foar de draadleaze ferbining seit neat oer ferkear dat de tunnel ferlit. De reparaasje is in hânfol smelle regels tapast yn in beskate folchoarder.
It symptoom ferskynt pas nei't de tunnel omheech is
In standertwegeringsbelied docht krekt wat der sein is: alles sûnder oerienkommende regel wurdt wegere, op elk ynterface dat bestiet. De tunnel bestie net doe't de regels skreaun waarden, dus gjin fan harren kin him pakke, en de wegering dy't altyd der wie jildt no foar namme-oplossing. Direkt ferkear nei in letterlik adres kin noch wurkje as in bredere tastimming it dekt, en dêrom slagget in ping nei in iepenbiere resolver wylst it sykjen fan in namme mislearret. De leechte is in regel foar in ynterface dat it belied noait sjoen hat.
Dat ferklearret ek wêrom't de flater him skjin omkeart: lit de tunnel sakje en nammen losse wer op, omdat de fraach weromkomt by in ynterface dat wol regels hat. In belied dat allinnich mislearret wylst de tunnel omheech is, is gjin DNS-probleem, en it ôfstimmen fan de resolver sels fergriemt hjir de measte tiid. Lês de ynterfacelist foardatst de resolverkonfiguraasje lêst.
Trije rjochtingen, trije ferskillende regelsets
Ien sesje rekket regels yn mear as ien rjochting, en in tunnel foeget in twadde ynterface ta oan hast elk fan harren. It earst sortearjen fan it ferkear op rjochting en ynterface makket de rest meganysk, want elke rige hjirûnder hat syn eigen regel op syn eigen plak nedich. De foarbylden brûke tun0 en in pool fan 10.8.0.0/24, dus ferfange de nammen en berikken troch dy út 'e eigen útfier fan 'e klant.
| 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 |
Twa rigen wurde faak trochinoar helle, om't beide de tunnel neame. In regel foar de resolver lit ferkear ta dat de klant de tunnel yn stjoert, wylst in regel foar SSH ferkear tastiet dat de tsjinner derút ûntfangt; se libje op ferskillende masines en mislearje ûnôfhinklik. De rige dy't it meast fergetten wurdt is de twadde, om't de klant de tunnel hielendal net bouwe kin ear't syn ferkear nei it iepenbiere adres fan 'e tsjinner tastien is. Wurkje fan boppe nei ûnderen en elke flater hat ien mooglike oarsaak.
In prodde resolver hat syn eigen regel nedich
Oft de tunnel DNS draacht hinget ôf fan wat de tsjinner stjoert. In tsjinner dy't in resolveropsje prodt, ynstallearret in privee adres yn 'e konfiguraasje fan 'e klant, en dat adres is allinnich fia de tunnel te berikken. As de tsjinner neat prodt, hâldt de klant de resolver dy't er al hie, en de regels hjirûnder hawwe neat om ta te litten. Kontrolearje de prodde tastân en it hjoeddeiske fraachresultaat foardatst eat skriuwst:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedDe statusútfier neamt de resolver yn gebrûk en de ferbining dêr't er oan bûn is, en it rûtesykjen dêrefter lit sjen hokker ynterface in fraach nei dat adres drage soe. As de resolver op in oare ferbining sit, is it probleem earder as de firewall en gjin regel sil helpe. As beide it oer de tunnel iens binne, binne twa regels nedich, om't UDP de measte fragen draacht en TCP it oernimt as in antwurd ôfkapt wurdt. Skriuw beide wearden op, want dat binne dejingen dy't de regels neame sille:
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'Iepenje it bûtenste paad foar it binnenste
De klant moat it iepenbiere adres fan 'e tsjinner berikke foar't in tunnel bestiet, dus de regel dêrfoar sit op 'e fysike ferbining en moat earst op syn plak wêze. In belied dat de resolver talit mar de tsjinner ferjit, lit de klant hielendal net by steat de tunnel te bouwen, en dat symptoom wurdt meastentiids op in kill switch skood. Lit dan de tsjinsten ta dy'tst echt troch de tunnel woe, ien smelle regel tagelyk, ynstee fan it ynterface hielendal iepen te dwaan. De smelle regels binne de reden dat de wegering op syn plak bliuwe kin.
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'Folchoarder is wichtich by it testen, om't de earste regel is wat de tunnel hielendal omheech komme lit. Foegje dy ta, ferbyn, en befêstigje dat de tunnel omheech is foardatst de tsjinstregel tafoegest, om't beide tagelyk dwaan betsjut dat in flater dy neat seit oer hokker helte ferkeard is. Ferfange it dokumintaasje-adres hjirboppe troch it einpunt dêr't de klant foar konfigurearre is.
Meitsje de klantkant ôf troch mei opsetsin te ûntbinen. De wegering moat it ferkear datst mei opsetsin útsletten hast noch hieltyd wegerje, om't in resolver dy't antwurdet wylst de tunnel omheech is mar de helte fan in belied dekt dat by twivel wegeret.
In klant dy't ferbynt is noch net talitten
De tsjinner hat syn eigen rjochting te beskôgjen, en in klant dy't de hânskudding foltôget kin noch hieltyd neat berikke dat op 'e tsjinner draait oant de tsjinner him talit. De regel foar de iepenbiere listener lit de tunnel allinnich bestean; hy lit it ferkear fan 'e tunnel net yn. Op 'e tsjinner binne dat twa regels plus ien kontrôle dat de tsjinst echt harket:
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 yn 'e regel moat gelyk wêze oan it berik dat de tsjinner tawiist, en it tunnelnûmer moat oerienkomme mei dat de tsjinner makke hat, om't in regel foar in oar ynterface net te ûnderskieden is fan gjin regel. limit is mei opset sin foar in administratyf port, om't it werhelle ferbiningen beheint ynstee fan se sûnder limyt ta te litten. De listener-kontrôle skiedt in sletten port fan in fuortsmitten pakket, dy't fan 'e klant ôf identyk lykje. Nûmere regels binne ek net it hiele byld: de before-regels fan UFW en alle mei de hân skreaune nftables-rigels komme earder oerien en kinne noch hieltyd in pakket wegerje dat de list blykber talit.