UFW laat die VPN se DNS-bediener val sodra die tonnel op is
'n Verstek-weieringsbeleid vir UFW dek ook die tonnelkoppelvlak. Sorteer die verkeer volgens rigting, laat die gepusde resolver op tun0 toe en maak dan die buitenste pad oop.
Name hou op om te resolve die oomblik wanneer die VPN koppel, terwyl 'n ping na 'n openbare adres steeds antwoord en die firewall-status niks wys wat verkeerd lyk nie. Niks het in die beleid verander nie; wat verander het, is dat 'n nuwe koppelvlak verskyn het, en die verstek-weiering dek dit van die eerste pakket af. UFW besluit volgens rigting en koppelvlak, so 'n reël wat vir die draadlose skakel geskryf is, sê niks oor verkeer wat die tonnel verlaat nie. Die herstel is 'n handvol smal reëls wat in 'n bepaalde volgorde toegepas word.
Die simptoom verskyn eers nadat die tonnel op is
'n Verstek-weieringsbeleid doen presies wat aan hom gesê is: enigiets sonder 'n passende reël word geweier, op elke koppelvlak wat bestaan. Die tonnel het nie bestaan toe die reëls geskryf is nie, so nie een van hulle kan dit pas nie, en die weiering wat altyd daar was, geld nou vir naamresolusie. Direkte verkeer na 'n letterlike adres kan steeds werk wanneer 'n breër toelating dit dek, en daarom slaag 'n ping na 'n openbare resolver terwyl 'n naamsoektog misluk. Die leemte is 'n reël vir 'n koppelvlak wat die beleid nog nooit gesien het nie.
Dit verduidelik ook waarom die fout skoon terugkeer: laat die tonnel val en name resolve weer, want die navraag keer terug na 'n koppelvlak wat wel reëls het. 'n Beleid wat net misluk terwyl die tonnel op is, is nie 'n DNS-probleem nie, en om die resolver self te stel mors hier die meeste tyd. Lees die koppelvlaklys voordat jy die resolver-konfigurasie lees.
Drie rigtings, drie verskillende reëlversamelings
'n Enkele sessie raak reëls in meer as een rigting, en 'n tonnel voeg 'n tweede koppelvlak by byna elkeen van hulle. Om die verkeer eers volgens rigting en koppelvlak te sorteer, maak die res meganies, want elke ry hieronder het sy eie reël op sy eie plek nodig. Die voorbeelde gebruik tun0 en 'n poel van 10.8.0.0/24, so vervang die name en reekse met dié uit die kliënt se eie uitset.
| 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 |
Twee rye word dikwels verwar omdat albei die tonnel noem. 'n Reël vir die resolver laat verkeer toe wat die kliënt in die tonnel stuur, terwyl 'n reël vir SSH verkeer toelaat wat die bediener daaruit ontvang; hulle woon op verskillende masjiene en misluk onafhanklik. Die ry wat die meeste vergeet word, is die tweede, want die kliënt kan die tonnel glad nie vestig voordat sy verkeer na die bediener se openbare adres toegelaat word nie. Werk van bo na onder en elke mislukking het een moontlike oorsaak.
'n Gepusde resolver het sy eie reël nodig
Of die tonnel DNS dra, hang af van wat die bediener stuur. 'n Bediener wat 'n resolver-opsie pus, installeer 'n private adres in die kliënt se konfigurasie, en daardie adres is net deur die tonnel bereikbaar. As die bediener niks pus nie, hou die kliënt die resolver wat hy al gehad het, en die reëls hieronder het niks om toe te laat nie. Kontroleer die gepusde toestand en die huidige navraagresultaat voordat jy enigiets skryf:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedDie status-uitset noem die resolver in gebruik en die skakel waaraan dit gebind is, en die roete-soektog daaronder wys watter koppelvlak 'n navraag na daardie adres sou dra. Wanneer die resolver op 'n ander skakel sit, is die probleem vroeër as die firewall en geen reël sal help nie. Wanneer albei oor die tonnel saamstem, is twee reëls nodig, want UDP dra die meeste navrae en TCP neem oor wanneer 'n antwoord afgekap word. Teken albei waardes aan, want dit is die waardes wat die reëls sal noem:
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'Maak die buitenste pad oop voor die innerlike
Die kliënt moet die bediener se openbare adres bereik voordat 'n tonnel bestaan, so die reël daarvoor sit op die fisiese skakel en moet eerste in plek wees. 'n Beleid wat die resolver toelaat maar die bediener vergeet, laat die kliënt heeltemal nie in staat om die tonnel te bou nie, en daardie simptoom kry gewoonlik die skuld op 'n kill switch. Laat dan die dienste toe wat jy eintlik deur die tonnel wou hê, een smal reël op 'n slag, eerder as om die koppelvlak in die geheel oop te maak. Die smal reëls is die rede waarom die weiering in plek kan bly.
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'Volgorde maak saak terwyl jy toets, want die eerste reël is wat die tonnel hoegenaamd laat opkom. Voeg dit by, koppel, en bevestig die tonnel is op voordat jy die dienstreël byvoeg, want om albei gelyk te doen beteken 'n mislukking sê niks oor watter helfte verkeerd is nie. Vervang die dokumentasie-adres hierbo met die eindpunt waarvoor die kliënt gekonfigureer is.
Maak die kliëntkant klaar deur doelbewus te ontkoppel. Die weiering moet steeds die verkeer weier wat jy doelbewus uitgesluit het, want 'n resolver wat antwoord terwyl die tonnel op is, dek net die helfte van 'n beleid wat in geval van twyfel weier.
'n Kliënt wat koppel, is nog nie toegelaat nie
Die bediener het sy eie rigting om te oorweeg, en 'n kliënt wat die handdruk voltooi, kan steeds niks bereik wat op die bediener loop voordat die bediener hom toelaat nie. Die openbare luisteraar-reël laat net die tonnel bestaan; dit laat nie die tonnel se verkeer in nie. Op die bediener is dit twee reëls plus een kontrole dat die diens werklik luister:
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'Die poel in die reël moet gelyk wees aan die reeks wat die bediener toeken, en die tonnelnommer moet ooreenstem met dié wat die bediener geskep het, want 'n reël vir 'n ander koppelvlak is nie van geen reël te onderskei nie. limit is doelbewus vir 'n administratiewe poort, want dit beperk herhaalde verbindings eerder as om hulle onbeperk toe te laat. Die luisteraar-kontrole onderskei 'n geslote poort van 'n weggegooide pakket, wat van die kliënt af identies lyk. Genommerde reëls is ook nie die hele prentjie nie: UFW se voor-reëls en enige handgeskrewe nftables-lyne pas vroeër en kan steeds 'n pakket weier wat die lys blykbaar toelaat.