ufw allow 443 die neat foar in tsjinst efter de VPN

Ping slagget fan in VPN-klant, de TCP-tsjinst rint yn 'e tiid, en ufw allow 443/tcp feroaret hielendal neat. Wannear't de applikaasje op in host efter de gateway rint en net op 'e gateway sels, is dy tagong foar it ferkearde ferkearspaad skreaun. It pakket is net oan 'e firewall adressearre en wurdt net oan in lokaal proses levere, dus de ynfierregels sjogge it nea. De reparaasje is in rûteregel rjochte op 'e trochstjoerde stream, en it bewiis dêrfoar stiet al yn it log.

Bepale oft it doel lokaal as trochstjoerd is

Lês it pakket sa't de kernel it sjocht. Ferkear dat oan in tsjinst op 'e gateway levere wurdt, is lokale ynfier. Ferkear dat de gateway nei in oare host trochroutet, is trochstjoerd, en UFW hâldt aparte regelsets foar de twa paden. It ûnderskie wurdt bepaald troch it doeladres en de rûtesyktocht, net troch hokker ynterface it pakket op oankaam.

In logrigel dy't deselde ynterface yn sawol it IN- as it OUT-fjild toant, kin noch altyd in rûte pakket beskriuwe, want in tunnel dy't klanten by ien apparaat yn en út draacht, sjocht der krekt sa út. It doeladres beslist de fraach flugger as de ynterfacenammen dogge. Deselde namme twa kear sjen bewiist gjin lokale levering, en in tunnelinterface betinke dy't de útrôl nea makke hat, helpt ek net.

Lês it blok foardat jo in regel tafoegje

Reprodusearje ien autorisearre ferbiningspoging en fêstlizze de boarne, it doel, it protokol en de doelpoarte sa't de gateway se fêstlei. Ferlykje dy fjouwer wearden mei de loginfier en mei it wiere plak fan 'e tsjinst. In earder slagge ping bewiist allinnich dat syn eigen útwikseling tastien wie, en in firewall kin in TCP SYN nei in applikaasje hiel oars behannelje.

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

It earste kommando jout it oardiel mei syn fjilden werom, en it twadde lit sjen wat al laden is en yn hokker oarder. Lês beide foardat jo eat bewurkje, want in earder blokkearring boppe jo regel ferklearret itselde symptoom sûnder in missende regel.

Skriuw de smelste rûteregel dy't past

Yn dit foarbyld komme klanten op tun0 fan 172.20.8.0/24, harket de tsjinst op 10.30.0.15 op poarte 8443, en giet de gateway fuort troch ens5. Dy wearden binne keazen om hielendal net op in wolk-VPC-standert fan 10.0.0.0/16 as in thúsnetwurk fan 192.168.0.0/16 te lykjen, en 8443 hâldt it foarbyld fuort fan 'e eigen 443-harker fan 'e gateway.

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

De proefrin prints it regelset dat ûntstean soe, en dat is de goedkeapste manier om te sjen oft jo regel foar of nei in besteande blokkearring lânet. Befêstigje de ynterfacenammen en ynderlike adressen tsjin 'e útrôl en net tsjin it foarbyld, en tink derom dat as NAT foar it doel earst rint, it filter it oersetten doel sjocht.

Hâld it werompaad steatfêst

UFW folget tastiene ferbiningen, dus de antwurden op in tastiene trochstjoerde stream wurde talitten sûnder in eksplisite tsjinoerstelde regel. In ûnbeheinde regel yn 'e tsjinoerstelde rjochting tafoegje om dingen te litten wurkjen ferbreedt it belied fier bûten de iene tsjinst en is net nedich foar in normale fraach-antwurd-útwikseling. Hâld it werompaad ymplisyt en it regelset lêsber.

Pas de regel pas ta as de proefrin by jo bedoeling past, en befêstigje dan dat de oardere list him op it ferwachte plak toant. Hâld de VPN-harker en de behearregels as aparte saken, want dy feroarje is in oare beslissing as ien applikaasje talitte. Notearje de feroaring op itselde plak dêr't de topology skreaun is, sadat de folgjende yngenieur it net op 'e nij hoecht te ûntdekken út in pakketopname.

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

Kontrolearje wat UFW net foar jo ôftwinge kin

In korrekte regel hat noch kernel-trochstjoering en in rûte nei de tsjinst nedich. Befêstigje beide foardat jo de firewall in twadde kear beskylgje.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Sjoch dan bûten de host. Op in wolk-ynstânsje ferfangt it UFW-belied fan 'e gast gjin feiligensgroepen, subnet-ACL's of de eigen trochstjoeringskonfiguraasje fan 'e provider, dus in lokale blokkearring is bewiis oer ien laach en net it bewiis dat elke oare laach de tsjinst tastiet.

Einigje mei it testen fan in nije ferbining mei de firewall oan, fan in tastiene boarne en fan ien dy't der neat mei te meitsjen hat. UFW útsette hellet it symptoom fuort en ferneatiget it bewiis yn itselde kommando, dêrom soe it it lêste eksperimint wêze moatte en net it earste.