Comutatorul de urgență al UFW blochează VPN-ul? Permite partenerul

Ai urmat lista de verificare: refuză ieșirea, permite tunelul, activează ufw. Apoi clientul așteaptă la strângerea de mână și nu se conectează niciodată, sau se conectează și nicio pagină nu se încarcă. Ambele eșecuri vin din aceeași lipsă. Regula care lasă tunelul să existe lipsește, pentru că tunelul nu este o interfață prin care ies pachetele tale.

De ce o permisiune pe tun0 nu se potrivește cu nimic la început

tun0 este creat de client după ce există o sesiune. Datagramele care construiesc acea sesiune sunt pachete UDP obișnuite adresate furnizorului pe portul 1194, și ies prin wlan0 sau eth0 cu adresa sursă fizică. allow out on tun0 se potrivește doar cu traficul a cărui interfață de ieșire este tun0, așa că în timpul strângerii de mână nu se potrivește cu nimic.

Pune default deny outgoing deasupra și pachetele exterioare sunt aruncate înainte ca interfața să apară. Clientul reîncearcă, expiră și raportează o eroare TLS sau de strângere de mână, ceea ce trimite oamenii să caute prin certificate și MTU în timp ce firewallul mănâncă conexiunea în tăcere. Regula care trebuia să-ți țină traficul în frâu împiedică acel trafic să fie ținut în frâu.

Corectura reflexă face scurgerea permanentă. sudo ufw allow out on wlan0, sau readucerea valorii implicite la permitere, ridică tunelul și lasă mașina fără comutator de urgență: data viitoare când tunelul cade, totul repornește prin adaptorul fizic. Am pierdut o după-amiază exact pe acea pereche de modificări înainte să-mi dau seama ce pachet filtrez de fapt.

De ce au nevoie cele două seturi de pachete

Traficul tău traversează firewallul de două ori, în două forme. Pachetul interior pleacă de la adresa tunelului spre exterior prin tun0. Pachetul exterior merge de la adresa fizică la partener, și este singurul lucru vizibil pe fir. O regulă pentru fiecare formă:

sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'

Înlocuiește adresa și portul cu cele din propriul profil. Partenerii WireGuard răspund de obicei pe 51820/udp; profilurile OpenVPN care merg pe TCP 443 au nevoie de acel port în schimb. Detaliile diferă, forma nu: ambele reguli sunt înguste și împreună definesc singurele destinații pe care mașina le poate atinge cât timp tunelul e jos.

Ordinea este al doilea mit. Cu iptables brut citești lanțul de sus în jos și raționezi care regulă câștigă. ufw nu este un înveliș subțire în jurul listei pe care ai tastat-o; el compilează regulile tale în lanțuri proprii și alege punctele de inserare. ufw status le tipărește în ordinea ufw, nu a ta. Când o regulă pare ignorată, compară ufw show added cu setul compilat din iptables -S | grep ufw înainte de a rescrie ceva.

Excepția trebuie să rămână lată de o singură adresă

O regulă de partener este corectă doar cât timp numește adresa pe care clientul o apelează. Furnizorii rotesc punctele finale, iar un profil care rezolvă un nume de gazdă va urma o schimbare DNS către o adresă nouă în timp ce regula arată în continuare spre cea veche. Când un tunel care a funcționat luni de zile nu mai urcă, compară adresa din regulă cu cea pe care o caută clientul înainte de a lărgi ceva.

Lărgirea la o subrețea întreagă, sau la fiecare destinație pe portul 1194, transformă politica din nou într-un firewall cu o gaură. Excepția este comutatorul de urgență; odată ce e lat, nu mai rămâne nimic de oprit. Ține-l pe o singură adresă și lasă un comentariu care numește profilul și furnizorul cărora le aparține, pentru că peste șase luni adresa va părea arbitrară.

Rezolvarea numelor merită propria linie. Căutarea are loc înainte ca tunelul să existe, prin interfața fizică, așa că o politică strictă de refuz al ieșirii poate lăsa clientul incapabil să-și găsească propriul server. Permite portul 53 către adresa resolverului tău, sau rezolvă o dată și fixează adresa în profil. A permite DNS pe fiecare interfață este o decizie, nu o valoare implicită.

Construiește politica înainte ca tunelul să fie necesar

ufw enable aplică întreaga politică deodată și își reîncarcă lanțurile, iar schimbarea unei politici implicite pe un firewall aflat în funcțiune le reîncarcă și pe ele. manualul ufw avertizează că asta poate scăpa conexiuni existente precum SSH. De aceea comenzile merg în această ordine, cu regula SSH înainte de activare și o sesiune de consolă deschisă:

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

ufw reset este lăsat intenționat în afara acelui bloc. Șterge fiecare regulă și dezactivează firewallul, iar pe un host la distanță activarea următoare este cea care îți scapă sesiunea. Dacă totuși resetezi, adaugă regula SSH și confirmă o a doua cale de întoarcere prin consolă înainte de a merge mai departe.

Secvența nu este cosmetică. Regulile adăugate cât timp ufw rulează nu golesc nimic, dar în momentul în care întorci o politică implicită lanțurile se reîncarcă, iar o sesiune pe care politica veche o permitea pleacă împreună cu ele. Fă valorile implicite, permisiunile și activarea într-o singură trecere, cât timp mai ai o cale de intrare care nu depinde de mașină.

Testează starea blocată și păstrează anularea

Un comutator de urgență netestat este o presupunere. Deconectează clientul intenționat și încearcă să încarci o pagină: trebuie să eșueze. Reconectează și trebuie să-și revină fără să atingi vreo regulă. sudo ufw status verbose confirmă valorile implicite și starea jurnalizării, iar ufw status numbered arată ce regulă de test să ștergi când supraviețuiește scopului ei.

Ține scriptul invers lângă cel direct. O mașină cu refuz al ieșirii și un tunel mort nu-și poate descărca propria reparație, așa că anularea trebuie să stea pe disc și să fie lizibilă dintr-o consolă:

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

Rulează-l când tunelul e deja jos și regulile trebuie scoase, nu ca pas de rutină. Înainte să închizi terminalul, patru lucruri trebuie să fie adevărate: regula partenerului numește exact o adresă, DNS-ul are o excepție numită, activarea a venit după permisiuni, iar scoaterea tunelului ucide traficul obișnuit fără să ucidă clientul definitiv.