ufw allow 443 nuk bëri asgjë për një shërbim pas VPN-së

Ping-u kalon nga një klient VPN, shërbimi TCP skadon dhe ufw allow 443/tcp nuk ndryshon absolutisht asgjë. Kur aplikacioni ekzekutohet në një host pas portës dhe jo në vetë portën, ajo leje u shkrua për rrugën e gabuar të trafikut. Paketa nuk është adresuar te firewall-i dhe nuk dorëzohet te asnjë proces lokal, prandaj rregullat hyrëse nuk e shohin kurrë. Rregullimi është një rregull rruge i drejtuar nga rrjedha e përcjellë, dhe prova për të gjendet tashmë në regjistër.

Vendosni nëse destinacioni është lokal apo i përcjellë

Lexoni paketën ashtu siç e sheh kerneli. Trafiku i dorëzuar te një shërbim në portë është hyrje lokale. Trafiku që porta e drejton më tej te një host tjetër është i përcjellë, dhe UFW mban grupe rregullash të veçanta për të dyja rrugët. Diferencën e vendos adresa e destinacionit dhe kërkimi i rrugës, jo ndërfaqja në të cilën mbërriti paketa.

Një rresht regjistri që tregon të njëjtën ndërfaqe në të dy fushat IN dhe OUT mund të përshkruajë gjithsesi një paketë të rrugëzuar, sepse një tunel që i çon klientët brenda dhe jashtë një pajisjeje të vetme duket pikërisht kështu. Adresa e destinacionit e zgjidh çështjen më shpejt sesa emrat e ndërfaqeve. Të shohësh të njëjtin emër dy herë nuk provon dorëzim lokal, dhe sajimi i një ndërfaqeje tuneli që vendosja nuk e krijoi kurrë nuk ndihmon gjithashtu.

Lexoni bllokun përpara se të shtoni ndonjë rregull

Riprodhoni një tentativë të autorizuar lidhjeje dhe regjistroni burimin, destinacionin, protokollin dhe portën e destinacionit ashtu siç i regjistroi porta. Krahasoni ato katër vlera me hyrjen e regjistrit dhe me vendndodhjen reale të shërbimit. Një ping i suksesshëm më parë provon vetëm se shkëmbimi i tij vetjak ishte i lejuar, dhe një firewall mund ta trajtojë një TCP SYN drejt një aplikacioni krejt ndryshe.

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

Komanda e parë kthen vendimin bashkë me fushat e tij, dhe e dyta tregon çfarë është ngarkuar tashmë dhe në çfarë rendi. Lexoni të dyja përpara se të redaktoni diçka, sepse një refuzim i mëparshëm mbi rregullin tuaj shpjegon të njëjtin simptom pa asnjë rregull që mungon.

Shkruani rregullin më të ngushtë të rrugës që përshtatet

Në këtë shembull klientët mbërrijnë në tun0 nga 172.20.8.0/24, shërbimi dëgjon në 10.30.0.15 në portën 8443, dhe porta del përmes ens5. Ato vlera u zgjodhën që të mos ngjajnë aspak me një parazgjedhje të VPC-së në re prej 10.0.0.0/16 ose me një rrjet shtëpiak prej 192.168.0.0/16, dhe 8443 e mban shembullin larg dëgjuesit 443 të vetë portës.

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

Ekzekutimi i thatë printon grupin e rregullave që do të rezultonte, dhe ky është mënyra më e lirë për të parë nëse rregulli juaj bie përpara një refuzimi ekzistues apo pas tij. Verifikoni emrat e ndërfaqeve dhe adresat e brendshme kundrejt vendosjes dhe jo kundrejt shembullit, dhe mbani mend se kur NAT-i i destinacionit ekzekutohet i pari, filtri sheh destinacionin e përkthyer.

Mbajeni rrugën e kthimit me gjendje

UFW ndjek lidhjet e lejuara, prandaj përgjigjet ndaj një rrjedhe të përcjellë të lejuar pranohen pa një rregull të kundërt të shprehur. Shtimi i një rregulli të pakufizuar në drejtimin e kundërt që gjërat të funksionojnë e zgjeron politikën shumë përtej shërbimit të vetëm dhe nuk kërkohet për një shkëmbim normal kërkese dhe përgjigjeje. Mbajeni rrugën e kthimit të nënkuptuar dhe grupin e rregullave të lexueshëm.

Zbatojeni rregullin vetëm pasi ekzekutimi i thatë përputhet me qëllimin tuaj, dhe më pas konfirmoni që lista e renditur e shfaq në pozicionin e pritur. Mbajeni dëgjuesin e VPN-së dhe rregullat e menaxhimit si çështje të veçanta, sepse ndryshimi i tyre është një vendim tjetër nga lejimi i një aplikacioni. Shënoni ndryshimin atje ku është shkruar topologjia, që inxhinieri i ardhshëm të mos e rizbulojë nga një kapje paketash.

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

Kontrolloni çfarë UFW nuk mund të zbatojë për ju

Një rregull i saktë ka ende nevojë për përcjellje në kernel dhe për një rrugë që arrin shërbimin. Konfirmoni të dyja përpara se ta fajësoni firewall-in për herë të dytë.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Më pas shikoni jashtë hostit. Në një instancë në re, politika e UFW-së së mysafirit nuk zëvendëson grupet e sigurisë, ACL-të e nënrrjetit ose konfigurimin e vetë ofruesit për përcjellje, prandaj një bllokim lokal është provë për një shtresë dhe jo prova se çdo shtresë tjetër e lejon shërbimin.

Përfundoni duke testuar një lidhje të re me firewall-in të aktivizuar, nga një burim i lejuar dhe nga një i palidhur. Çaktivizimi i UFW-së e heq simptomën dhe e shkatërron provën në të njëjtën komandë, prandaj duhet të jetë eksperimenti i fundit dhe jo i pari.