Limitați regula SNAT a OpenVPN înainte să strice nginx

Două defecțiuni vin mereu de la același tip de gazdă. În prima, clienții se autentifică și apoi nu ajung nimic dincolo de tunel. În a doua, VPN-ul urcă și site-ul propriu al serverului nu mai răspunde, ceea ce este mai alarmant pentru că pare o daună colaterală. Pe un VPS bazat pe containere ambele se întorc de obicei la aceeași listă scurtă de verificări, iar ordinea contează: mai întâi dispozitivul, apoi traducerea, în final domeniul de aplicare.

Confirmați că containerul poate crea un dispozitiv tun

Nimic altceva nu contează dacă interfața tunelului nu poate exista. Verificați că /dev/net/tun este prezent și că crearea unui dispozitiv de test reușește, pentru că mulți furnizori dezactivează tun în containere implicit. Nicio muncă la firewall nu compensează un dispozitiv care nu a fost creat niciodată.

Dacă dispozitivul lipsește, doar gazda sau furnizorul îl pot activa. Un alt plan este adesea mai ieftin decât un fir de suport deschis care durează o săptămână. Confirmați acest lucru înainte de a citi măcar o linie din logul OpenVPN. Altfel veți petrece seara reglând reguli care nu vor vedea niciodată un pachet.

Decideți ce face MASQUERADE pe această interfață

Pe o mașină virtuală obișnuită regula obișnuită de ieșire este POSTROUTING MASQUERADE din interfața principală. Într-un container OpenVZ dispozitivul vizibil este adesea venet0, o interfață virtuală administrată de gazdă, nu o placă de rețea rutată, iar MASQUERADE nu se comportă întotdeauna acolo cum presupun tutorialele.

Forma fezabilă este o traducere explicită către adresa pe care clienții o ating deja, cu redirecționarea permisă în ambele sensuri. Înlocuirea pool-ului din configurația serverului contează la fel de mult ca înlocuirea adresei. Citiți fiecare linie înainte de a o lipi.

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Fără regulile de redirecționare traducerea are loc în continuare, iar nucleul refuză în continuare să redirecționeze. Această combinație produce starea confuză în care contoarele de pe regula NAT cresc în timp ce clientul nu primește nimic. Cele două linii FORWARD trebuie să stea și ele înaintea oricărei reguli drop largi din același lanț. Ordinea face parte din configurație, nu este un detaliu de implementare.

Limitați regula la un pool și o interfață

Al doilea simptom are altă cauză: o regulă POSTROUTING fără restricție de sursă și fără restricție de ieșire. O astfel de regulă rescrie fiecare pachet care părăsește gazda.

Serviciile care depind de sursa originală se comportă atunci greșit. Un server web din spatele unui proxy local poate înceta să răspundă, iar repornirea nu schimbă nimic pentru că regula este încă pe traseu. Este afectat și traficul pe care gazda îl trimite către propria adresă publică, de aceea defecțiunea poate părea o problemă de DNS sau de certificat, nu de firewall. Regula a fost aproape sigur adăugată pentru a repara primul simptom.

Soluția este să restrângeți potrivirea la pool-ul tunelului și la interfața de ieșire, apoi să adăugați o regulă pe pool în loc să lărgiți o singură regulă pentru mai multe.

Faceți regulile persistente și aflați cine le mai deține

Regulile adăugate manual dispar la repornire, așa că salvați-le cu iptables-save sau administrați-le prin netfilter-persistent acolo unde este instalat. Confirmați că restaurarea rulează înainte ca OpenVPN să pornească. Apoi reporniți o dată intenționat, în loc să descoperiți golul în timpul unui incident.

Pe o gazdă cu containere, confirmați și că fișierul de persistență se află în stocare de container care se poate scrie și că furnizorul nu înlocuiește filtrarea la pornire. Unele platforme administrează politica în afara containerului, unde regulile locale fie sunt ignorate, fie se ciocnesc cu cele ale gazdei.

Verificați cu contoare și cu un singur flux capturat

De la un client conectat, verificați adresa publică raportată de un serviciu extern. Dacă se potrivește cu adresa serverului, traducerea funcționează; dacă nu, pachetul iese pe alt traseu sau nu iese deloc. Apoi testați atât un serviciu găzduit pe server, cât și unul pe internetul public, pentru că urmează trasee diferite prin același set de reguli.

Pe server, citiți contoarele de pachete de pe regulile NAT și FORWARD cu iptables -t nat -L -v -n și urmăriți un flux într-o captură. Dacă adresa clientului apare în captură și nu urmează niciun răspuns, golul este pe traseul de întoarcere sau în filtrarea furnizorului, nu în profilul clientului. Comparați sursa capturată cu adresa către care traduce regula, pentru că o nepotrivire înseamnă că o altă regulă s-a potrivit prima. Un singur flux observat rezolvă mai mult decât o pagină de citire a configurației.

Țineți pool-ul, adresa tradusă și numele interfeței împreună în registrul de modificări. O regulă corectă pentru un pool traduce greșit următorul.