UFW nomet VPN DNS serveri, tiklīdz tunelis ir uzcelts

Vārdi pārstāj risināties tajā brīdī, kad VPN pievienojas, kamēr ping uz publisku adresi joprojām atbild un ugunsmūra statuss neuzrāda neko, kas izskatītos nepareizi. Politikā nekas nav mainījies; mainījies ir tas, ka parādījās jauna saskarne, un noklusējuma aizliegums to aptver jau no pirmās paketes. UFW izlemj pēc virziena un saskarnes, tāpēc bezvadu saitei rakstīts noteikums neko nepasaka par trafiku, kas iziet no tuneļa. Labojums ir sauja šauru noteikumu, kas piemēroti noteiktā secībā.

Simptoms parādās tikai pēc tam, kad tunelis ir uzcelts

Noklusējuma aizlieguma politika dara tieši to, kas tai teikts: viss bez atbilstoša noteikuma tiek noraidīts, katrā eksistējošā saskarnē. Tunelis neeksistēja, kad tika rakstīti noteikumi, tāpēc neviens no tiem nevar to uztvert, un aizliegums, kas vienmēr bija, tagad attiecas uz vārdu risināšanu. Tiešs trafiks uz burtisku adresi joprojām var darboties, ja to aptver plašāka atļauja, un tāpēc ping uz publisku resolveri izdodas, kamēr vārda meklēšana neizdodas. Plaisa ir noteikums saskarnei, kuru politika nekad nav redzējusi.

Tas arī izskaidro, kāpēc kļūme tīri apgriežas: noņem tuneli, un vārdi atkal risinās, jo vaicājums atgriežas saskarnē, kurai ir noteikumi. Politika, kas neizdodas tikai tad, kad tunelis ir uzcelts, nav DNS problēma, un paša resolvera regulēšana šeit izšķiež visvairāk laika. Izlasiet saskarņu sarakstu pirms resolvera konfigurācijas lasīšanas.

Trīs virzieni, trīs dažādi noteikumu kopumi

Viena sesija skar noteikumus vairāk nekā vienā virzienā, un tunelis gandrīz katrai no tām pievieno otru saskarni. Vispirms sakārtojot trafiku pēc virziena un saskarnes, pārējais kļūst mehānisks, jo katrai rindai zemāk vajag savu noteikumu savā vietā. Piemēri izmanto tun0 un 10.8.0.0/24 kopu, tāpēc aizstājiet nosaukumus un diapazonus ar tiem, kas ir paša klienta izvadē.

Divas rindas bieži jauc, jo abas piemin tuneli. Resolvera noteikums atļauj trafiku, ko klients sūta tunelī, bet SSH noteikums atļauj trafiku, ko serveris no tā saņem; tie dzīvo dažādās mašīnās un neizdodas neatkarīgi. Visbiežāk aizmirstā rinda ir otrā, jo klients vispār nevar izveidot tuneli, kamēr tā trafiks uz servera publisko adresi nav atļauts. Strādājiet no augšas uz leju, un katrai kļūmei ir viens iespējams cēlonis.

Uzspiests resolveris prasa savu noteikumu

Vai tunelis nes DNS, ir atkarīgs no tā, ko sūta serveris. Serveris, kas uzspiež resolvera opciju, klienta konfigurācijā ievieto privātu adresi, un šī adrese ir maršrutējama tikai caur tuneli. Ja serveris neko neuzspiež, klients patur jau esošo resolveri, un noteikumiem zemāk nav ko atļaut. Pirms kaut ko rakstīt, pārbaudiet uzspiesto stāvokli un pašreizējo vaicājuma rezultātu:

dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numbered

Statusa izvade nosauc izmantoto resolveri un saiti, pie kuras tas piesaistīts, un aiz tās esošā maršruta meklēšana parāda, kura saskarne pārvadās vaicājumu uz šo adresi. Kad resolveris atrodas citā saitē, problēma ir agrāk nekā ugunsmūris, un neviens noteikums nepalīdzēs. Kad abi vienojas par tuneli, vajadzīgi divi noteikumi, jo lielāko daļu vaicājumu pārvadā UDP, un TCP pārņem, kad atbilde tiek apgriezta. Pierakstiet abas vērtības, jo tieši tās nosauks noteikumi:

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'

Atveriet ārējo ceļu pirms iekšējā

Klientam jāsasniedz servera publiskā adrese pirms tuneļa pastāvēšanas, tāpēc noteikums tam atrodas fiziskajā saitē un tam jābūt vietā pirmajam. Politika, kas atļauj resolveri, bet aizmirst serveri, atstāj klientu pilnīgi nespējīgu izveidot tuneli, un šis simptoms parasti tiek piedēvēts kill switch. Pēc tam atļaujiet pakalpojumus, kurus patiešām gribējāt caur tuneli, pa vienam šauram noteikumam, nevis atveriet saskarni pilnībā. Šaurie noteikumi ir iemesls, kāpēc aizliegums var palikt savā vietā.

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'

Secība ir svarīga testēšanas laikā, jo pirmais noteikums ir tas, kas vispār ļauj tunelim pacelties. Pievienojiet to, pieslēdzieties un pārliecinieties, ka tunelis ir uzcelts, pirms pievienojat pakalpojuma noteikumu, jo abus uzreiz darīt nozīmē, ka kļūme neko nepasaka par to, kura puse ir nepareiza. Aizstājiet dokumentācijas adresi augstāk ar galapunktu, kuram klients ir konfigurēts.

Pabeidziet klienta pusi, apzināti atvienojoties. Aizliegumam joprojām jānoraida trafiks, ko apzināti izslēdzāt, jo resolveris, kas atbild, kamēr tunelis ir uzcelts, aptver tikai pusi no politikas, kas šaubu gadījumā aizliedz.

Pieslēdzies klients vēl nav uzņemts

Serverim ir savs virziens, kas jāņem vērā, un klients, kas pabeidz rokasspiedienu, joprojām nevar sasniegt neko, kas darbojas serverī, kamēr serveris to neuzņem. Publiskā klausītāja noteikums tikai ļauj tunelim pastāvēt; tas neielaiž tuneļa trafiku. Serverī tie ir divi noteikumi un viena pārbaude, vai pakalpojums tiešām klausās:

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'

Noteikuma kopa ir jābūt vienādai ar diapazonu, ko serveris piešķir, un tuneļa numuram jāatbilst servera izveidotajam, jo noteikums citai saskarnei nav atšķirams no noteikuma neesamības. limit ir apzināti administratīvajam portam, jo tas ierobežo atkārtotus savienojumus, nevis uzņem tos bez ierobežojuma. Klausītāja pārbaude atdala slēgtu portu no izmestas paketes, kas no klienta puses izskatās vienādi. Numurētie noteikumi arī nav viss attēls: UFW before noteikumi un jebkura ar roku rakstīta nftables rinda atbilst agrāk un joprojām var noraidīt paketi, kuru saraksts šķietami atļauj.