ufw allow 443 hjälpte inte en tjänst bakom VPN:en

Ping lyckas från en VPN-klient, TCP-tjänsten får timeout och ufw allow 443/tcp ändrar absolut ingenting. När programmet körs på en värd bakom gatewayen i stället för på gatewayen själv skrevs tillståndet för fel trafikväg. Paketet är inte adresserat till brandväggen och levereras inte till någon lokal process, så indatareglerna ser det aldrig. Åtgärden är en rutteregel riktad mot det vidarebefordrade flödet, och beviset för den finns redan i loggen.

Avgör om destinationen är lokal eller vidarebefordrad

Läs paketet som kärnan ser det. Trafik som levereras till en tjänst på gatewayen är lokal indata. Trafik som gatewayen routar vidare till en annan värd är vidarebefordrad, och UFW håller separata regeluppsättningar för de två vägarna. Skillnaden avgörs av destinationsadressen och ruttuppslaget, inte av gränssnittet som paketet kom in på.

En logglinje som visar samma gränssnitt i både IN- och OUT-fältet kan fortfarande beskriva ett routat paket, eftersom en tunnel som bär klienter in och ut ur en enda enhet ser precis så ut. Destinationsadressen avgör frågan snabbare än gränssnittsnamnen. Att se samma namn två gånger bevisar inte lokal leverans, och att hitta på ett tunnelgränssnitt som driftsättningen aldrig skapade hjälper inte heller.

Läs blocket innan du lägger till någon regel

Återskapa ett auktoriserat anslutningsförsök och registrera källa, destination, protokoll och destinationsport så som gatewayen registrerade dem. Jämför de fyra värdena med loggposten och med tjänstens faktiska placering. En tidigare lyckad ping bevisar bara att dess eget utbyte var tillåtet, och en brandvägg kan behandla en TCP SYN mot ett program helt annorlunda.

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

Det första kommandot returnerar avgörandet med sina fält, och det andra visar vad som redan är laddat och i vilken ordning. Läs båda innan du redigerar något, eftersom en tidigare nekning ovanför din regel förklarar samma symptom utan någon saknad regel.

Skriv den smalaste rutteregel som passar

I det här exemplet kommer klienterna in på tun0 från 172.20.8.0/24, tjänsten lyssnar på 10.30.0.15 på port 8443, och gatewayen går ut via ens5. Värdena valdes för att inte alls likna en moln-VPC-standard på 10.0.0.0/16 eller ett hemmanät på 192.168.0.0/16, och 8443 håller exemplet borta från gatewayens egen 443-lyssnare.

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

Testkörningen skriver ut den regeluppsättning som skulle bli resultatet, och det är det billigaste sättet att se om din regel landar före eller efter en befintlig nekning. Bekräfta gränssnittsnamnen och de inre adresserna mot driftsättningen i stället för mot exemplet, och kom ihåg att när destinations-NAT körs först ser filtret den översatta destinationen.

Håll returvägen tillståndsfull

UFW spårar tillåtna anslutningar, så svaren på ett tillåtet vidarebefordrat flöde släpps in utan en uttrycklig omvänd regel. Att lägga till en obegränsad regel i motsatt riktning för att få saker att fungera vidgar policyn långt bortom den enda tjänsten och behövs inte för ett normalt fråga-svar-utbyte. Håll returvägen implicit och regeluppsättningen läsbar.

Tillämpa regeln först när testkörningen stämmer med din avsikt, och bekräfta sedan att den ordnade listan visar den på förväntad plats. Behåll VPN-lyssnaren och administrationsreglerna som skilda angelägenheter, eftersom att ändra dem är ett annat beslut än att släppa in ett program. Anteckna ändringen där topologin är nedskriven, så att nästa ingenjör inte behöver upptäcka den igen från en paketfångst.

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

Kontrollera vad UFW inte kan genomdriva åt dig

En korrekt regel behöver fortfarande vidarebefordran i kärnan och en rutt som når tjänsten. Bekräfta båda innan du skyller på brandväggen en andra gång.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Titta sedan utanför värden. På en molninstans ersätter gästens UFW-policy inte säkerhetsgrupper, subnät-ACL:er eller leverantörens egen vidarebefordranskonfiguration, så ett lokalt block är bevis om ett lager och inte bevis för att alla andra lager tillåter tjänsten.

Avsluta med att testa en ny anslutning med brandväggen påslagen, från en tillåten källa och från en orelaterad. Att inaktivera UFW tar bort symptomet och förstör beviset i samma kommando, därför bör det vara det sista experimentet och inte det första.