ufw allow 443 nu a făcut nimic pentru un serviciu din spatele VPN-ului

Pingul reușește dintr-un client VPN, serviciul TCP expiră, iar ufw allow 443/tcp nu schimbă absolut nimic. Când aplicația rulează pe o gazdă din spatele gateway-ului și nu pe gateway-ul însuși, acea permisiune a fost scrisă pentru calea greșită de trafic. Pachetul nu este adresat paravanului și nu este livrat vreunui proces local, așa că regulile de intrare nu îl văd niciodată. Remedierea este o regulă de rută îndreptată spre fluxul redirecționat, iar dovada se află deja în jurnal.

Decideți dacă destinația este locală sau redirecționată

Citiți pachetul așa cum îl vede nucleul. Traficul livrat unui serviciu de pe gateway este intrare locală. Traficul pe care gateway-ul îl rutează mai departe către altă gazdă este redirecționat, iar UFW ține seturi de reguli separate pentru cele două căi. Diferența este decisă de adresa de destinație și de căutarea rutei, nu de interfața pe care a sosit pachetul.

O linie de jurnal care arată aceeași interfață în ambele câmpuri IN și OUT poate descrie în continuare un pachet rutat, pentru că un tunel care duce clienții înăuntru și în afară dintr-un singur dispozitiv arată exact așa. Adresa de destinație lămurește întrebarea mai repede decât numele interfețelor. Vederea aceluiași nume de două ori nu dovedește o livrare locală, iar inventarea unei interfețe de tunel pe care implementarea nu a creat-o niciodată nu ajută nici ea.

Citiți blocul înainte de a adăuga orice regulă

Reproduceți o singură încercare de conexiune autorizată și notați sursa, destinația, protocolul și portul de destinație așa cum le-a înregistrat gateway-ul. Comparați cele patru valori cu înregistrarea din jurnal și cu locația reală a serviciului. Un ping reușit anterior dovedește doar că propriul său schimb a fost permis, iar un paravan poate trata un TCP SYN către o aplicație complet diferit.

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

Prima comandă returnează verdictul împreună cu câmpurile sale, iar a doua arată ce este deja încărcat și în ce ordine. Citiți-le pe amândouă înainte de a edita ceva, pentru că o respingere anterioară deasupra regulii dumneavoastră explică același simptom fără nicio regulă lipsă.

Scrieți cea mai îngustă regulă de rută care se potrivește

În acest exemplu, clienții sosesc pe tun0 din 172.20.8.0/24, serviciul ascultă pe 10.30.0.15 la portul 8443, iar gateway-ul iese prin ens5. Acele valori au fost alese ca să nu semene deloc cu o valoare implicită de VPC în cloud de 10.0.0.0/16 sau cu o rețea de acasă de 192.168.0.0/16, iar 8443 ține exemplul departe de propriul ascultător 443 al gateway-ului.

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

Rularea de probă tipărește setul de reguli care ar rezulta, iar acesta este cel mai ieftin mod de a vedea dacă regula dumneavoastră ajunge înainte sau după o respingere existentă. Verificați numele interfețelor și adresele interne față de implementare și nu față de exemplu, și țineți minte că atunci când NAT-ul de destinație rulează primul, filtrul vede destinația tradusă.

Păstrați calea de întoarcere cu stare

UFW urmărește conexiunile permise, așa că răspunsurile la un flux redirecționat permis sunt admise fără o regulă inversă explicită. Adăugarea unei reguli nelimitate în direcția opusă pentru ca lucrurile să funcționeze lărgește politica mult dincolo de un singur serviciu și nu este necesară pentru un schimb normal de cerere și răspuns. Păstrați calea de întoarcere implicită și setul de reguli lizibil.

Aplicați regula doar după ce rularea de probă corespunde intenției dumneavoastră, apoi confirmați că lista ordonată o arată în poziția așteptată. Păstrați ascultătorul VPN și regulile de administrare ca probleme separate, pentru că modificarea lor este o decizie diferită de admiterea unei aplicații. Notați modificarea acolo unde este scrisă topologia, ca următorul inginer să nu o descopere din nou dintr-o captură de pachete.

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

Verificați ce nu poate impune UFW în locul dumneavoastră

O regulă corectă are în continuare nevoie de redirecționarea din nucleu și de o rută care ajunge la serviciu. Confirmați ambele înainte de a da vina pe paravan a doua oară.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Apoi priviți în afara gazdei. Pe o instanță din cloud, politica UFW a oaspetelui nu înlocuiește grupurile de securitate, ACL-urile de subrețea sau configurația proprie de redirecționare a furnizorului, așa că un blocaj local este o dovadă despre un singur strat și nu dovada că toate celelalte straturi permit serviciul.

Încheiați testând o conexiune nouă cu paravanul activ, dintr-o sursă permisă și dintr-una nelegată. Dezactivarea UFW elimină simptomul și distruge dovada în aceeași comandă, de aceea ar trebui să fie ultimul experiment și nu primul.