VPN conectat, dar firewall-ul încă blochează: cum să afli care dintre ele

Tunelul funcționează și un port tot eșuează. Citește calea, apoi politica pe fiecare strat, și schimbă cea mai îngustă regulă în loc să dezactivezi oricare dintre cele două controale.

Clientul spune conectat, resursa tot refuză, iar următorul pas obișnuit este să oprești ceva. Cele două controale din acea frază fac treburi diferite: VPN-ul construiește o cale pentru traficul acoperit, iar un firewall decide pentru fiecare conexiune dacă traficul poate trece. Un tunel funcțional cu o politică ce refuză arată exact ca un tunel stricat din scaunul utilizatorului, așa că sarcina este să afli care strat răspunde. Iată ordinea pe care o urmez, cu citirea care îți spune să te oprești.

Separă calea de politică

Începe cu forma eșecului, pentru că este informație gratuită. Un pachet aruncat produce un timeout: clientul reîncearcă, nimic nu se întoarce, iar comanda atârnă până cedează. Un refuz produce o negare sau un reset: ceva a răspuns și a spus nu. Un serviciu care nu ascultă refuză pe gazda însăși, fără niciun firewall.

Acele trei rezultate indică straturi diferite. Timeout înseamnă că undeva o politică aruncă în tăcere, sau că ruta nu părăsește niciodată mașina. Refuzat înseamnă că ai ajuns la gazdă și stiva ei sau firewall-ul local a refuzat. Liniște totală, cu interfața tunelului activă și fără rută către destinație, înseamnă că ruta este greșită și nicio regulă de firewall nu o repară.

Citește calea într-o singură trecere

Confirmă că tunelul acoperă destinația înainte de a te uita la măcar o regulă. Un tunel divizat care transportă doar subrețeaua biroului nu va direcționa o cerere către alt interval, iar atunci eșecul arată ca o blocare a firewall-ului care nu este:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

Ieșirea rutei numește interfața prin care va pleca pachetul și adresa sursă pe care o va purta. Dacă acea interfață este placa ta de rețea fizică și nu tunelul, problema este în rutare sau în intervalele permise ale tunelului, și aparține configurației VPN, nu firewall-ului.

O capcană proprie VPN-ului merită o verificare separată. În WireGuard, AllowedIPs unui peer este simultan rută și filtru criptografic: un pachet a cărui adresă sursă nu se potrivește cu setul permis al peer-ului este aruncat înainte de a fi consultată vreo regulă de firewall. Așa, un firewall de gazdă perfect corect poate sta în spatele unei aruncări silențioase care pare o politică, iar remedierea este o linie de configurare a cheii, nu o regulă.

Citește politica în stratul care răspunde

Odată ce calea este corectă, parcurge politica de la gazdă spre exterior și urmărește singurul strat ale cărui contoare se mișcă:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

Socketul care ascultă răspunde la o altă întrebare decât regulile. Dacă nimic nu ascultă pe port, nucleul refuză conexiunea și nicio regulă de intrare nu este relevantă. Dacă socketul există și conexiunea de la un client îndepărtat expiră, o aruncare are loc undeva pe cale, iar contoarele regulilor îți spun dacă se întâmplă aici.

Activează jurnalizarea pentru profilul sau lanțul pe care îl suspectezi în loc să ghicești din exterior. O singură aruncare înregistrată care numește sursa, destinația și portul identifică stratul și regula, și dovedește și că pachetul a ajuns, ceea ce niciun test din partea clientului nu poate stabili.

Citește decizia gateway-ului când tunelul se termină acolo

Pe un gateway site-to-site sau de acces la distanță, VPN-ul autentifică un utilizator, iar politica autorizează o resursă, și acestea sunt acordări separate. Un utilizator admis în tunel nu este admis automat pe fiecare gazdă internă, iar refuzul vine adesea dintr-o regulă de forwarding în timp ce tunelul însuși este sănătos. Aceeași separare apare în IPsec, unde politica de securitate care selectează traficul diferă de filtrul care îl admite, și de aceea cele două sunt documentate ca mecanisme diferite în RFC 4301.

Verifică calea de întoarcere la fel de atent ca pe cea de ieșire. Filtrarea cu stare trebuie să vadă răspunsul, așa că rutarea asimetrică prin tunel într-o direcție și pe lângă el în cealaltă produce aruncări care par aleatorii și se reproduc doar de la unii clienți. Dacă traficul ajunge la gateway și se oprește, citește regula de forwarding și ruta de întoarcere împreună înainte de a lărgi ceva.

Gateway-ul este și locul unde o regulă NAT sau de mascare poate ascunde sursa reală. Dacă gazdele interne văd adresa gateway-ului în locul clientului, regulile lor de firewall de gazdă care trebuie să corespundă grupului de clienți nu vor corespunde niciodată, iar remedierea aparține gateway-ului, nu fiecărui server.

Schimbă cel mai îngust strat, apoi verifică

Rezistă reparației largi. Dezactivarea firewall-ului de gazdă, adăugarea unei reguli care permite tot sau împingerea fiecărei interfețe într-un profil de încredere elimină de fiecare dată controlul care își făcea treaba, iar schimbarea supraviețuiește incidentului. O regulă limitată la intervalul sursă și la portul în cauză este mai ușor de revizuit, mai ușor de eliminat și lasă restul politicii mașinii intact.

Verifică cu același test care a eșuat, de la același client, apoi încă o dată după reconectare, pentru că o regulă care se potrivea înainte ca tunelul să renegocieze poate înceta să se potrivească după:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Înainte să închizi:

  • Ruta către destinație iese prin interfața tunelului, iar adresa sursă corespunde cu ce așteaptă politica.
  • Ceva ascultă pe port, iar refuzul sau timeout-ul este atribuit unei reguli numite, nu presupus.
  • Gateway-ul forwardează în ambele sensuri, iar destinația vede sursa pentru care au fost scrise regulile tale.
  • Niciun control nu a fost dezactivat pentru ca testul să treacă, iar schimbarea pe care ai făcut-o numește un singur interval sursă și un singur port.

Articole similare