UFW avārijas slēdzis bloķē jūsu VPN? Atļaujiet partnerim

Jūs izpildījāt kontrolsarakstu: aizliegt izejošo, atļaut tuneli, ieslēgt ufw. Tad klients gaida rokasspiedienā un nekad nepievienojas, vai arī pievienojas un neviena lapa neielādējas. Abas neveiksmes nāk no vienas un tās pašas nepilnības. Trūkst noteikuma, kas ļauj tunelim pastāvēt, jo tunelis nav saskarne, pa kuru iziet jūsu paketes.

Kāpēc atļauja uz tun0 sākumā neatbilst nekam

tun0 izveido klients pēc tam, kad sesija pastāv. Datagrammas, kas veido šo sesiju, ir parastas UDP paketes, kas adresētas pakalpojumu sniedzējam 1194 portā, un tās iziet caur wlan0 vai eth0 ar fizisko avota adresi. allow out on tun0 atbilst tikai tam trafikam, kura izejošā saskarne ir tun0, tāpēc rokasspiediena laikā tas neatbilst nekam.

Uzlieciet default deny outgoing un ārējās paketes tiek izmestas, pirms saskarne vispār parādās. Klients mēģina vēlreiz, nokļūst taimautā un ziņo par TLS vai rokasspiediena kļūdu, kas liek cilvēkiem meklēt sertifikātos un MTU, kamēr ugunsmūris klusi ēd savienojumu. Noteikums, kam bija jāsavaldzina jūsu trafiks, traucē šim trafikam tikt savaldzītam.

Refleksu labojums padara noplūdi pastāvīgu. sudo ufw allow out on wlan0, vai atgriežot noklusējumu uz atļaut, paceļ tuneli un atstāj mašīnu bez avārijas slēdža: nākamreiz, kad tunelis krīt, viss atsākas pa fizisko adapteri. Es pazaudēju pēcpusdienu tieši šim pārim izmaiņu, pirms izdomāju, kuru paketi es patiešām filtrēju.

Kas vajadzīgs abiem pakešu kopām

Jūsu trafiks šķērso ugunsmūri divreiz, divās formās. Iekšējā pakete iet no tuneļa adreses uz āru caur tun0. Ārējā pakete iet no fiziskās adreses pie partnera, un tas ir vienīgais, kas redzams uz vada. Viens noteikums katrai formai:

sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'

Aizstājiet adresi un portu ar tiem no sava profila. WireGuard partneri parasti atbild uz 51820/udp; OpenVPN profiliem, kas iet pa TCP 443, tā vietā vajadzīgs šis ports. Detaļas atšķiras, forma ne: abi noteikumi ir šauri, un kopā tie nosaka vienīgos galamērķus, kurus mašīna var sasniegt, kamēr tunelis ir izslēgts.

Kārtība ir otrais mīts. Ar neapstrādātu iptables jūs lasāt ķēdi no augšas uz leju un spriežat, kurš noteikums uzvar. ufw nav plāns ievadītā saraksta apvalks; tas kompilē jūsu noteikumus savās ķēdēs un izvēlas ievietošanas punktus. ufw status izdrukā tos ufw kārtībā, nevis jūsu. Kad noteikums izskatās ignorēts, salīdziniet ufw show added ar kompilēto kopu no iptables -S | grep ufw pirms kaut ko pārrakstīt.

Izņēmumam jāpaliek viena adrese platumā

Partnera noteikums ir pareizs tikai tik ilgi, kamēr tas nosauc adresi, uz kuru klients zvana. Sniedzēji rotē galapunktus, un profils, kas atrisina resursdatora nosaukumu, sekos DNS izmaiņām uz jaunu adresi, kamēr noteikums joprojām rādīs uz veco. Kad tunelis, kas darbojās mēnešus, pārstāj celties, pirms kaut ko paplašināt salīdziniet noteikuma adresi ar to, ko meklē klients.

Paplašināšana uz visu apakštīklu vai uz katru galamērķi 1194 portā pārvērš politiku atkal ugunsmūrī ar caurumu. Izņēmums ir avārijas slēdzis; kad tas ir plašs, vairs nav ko izslēgt. Turiet to vienā adresē un atstājiet komentāru, kas nosauc profilu un sniedzēju, kam tas pieder, jo pēc sešiem mēnešiem adrese izskatīsies patvaļīga.

Nosaukumu izšķiršana pelna savu rindu. Meklēšana notiek pirms tuneļa pastāvēšanas, pa fizisko saskarni, tāpēc stingra izejošā aizlieguma politika var atstāt klientu nespējīgu atrast savu serveri. Atļaujiet 53 portu uz sava atrisinātāja adresi, vai atrisiniet vienreiz un piespraudiet adresi profilā. Atļaut DNS visās saskarnēs ir lēmums, nevis noklusējums.

Veidojiet politiku pirms tuneļa nepieciešamības

ufw enable piemēro visu politiku uzreiz un pārlādē savas ķēdes, un noklusējuma politikas maiņa darbojošā ugunsmūrī tās arī pārlādē. ufw rokasgrāmata brīdina, ka tas var nomest esošos savienojumus, piemēram, SSH. Tāpēc komandas iet šādā kārtībā, ar SSH noteikumu pirms ieslēgšanas un atvērtu konsoles sesiju:

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

ufw reset apzināti atstāts ārpus šī bloka. Tas dzēš katru noteikumu un atspējo ugunsmūri, un attālinātā resursdatorā tieši nākamā ieslēgšana nomet jūsu sesiju. Ja tomēr atiestatāt, pievienojiet SSH noteikumu un pirms turpināšanas apstipriniet otru ceļu atpakaļ caur konsoli.

Secība nav kosmētiska. Noteikumi, kas pievienoti, kamēr ufw darbojas, neko neizskalo, bet brīdī, kad apgriežat noklusējuma politiku, ķēdes tiek pārlādētas, un sesija, ko pieļāva vecā politika, aiziet kopā ar tām. Veiciet noklusējumus, atļaujas un ieslēgšanu vienā piegājienā, kamēr jums vēl ir ieeja, kas nav atkarīga no mašīnas.

Pārbaudiet bloķēto stāvokli un saglabājiet atcelšanu

Nepārbaudīts avārijas slēdzis ir minējums. Apzināti atvienojiet klientu un mēģiniet ielādēt lapu: tam jāneizdodas. Pievienojieties vēlreiz, un tam jāatjaunojas, neaiztiekot nevienu noteikumu. sudo ufw status verbose apstiprina noklusējumus un reģistrēšanas stāvokli, un ufw status numbered parāda, kuru testa noteikumu dzēst, kad tas pārdzīvo savu mērķi.

Turiet apgriezto skriptu blakus tiešajam. Mašīna ar izejošā aizliegumu un mirušu tuneli nevar lejupielādēt savu labojumu, tāpēc atcelšanai jābūt diskā un lasīšanai no konsoles:

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

Palaidiet to, kad tunelis jau ir izslēgts un noteikumi jānoņem, nevis kā parastu soli. Pirms aizverat termināli, jāizpildās četrām lietām: partnera noteikums nosauc tieši vienu adresi, DNS ir nosaukts izņēmums, ieslēgšana notika pēc atļaujām, un tuneļa izvilkšana nogalina parasto trafiku, bet nogalina klientu uz visiem laikiem.