ufw allow 443 faris nenion por servo malantaŭ la VPN

Ping sukcesas de VPN-kliento, la TCP-servo tempas, kaj ufw allow 443/tcp ŝanĝas tute nenion. Kiam la aplikaĵo ruliĝas sur gastigo malantaŭ la pordego anstataŭ sur la pordego mem, tiu permeso estis skribita por la malĝusta trafika vojo. La paketo ne estas adresita al la fajroŝirmo kaj ne estas liverita al loka procezo, do la envenaj reguloj neniam vidas ĝin. La riparo estas vojo-regulo celanta la plusendatan fluon, kaj la pruvo por ĝi jam troviĝas en la protokolo.

Decidu, ĉu la celo estas loka aŭ plusendata

Legu la paketon kiel la kerno vidas ĝin. Trafiko liverita al servo sur la pordego estas loka enveno. Trafiko, kiun la pordego plusendas al alia gastigo, estas plusendata, kaj UFW tenas apartajn regulajn arojn por la du vojoj. La distingon decidas la cela adreso kaj la voja serĉado, ne la interfaco per kiu la paketo alvenis.

Protokola linio montranta la saman interfacon en ambaŭ kampoj IN kaj OUT ankoraŭ povas priskribi enkursigitan paketon, ĉar tunelo, kiu portas klientojn en kaj el unu aparato, aspektas ĝuste tiel. La cela adreso solvas la demandon pli rapide ol la interfacaj nomoj. Vidi la saman nomon duoble ne pruvas lokan liveron, kaj elpensi tunelan interfacon, kiun la deplojo neniam kreis, ankaŭ ne helpas.

Legu la blokon antaŭ ol aldoni ajnan regulon

Ripetu unu rajtigitan konektan provon kaj registru ĝian fonton, celon, protokolon kaj celan pordon kiel la pordego registris ilin. Komparu tiujn kvar valorojn kun la protokola ero kaj kun la fakta loko de la servo. Antaŭa sukcesa ping pruvas nur, ke ĝia propra interŝanĝo estis permesita, kaj fajroŝirmo povas trakti TCP SYN al aplikaĵo tute alie.

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

La unua komando redonas la verdikton kun ĝiaj kampoj, kaj la dua montras, kio jam estas ŝargita kaj en kiu ordo. Legu ambaŭ antaŭ ol redakti ion ajn, ĉar antaŭa malpermeso super via regulo klarigas la saman simptomon sen iu ajn mankanta regulo.

Skribu la plej mallarĝan vojo-regulon kiu taŭgas

En ĉi tiu ekzemplo klientoj alvenas sur tun0 de 172.20.8.0/24, la servo aŭskultas sur 10.30.0.15 ĉe pordo 8443, kaj la pordego eliras tra ens5. Tiuj valoroj estis elektitaj por aspekti tute ne kiel nuba VPC-defaŭlto de 10.0.0.0/16 aŭ hejma reto de 192.168.0.0/16, kaj 8443 tenas la ekzemplon for de la propra 443-aŭskultanto de la pordego.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

La provrulo presas la regulan aron kiu rezultus, kio estas la plej malmultekosta maniero vidi, ĉu via regulo falas antaŭ aŭ post ekzistanta malpermeso. Konfirmu la interfacajn nomojn kaj internajn adresojn kontraŭ la deplojo anstataŭ kontraŭ la ekzemplo, kaj memoru, ke kiam cela NAT ruliĝas unue, la filtrilo vidas la tradukitan celon.

Tenu la revenan vojon kun stato

UFW spuras permesitajn konektojn, do la respondoj al permesita plusendata fluo estas akceptataj sen eksplicita inversa regulo. Aldoni senliman regulon en la mala direkto por ke aferoj funkciu larĝigas la politikon multe preter la unu servo kaj ne necesas por normala interŝanĝo de peto kaj respondo. Tenu la revenan vojon implica kaj la regulan aron legebla.

Apliku la regulon nur post kiam la provrulo kongruas kun via intenco, poste konfirmu, ke la ordigita listo montras ĝin en la atendata pozicio. Konservu la VPN-aŭskultanton kaj la administrajn regulojn kiel apartajn aferojn, ĉar ŝanĝi ilin estas alia decido ol enlasi unu aplikaĵon. Notu la ŝanĝon en la sama loko kie la topologio estas skribita, por ke la sekva inĝeniero ne retrovu ĝin el paketa kapto.

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

Kontrolu, kion UFW ne povas devigi por vi

Ĝusta regulo ankoraŭ bezonas kernan plusendadon kaj vojon kiu atingas la servon. Konfirmu ambaŭ antaŭ ol kulpi la fajroŝirmon duan fojon.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Poste rigardu ekster la gastigon. Ĉe nuba instanco la UFW-politiko de la gasto ne anstataŭas sekurecajn grupojn, subretajn ACL-ojn aŭ la propran plusendadan agordon de la provizanto, do loka bloko estas pruvo pri unu tavolo, ne pruvo ke ĉiu alia tavolo permesas la servon.

Finu per testo de nova konekto kun la fajroŝirmo ŝaltita, el permesita fonto kaj el nerilata. Malŝalti UFW forigas la simptomon kaj detruas la pruvon en la sama komando, tial ĝi devus esti la lasta eksperimento anstataŭ la unua.