Un firewall al distribuției Linux poate bloca traficul VPN

Tunelul urcă, jurnalul spune conectat, iar o aplicație tot nu ajunge nicăieri. Pe un client Linux asta înseamnă de obicei că firewall-ul distribuției filtrează o cale pe care clientul VPN nu a administrat-o niciodată. Doi manageri pot fi activi simultan, fiecare cu propriile idei despre interfață, zonă și direcția traficului. Identificarea proprietarului înainte de a modifica ceva este mai rapidă decât încercarea regulilor până când ceva funcționează.

Găsește managerul și backend-ul

Începe cu ce este efectiv încărcat, nu cu ce este instalat. O distribuție poate livra firewalld, ufw și un serviciu nftables simplu, iar doar unul dintre ele deține setul de reguli care rulează. Pachetele coexistă pașnic, iar o regulă introdusă prin frontend-ul greșit nu ajunge niciodată la nucleu. Citește serviciul activ, apoi citește setul de reguli pe care l-a produs.

Backend-ul contează la fel de mult ca frontend-ul. O instalare firewalld poate conduce nftables sau vechiul backend iptables în funcție de versiune și configurație, iar cele două produc rezultate de inspecție diferite. Notează distribuția, versiunea și backend-ul în tichet înainte de a compara sistemul tău cu orice ghid.

Potrivește direcția și interfața

O cerere de ieșire a clientului, un ascultător de intrare și un pachet redirecționat trec prin cârlige diferite, iar o regulă pentru unul nu le acoperă pe celelalte. O zonă care permite LAN-ul local adesea nu include interfața tunelului sau pool-ul de adrese VPN. Interfața tunelului ajunge de obicei în zona implicită, care este adesea mai strictă decât zona în care se află adaptorul fizic. Această nepotrivire explică de ce navigarea funcționează în LAN și se oprește în momentul în care tunelul urcă.

Întreabă care direcție a eșuat înainte de a alege o regulă. O aplicație care nu se poate conecta spre exterior are nevoie de calea de ieșire, în timp ce un serviciu de intrare are nevoie de calea de intrare pe interfața tunelului. Adăugarea unei reguli în lanțul greșit produce o schimbare care pare aplicată și nu face absolut nimic.

Ține proprietarii regulilor în acord

Cârligul unui client VPN, un mediu de execuție pentru containere și serviciul distribuției pot toate modifica rețeaua, și nu se coordonează între ele. Regulile introduse manual dispar la următoarea reîncărcare, iar regulile inserate în lanțul unui manager pot fi evaluate într-o ordine pe care nu ai intenționat-o. Folosește configurația persistentă a managerului și inspectează setul de reguli rezultat în locul fișierului pe care l-ai scris. Dezactivarea întregului firewall pentru că un serviciu este inaccesibil schimbă o problemă mică pe una mare.

Contoarele înguste sunt modalitatea ieftină de a găsi fluxul respins. O regulă de jurnalizare limitată la o singură destinație și un singur port arată dacă eliminarea are loc local fără a captura traficul altcuiva. Elimină regula de jurnalizare când ancheta se încheie, deoarece este diagnostic și nu politică, și documentația de zone a firewalld explică modul în care interfețele și serviciile se combină.

Verifică remedierea fără a pierde blocarea

Inspectează starea aplicată cu managerul care o deține, folosind comenzi care corespund backend-ului notat. Lista de mai jos presupune că firewalld este responsabil; înlocuiește cu echivalentul pentru nftables sau ufw în loc să le rulezi pe toate. Amestecarea instrumentelor într-o singură sesiune este felul în care o mașină ajunge cu două seturi de reguli conflictuale.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=trusted --list-all
sudo nft list ruleset | head -40

Prima comandă numește zonele și interfețele atribuite acestora, ceea ce arată unde a aterizat de fapt tunelul. A doua tipărește regulile și serviciile unei zone, astfel încât să poți vedea dacă interfața VPN este acoperită măcar. Lista nftables este adevărul de bază pentru backend-ul folosit, iar o regulă care există doar într-un fișier de configurare nu apare acolo. Compară cele trei ieșiri cu regula adăugată, iar nepotrivirea de obicei se numește singură.

Apoi repetă cererea originală și comportamentul de eșec pe care îl ceri. Un site care tocmai funcționează nu este suficient dacă aceeași modificare a eliminat blocarea clientului, așa că testează și o cale neprotejată. Notează managerul, backend-ul, interfața și scopul regulii, deoarece o actualizare de pachet care reînvie un al doilea manager va reconstrui altfel toată harababura.