ufw allow 443 het niks vir 'n diens agter die VPN gedoen nie

Ping slaag vanaf 'n VPN-kliënt, die TCP-diens hou op reageer, en ufw allow 443/tcp verander heeltemal niks. Wanneer die toepassing op 'n gasheer agter die poort draai eerder as op die poort self, is daardie toelating vir die verkeerde verkeerspad geskryf. Die pakket is nie aan die vuurmuur geadresseer nie en word nie aan 'n plaaslike proses afgelewer nie, so die invoerreëls sien dit nooit. Die herstel is 'n roetereël gerig op die deurgestuurde vloei, en die bewyse daarvoor is reeds in die log.

Bepaal of die bestemming plaaslik of deurgestuur is

Lees die pakket soos die kernel dit sien. Verkeer wat aan 'n diens op die poort afgelewer word, is plaaslike invoer. Verkeer wat die poort na 'n ander gasheer deurstuur, is deurgestuur, en UFW hou afsonderlike reëlversamelings vir die twee paaie. Die onderskeid word deur die bestemmingsadres en die roetesoektog bepaal, nie deur watter koppelvlak die pakket op aangekom het nie.

'n Logreël wat dieselfde koppelvlak in beide die IN- en OUT-velde wys, kan steeds 'n geroteerde pakket beskryf, want 'n tonnel wat kliënte by een toestel in en uit dra, lyk presies so. Die bestemmingsadres besleg die vraag vinniger as wat die koppelvlakname dit doen. Om dieselfde naam twee keer te sien bewys nie plaaslike aflewering nie, en om 'n tonnelkoppelvlak te bedink wat die ontplooiing nooit geskep het nie, help ook nie.

Lees die blok voordat jy enige reël byvoeg

Reproduseer een gemagtigde verbindingspoging en teken die bron, bestemming, protokol en bestemmingspoort op soos die poort dit aangeteken het. Vergelyk daardie vier waardes met die loginskrywing en met die diens se werklike ligging. 'n Suksesvolle ping vroeër bewys slegs dat sy eie uitruiling toegelaat is, en 'n vuurmuur kan 'n TCP SYN na 'n toepassing heeltemal anders behandel.

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

Die eerste opdrag gee die uitspraak saam met die velde daarvan, en die tweede wys wat reeds gelaai is en in watter volgorde. Lees albei voordat jy iets wysig, want 'n vroeëre weiering bo jou reël verduidelik dieselfde simptoom sonder enige ontbrekende reël.

Skryf die engste roetereël wat pas

Vir hierdie deurloop kom kliënte op tun0 van 172.20.8.0/24 af, luister die diens op 10.30.0.15 by poort 8443, en verlaat die poort die netwerk deur ens5. Daardie waardes is gekies om heeltemal anders as 'n wolke-VPC-verstek van 10.0.0.0/16 of 'n tuisnetwerk van 192.168.0.0/16 te lyk, en 8443 hou die voorbeeld weg van die poort se eie 443-luisteraar.

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

Die droë loop druk die reëlversameling wat sou ontstaan, wat die goedkoopste manier is om te sien of jou reël voor of na 'n bestaande weiering beland. Bevestig die koppelvlakname en binne-adresse teen die ontplooiing eerder as teen die voorbeeld, en onthou dat wanneer bestemming-NAT eerste loop, die filter die vertaalde bestemming sien.

Hou die terugpad staatvol

UFW volg toegelate verbindings, so die antwoorde op 'n toegelate deurgestuurde vloei word toegelaat sonder 'n eksplisiete omgekeerde reël. Om 'n onbeperkte reël in die teenoorgestelde rigting by te voeg om dinge te laat werk, verbreed die beleid ver verby die enkele diens en is nie vir 'n normale versoek-antwoord-uitruiling nodig nie. Hou die terugpad implisiet en die reëlversameling leesbaar.

Pas die reël eers toe nadat die droë loop by jou bedoeling pas, en bevestig dan dat die geordende lys dit op die verwagte plek wys. Behou die VPN-luisteraar en die bestuursreëls as afsonderlike sake; 'n verandering daaraan is 'n ander besluit as om een toepassing toe te laat. Noteer die verandering op dieselfde plek waar die topologie neergeskryf is, sodat die volgende ingenieur dit nie weer uit 'n pakketopname hoef te ontdek nie.

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

Kyk wat UFW nie vir jou kan afdwing nie

'n Korrekte reël het steeds kernel-deursturing en 'n roete na die diens nodig. Bevestig albei voordat jy die vuurmuur 'n tweede keer blameer.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Kyk dan buite die gasheer. Op 'n wolke-instansie vervang die gas se UFW-beleid nie sekuriteitsgroepe, subnet-ACL's of die verskaffer se eie deursturingskonfigurasie nie, so 'n plaaslike blok is bewys oor een laag eerder as 'n bewys dat elke ander laag die diens toelaat.

Sluit af deur 'n nuwe verbinding met die vuurmuur geaktiveer te toets, vanaf 'n toegelate bron en vanaf een wat nie verwant is nie. Om UFW te deaktiveer verwyder die simptoom en vernietig die bewyse in dieselfde opdrag, en daarom behoort dit die laaste eksperiment te wees eerder as die eerste.