UFW numeta VPN DNS serverį, kai tik tunelis pakyla
UFW numatytojo draudimo politika apima ir tunelio sąsają. Surikiuokite srautą pagal kryptį, leiskite stumiamą resolverį tun0 sąsajoje ir tada atidarykite išorinį kelią.
Vardai nustoja spręstis tą akimirką, kai VPN prisijungia, o ping į viešą adresą vis dar atsako ir ugniasienės būsena nerodo nieko, kas atrodytų negerai. Politikoje niekas nepasikeitė; pasikeitė tai, kad atsirado nauja sąsaja, ir numatytasis draudimas ją apima nuo pirmo paketo. UFW sprendžia pagal kryptį ir sąsają, todėl belaidžio ryšio taisyklei parašyta taisyklė nieko nesako apie srautą, išeinantį iš tunelio. Taisymas yra sauja siaurų taisyklių, taikomų tam tikra tvarka.
Simptomas pasireiškia tik po to, kai tunelis pakyla
Numatytojo draudimo politika daro būtent tai, kas jai buvo pasakyta: viskas be atitinkančios taisyklės atmetama, kiekvienoje egzistuojančioje sąsajoje. Tunelio nebuvo, kai buvo rašomos taisyklės, todėl nė viena jų negali jo pagauti, o draudimas, kuris visada buvo, dabar taikomas vardų sprendimui. Tiesioginis srautas į pažodinį adresą vis dar gali veikti, kai jį apima platesnis leidimas, todėl ping į viešą resolverį pavyksta, o vardo paieška nepavyksta. Spraga yra taisyklė sąsajai, kurios politika niekada nematė.
Tai taip pat paaiškina, kodėl gedimas švariai apsiverčia: nuimkite tunelį ir vardai vėl sprendžiami, nes užklausa grįžta į sąsają, kuri turi taisyklių. Politika, kuri nepavyksta tik tuneliui esant pakeltam, nėra DNS problema, o paties resolverio derinimas čia eikvoja daugiausia laiko. Perskaitykite sąsajų sąrašą prieš skaitydami resolverio konfigūraciją.
Trys kryptys, trys skirtingi taisyklių rinkiniai
Viena sesija paliečia taisykles daugiau nei viena kryptimi, o tunelis beveik kiekvienai jų prideda antrą sąsają. Pirmiausia surikiavus srautą pagal kryptį ir sąsają, likusi dalis tampa mechaninė, nes kiekvienai žemiau esančiai eilutei reikia savo taisyklės savo vietoje. Pavyzdžiuose naudojamas tun0 ir 10.8.0.0/24 telkinys, todėl pakeiskite pavadinimus ir diapazonus tais, kurie yra paties kliento išvestyje.
| 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 |
Dvi eilutės dažnai painiojamos, nes abi mini tunelį. Resolverio taisyklė leidžia srautą, kurį klientas siunčia į tunelį, o SSH taisyklė leidžia srautą, kurį serveris iš ten gauna; jos gyvena skirtingose mašinose ir nepavyksta nepriklausomai. Dažniausiai pamirštama eilutė yra antroji, nes klientas apskritai negali sukurti tunelio, kol jo srautas į viešą serverio adresą neleidžiamas. Dirbkite iš viršaus į apačią ir kiekvienas gedimas turi vieną galimą priežastį.
Stumiamas resolveris turi savo taisyklę
Ar tunelis neša DNS, priklauso nuo to, ką siunčia serveris. Serveris, kuris stumia resolverio parinktį, įrašo privatų adresą į kliento konfigūraciją, ir tas adresas maršrutizuojamas tik per tunelį. Jei serveris nieko nestumia, klientas išlaiko turimą resolverį, o žemiau esančios taisyklės neturi ko leisti. Prieš ką nors rašydami patikrinkite stumiamą būseną ir dabartinį užklausos rezultatą:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedBūsenos išvestis nurodo naudojamą resolverį ir ryšį, prie kurio jis pririštas, o už jo esanti maršruto paieška parodo, kuri sąsaja perneštų užklausą į tą adresą. Kai resolveris yra kitame ryšyje, problema yra anksčiau nei ugniasienė ir jokia taisyklė nepadės. Kai abu sutaria dėl tunelio, reikia dviejų taisyklių, nes daugumą užklausų neša UDP, o TCP perima, kai atsakymas nukerpamas. Užsirašykite abi reikšmes, nes būtent jas įvardins taisyklės:
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'Atidarykite išorinį kelią prieš vidinį
Klientas turi pasiekti viešą serverio adresą prieš atsirandant tuneliui, todėl taisyklė tam yra fiziniame ryšyje ir turi būti savo vietoje pirmoji. Politika, kuri leidžia resolverį, bet pamiršta serverį, palieka klientą visiškai nepajėgų sukurti tunelį, ir šis simptomas paprastai priskiriamas kill switch. Tada leiskite paslaugas, kurių iš tikrųjų norėjote per tunelį, po vieną siaurą taisyklę, o ne atverkite sąsają visiškai. Siauros taisyklės yra priežastis, kodėl draudimas gali likti vietoje.
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'Tvarka svarbi testuojant, nes pirmoji taisyklė yra tai, kas apskritai leidžia tuneliui pakilti. Pridėkite ją, prisijunkite ir patvirtinkite, kad tunelis pakeltas, prieš pridėdami paslaugos taisyklę, nes abu iš karto reiškia, kad gedimas nieko nepasako apie tai, kuri pusė neteisinga. Pakeiskite dokumentacijos adresą aukščiau į galinį tašką, kuriam sukonfigūruotas klientas.
Užbaikite kliento pusę sąmoningai atsijungdami. Draudimas turėtų vis dar atmesti srautą, kurį sąmoningai išskyrėte, nes resolveris, kuris atsako tuneliui esant pakeltam, apima tik pusę politikos, kuri abejojant draudžia.
Prisijungęs klientas dar nepriimtas
Serveris turi savo kryptį, į kurią reikia atsižvelgti, o klientas, baigęs rankos paspaudimą, vis tiek nepasiekia nieko, kas veikia serveryje, kol serveris jo nepriima. Viešo klausytojo taisyklė tik leidžia tuneliui egzistuoti; ji neįleidžia tunelio srauto. Serveryje tai dvi taisyklės ir vienas patikrinimas, ar paslauga tikrai klausosi:
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'Taisyklės telkinys turi būti lygus diapazonui, kurį serveris skiria, o tunelio numeris turi atitikti serverio sukurtą, nes kitos sąsajos taisyklė nesiskiria nuo jokios taisyklės. limit yra sąmoningai administraciniam prievadui, nes jis riboja pasikartojančius ryšius, o ne priima juos be apribojimų. Klausytojo patikrinimas atskiria uždarą prievadą nuo atmesto paketo, kurie iš kliento pusės atrodo vienodai. Numeruotos taisyklės taip pat nėra visas vaizdas: UFW before taisyklės ir bet kurios ranka rašytos nftables eilutės atitinka anksčiau ir vis dar gali atmesti paketą, kurį sąrašas tarsi leidžia.