Ĉu la haltŝaltilo de UFW blokas vian VPN? Permesu la kunulon

Vi sekvis la kontrolan liston: malpermesi eliron, permesi la tunelon, ŝalti ufw. Poste la kliento atendas ĉe la manpremo kaj neniam konektiĝas, aŭ ĝi konektiĝas kaj neniu paĝo ŝargiĝas. Ambaŭ malsukcesoj venas el la sama manko. Mankas la regulo, kiu lasas la tunelon ekzisti, ĉar la tunelo ne estas interfaco, el kiu viaj pakaĵoj foriras.

Kial permeso sur tun0 komence kongruas kun nenio

tun0 estas kreata de la kliento post kiam sesio ekzistas. La datagramoj, kiuj konstruas tiun sesion, estas ordinaraj UDP-pakaĵoj adresitaj al la provizanto sur pordo 1194, kaj ili foriras tra wlan0 aŭ eth0 kun la fizika fontadreso. allow out on tun0 kongruas nur kun trafiko, kies elira interfaco estas tun0, do dum la manpremo ĝi kongruas kun nenio.

Metu default deny outgoing supre kaj la eksteraj pakaĵoj estas forĵetataj antaŭ ol la interfaco eĉ aperas. La kliento reprovas, tempolimas kaj raportas TLS- aŭ manpreman fiaskon, kio sendas homojn serĉi tra atestiloj kaj MTU dum la fajroŝirmilo kviete manĝas la konekton. La regulo, kiu devis enteni vian trafikon, malhelpas, ke tiu trafiko estu entenata.

La refleksa riparo igas la likon daŭra. sudo ufw allow out on wlan0, aŭ reŝalti la normon al permeso, levas la tunelon kaj lasas la maŝinon sen haltŝaltilo: la sekvan fojon, kiam la tunelo falas, ĉio rekomenciĝas tra la fizika adaptilo. Mi perdis posttagmezon ĝuste pro tiu paro da ŝanĝoj antaŭ ol mi klarigis, kiun pakaĵon mi fakte filtris.

Kion bezonas la du aroj da pakaĵoj

Via trafiko transiras la fajroŝirmilon dufoje, en du formoj. La interna pakaĵo iras de la tunela adreso eksteren tra tun0. La ekstera pakaĵo iras de la fizika adreso al la kunulo, kaj ĝi estas la sola afero videbla sur la drato. Unu regulo por formo:

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'

Anstataŭigu la adreson kaj pordon per tiuj de via propra profilo. Kunuloj de WireGuard kutime respondas sur 51820/udp; profiloj de OpenVPN, kiuj iras tra TCP 443, bezonas tiun pordon anstataŭe. La detaloj malsamas, la formo ne: ambaŭ reguloj estas mallarĝaj, kaj kune ili difinas la solajn celojn, kiujn la maŝino povas atingi dum la tunelo estas malsupre.

Ordo estas la dua mito. Kun kruda iptables vi legas la ĉenon de supre malsupren kaj pripensas, kiu regulo venkas. ufw ne estas maldika volvaĵo ĉirkaŭ la listo, kiun vi tajpis; ĝi kompilas viajn regulojn en siajn proprajn ĉenojn kaj elektas la enmetajn punktojn. ufw status presas ilin en la ordo de ufw, ne via. Kiam regulo aspektas ignorata, komparu ufw show added kun la kompilita aro el iptables -S | grep ufw antaŭ ol reskribi ion ajn.

La escepto devas resti unu adreson larĝa

Regulo por kunulo estas ĝusta nur dum ĝi nomas la adreson, kiun la kliento vokas. Provizantoj rotacias finpunktojn, kaj profilo, kiu solvas gastigantan nomon, sekvos DNS-ŝanĝon al nova adreso dum la regulo plu montras al la malnova. Kiam tunelo, kiu funkciis dum monatoj, ĉesas leviĝi, komparu la adreson en la regulo kun tiu, kiun la kliento serĉas, antaŭ ol larĝigi ion ajn.

Larĝigo al tuta subreto, aŭ al ĉiu celo sur pordo 1194, retransformas la politikon en fajroŝirmilon kun truo. La escepto estas la haltŝaltilo; post kiam ĝi estas larĝa, nenio restas por haltigi. Tenu ĝin sur unu adreso kaj lasu komenton nomantan la profilon kaj provizanton, al kiuj ĝi apartenas, ĉar post ses monatoj la adreso aspektos arbitra.

Nomosolvado meritas propran linion. La serĉo okazas antaŭ ol la tunelo ekzistas, tra la fizika interfaco, do severa politiko de malpermeso de eliro povas lasi la klienton nekapabla trovi sian propran servilon. Permesu pordon 53 al la adreso de via solvilo, aŭ solvu unufoje kaj fiksu la adreson en la profilo. Permesi DNS sur ĉiu interfaco estas decido, ne normo.

Konstruu la politikon antaŭ ol la tunelo necesiĝos

ufw enable aplikas la tutan politikon samtempe kaj reŝargas siajn ĉenojn, kaj ŝanĝi norman politikon sur funkcianta fajroŝirmilo ankaŭ reŝargas ilin. La manlibro de ufw avertas, ke tio povas faligi ekzistantajn konektojn kiel SSH. Do la komandoj iras en ĉi tiu ordo, kun la SSH-regulo antaŭ la ŝalto kaj malfermita konsola sesio:

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 estas intence lasita ekster tiu bloko. Ĝi forigas ĉiun regulon kaj malŝaltas la fajroŝirmilon, kaj sur fora gastiganto la sekva ŝalto estas tio, kio faligas vian sesion. Se vi tamen restarigas, aldonu la SSH-regulon kaj konfirmu duan vojon reen tra konzolo antaŭ ol daŭrigi.

La sinsekvo ne estas kosmetika. Reguloj aldonitaj dum ufw funkcias ne forfluigas ion, sed en la momento, kiam vi renversas norman politikon, la ĉenoj reŝargiĝas, kaj sesio, kiun la malnova politiko permesis, foriras kun ili. Faru la normojn, la permesojn kaj la ŝalton en unu paŝo, dum vi ankoraŭ havas vojon enen, kiu ne dependas de la maŝino.

Testu la blokitan staton kaj konservu la malfaron

Nespertita haltŝaltilo estas konjekto. Intence malkonektu la klienton kaj provu ŝargi paĝon: ĝi devas malsukcesi. Rekonektiĝu kaj ĝi devas resaniĝi sen tuŝi regulon. sudo ufw status verbose konfirmas la normojn kaj la protokolan staton, kaj ufw status numbered montras, kiun testan regulon forigi, kiam ĝi pluvivos sian celon.

Tenu la inversan skripton apud la antaŭa. Maŝino kun malpermeso de eliro kaj mortinta tunelo ne povas elŝuti sian propran riparon, do la malfaro devas kuŝi sur la disko kaj esti legebla el konzolo:

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

Rulu ĝin, kiam la tunelo jam estas malsupre kaj la reguloj devas foriri, ne kiel rutinan paŝon. Antaŭ ol vi fermos la terminalon, kvar aferoj devas validi: la kunula regulo nomas ekzakte unu adreson, DNS havas nomitan escepton, la ŝalto venis post la permesoj, kaj tiri la tunelon mortigas ordinarajn trafikon sen mortigi la klienton por ĉiam.