UFW aruncă serverul DNS al VPN-ului imediat ce tunelul urcă

Numele nu mai sunt rezolvate în momentul în care VPN-ul se conectează, în timp ce un ping către o adresă publică răspunde în continuare și starea firewall-ului nu arată nimic care să pară greșit. Politica nu s-a schimbat; ce s-a schimbat este că a apărut o interfață nouă, iar refuzul implicit o acoperă de la primul pachet. UFW decide după direcție și interfață, așa că o regulă scrisă pentru legătura fără fir nu spune nimic despre traficul care iese din tunel. Reparația este o mână de reguli înguste aplicate într-o anumită ordine.

Simptomul apare abia după ce tunelul este sus

O politică de refuz implicit face exact ce i s-a spus: orice fără o regulă potrivită este respins, pe fiecare interfață care există. Tunelul nu exista când au fost scrise regulile, deci niciuna dintre ele nu îl poate prinde, iar refuzul care a fost mereu acolo se aplică acum rezolvării numelor. Traficul direct către o adresă literală poate funcționa în continuare când o permisiune mai largă îl acoperă, și de aceea un ping către un resolver public reușește în timp ce căutarea unui nume eșuează. Golul este o regulă pentru o interfață pe care politica nu a văzut-o niciodată.

Asta explică și de ce defecțiunea se inversează curat: scoate tunelul și numele se rezolvă din nou, pentru că interogarea se întoarce la o interfață care are reguli. O politică ce eșuează doar cât timp tunelul este sus nu este o problemă DNS, iar reglarea resolverului însuși pierde cel mai mult timp aici. Citește lista interfețelor înainte de a citi configurația resolverului.

Trei direcții, trei seturi de reguli diferite

O singură sesiune atinge reguli în mai mult de o direcție, iar un tunel adaugă o a doua interfață aproape tuturor. Sortarea traficului mai întâi după direcție și interfață face restul mecanic, pentru că fiecare rând de mai jos are nevoie de propria regulă în propriul loc. Exemplele folosesc tun0 și un pool de 10.8.0.0/24, așa că înlocuiește numele și intervalele cu cele din ieșirea clientului însuși.

Două rânduri sunt adesea confundate pentru că ambele menționează tunelul. O regulă pentru resolver permite traficul pe care clientul îl trimite în tunel, în timp ce o regulă pentru SSH permite traficul pe care serverul îl primește de acolo; ele trăiesc pe mașini diferite și eșuează independent. Rândul cel mai des uitat este al doilea, pentru că clientul nu poate construi deloc tunelul până când traficul său către adresa publică a serverului nu este permis. Lucrează de sus în jos și fiecare eșec are o singură cauză posibilă.

Un resolver împins are nevoie de propria regulă

Dacă tunelul transportă DNS depinde de ce trimite serverul. Un server care împinge o opțiune de resolver instalează o adresă privată în configurația clientului, iar acea adresă este rutabilă doar prin tunel. Dacă serverul nu împinge nimic, clientul păstrează resolverul pe care îl avea deja, iar regulile de mai jos nu au nimic de permis. Verifică starea împinsă și rezultatul actual al interogării înainte de a scrie ceva:

dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numbered

Ieșirea de stare numește resolverul folosit și legătura de care este legat, iar căutarea rutei din spatele ei arată ce interfață ar transporta o interogare către acea adresă. Când resolverul stă pe altă legătură, problema este mai devreme decât firewall-ul și nicio regulă nu va ajuta. Când ambele sunt de acord asupra tunelului, sunt necesare două reguli, pentru că UDP transportă majoritatea interogărilor, iar TCP preia când un răspuns este trunchiat. Notează ambele valori, pentru că ele sunt cele pe care regulile le vor numi:

sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'

Deschide calea exterioară înaintea celei interioare

Clientul trebuie să atingă adresa publică a serverului înainte ca un tunel să existe, așa că regula pentru ea stă pe legătura fizică și trebuie să fie la locul ei prima. O politică ce permite resolverul dar uită serverul lasă clientul complet incapabil să construiască tunelul, iar acel simptom este de obicei pus pe seama unui kill switch. Apoi permite serviciile pe care le voiai cu adevărat prin tunel, câte o regulă îngustă o dată, în loc să deschizi interfața în întregime. Regulile înguste sunt motivul pentru care refuzul poate rămâne la locul lui.

sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'

Ordinea contează în timpul testelor, pentru că prima regulă este cea care lasă tunelul să urce. Adaug-o, conectează-te și confirmă că tunelul este sus înainte de a adăuga regula serviciului, pentru că a face ambele deodată înseamnă că un eșec nu îți spune nimic despre care jumătate este greșită. Înlocuiește adresa de documentare de mai sus cu punctul final pentru care clientul este configurat.

Încheie partea clientului deconectând intenționat. Refuzul ar trebui să respingă în continuare traficul pe care l-ai exclus intenționat, pentru că un resolver care răspunde cât timp tunelul este sus acoperă doar jumătate dintr-o politică ce refuză în caz de îndoială.

Un client care se conectează nu este încă admis

Serverul are propria direcție de luat în considerare, iar un client care finalizează strângerea de mână tot nu ajunge la nimic ce rulează pe server până când serverul nu îl admite. Regula listenerului public permite doar ca tunelul să existe; nu lasă traficul tunelului să intre. Pe server acestea sunt două reguli plus o verificare că serviciul chiar ascultă:

sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'

Pool-ul din regulă trebuie să fie egal cu intervalul pe care serverul îl alocă, iar numărul tunelului trebuie să corespundă cu cel creat de server, pentru că o regulă pentru altă interfață este de nedistins de nicio regulă. limit este deliberat pentru un port administrativ, pentru că limitează conexiunile repetate în loc să le admită fără limită. Verificarea listenerului separă un port închis de un pachet aruncat, care din partea clientului arată identic. Nici regulile numerotate nu sunt toată imaginea: regulile before ale UFW și orice linie nftables scrisă manual se potrivesc mai devreme și pot încă refuza un pachet pe care lista pare să îl permită.