Lasă un client OpenVPN să facă SSH către altul fără a deschide pool-ul

Un client trebuie să ajungă la serviciul SSH al altui client, iar restul pool-ului trebuie să rămână la fel de izolat ca acum. Comutatorul tentant este client-to-client, care activează accesul între egali pentru toți deodată și încredințează decizia către OpenVPN în locul kernelului. Un răspuns mai îngust ține comutatorul oprit și lasă rutarea și firewall-ul serverului însuși să ducă exact un flux.

Mecanismul contează mai mult decât textul regulii, pentru că cele două abordări pun pachetul în locuri diferite. Să știi pe care ai ales-o explică atât regula care pare să nu facă nimic, cât și egalul care se conectează fără ea.

Unde mută client-to-client pachetul

Cu client-to-client activat, serverul retransmite un pachet de la egal în interior în loc să îl trimită înapoi prin dispozitivul de tunel, astfel încât pachetul nu ajunge niciodată pe calea de transfer a kernelului. Acest lucru este comod și înseamnă și că firewall-ul tău nu vede niciodată fluxul pe care ar trebui să îl supravegheze. Lasă opțiunea oprită și serverul rutează pachetul înapoi prin aceeași interfață, ceea ce îl pune în fața netfilter. Aceeași interfață la intrare, aceeași la ieșire, iar lanțul FORWARD are votul.

Schimbul este explicit: câștigi un punct de politică și preiei munca de rutare și transfer pe care o făcea scurtătura pentru tine. Acea muncă este mică pentru un singur flux și crește cu fiecare excepție pe care o adaugi. Numără excepțiile acum, pentru că în setul de reguli trăiește de fapt politica între egali.

Calea pe care o urmează de fapt un pachet de la egal

Presupune un serviciu Linux Community OpenVPN 2.6, procesare TUN în spațiul utilizatorului în loc de DCO, topologie de subrețea, tun0 și un pool de 10.44.0.0/24 cu clientul A la 10.44.0.21 și clientul B la 10.44.0.37. Cu topologie de subrețea, adresa și masca primite de A acoperă deja pool-ul, așa că A trimite pachetul către dispozitivul de tunel fără a avea nevoie de o rută împinsă suplimentară. Verifică ruta efectivă pe A în loc să presupui una.

Pe server, pachetul sosește adresat către B, care nu este o adresă locală, deci este transferat. Transferul IPv4 trebuie să fie activat pentru ca acest lucru să se întâmple, iar căutarea rutei trebuie să trimită pachetul înapoi prin tun0. Firewall-ul vede așadar un flux transferat cu aceeași interfață pe ambele părți, iar acesta este detaliul pe care majoritatea seturilor de reguli îl ratează. Aici nu este nevoie de traducere a sursei, iar păstrarea intactă a adresei lui A este ceea ce îi permite lui B să aplice propria regulă bazată pe sursă.

Două reguli pe server, în această ordine

Trei reguli poartă întreaga permisiune: transferul, excepția perechii și o aruncare implicită pentru perechea de tunel. Regula de acceptare numește perechea și serviciul, așa că permisiunea supraviețuiește unui pool care crește. Plaseaz-o înaintea oricărei respingeri generale a traficului tunel-la-tunel, pentru că prima potrivire câștigă:

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROP

Acele comenzi sunt ilustrative și aparțin mecanismului pe care gazda ta îl folosește pentru a păstra regulile; o inserare în timpul execuției dispare la următoarea pornire. Regula cu stare este cea care permite răspunsurilor lui B și strângerii de mână TCP să revină fără o a doua acceptare oglindită.

Verifică apoi contoarele, nu lista de reguli, pentru că o regulă care nu se potrivește niciodată arată identic cu una care funcționează. Dacă contoarele rămân la zero, pachetul nu urmează calea pe care crezi.

Ce trebuie să mai permită B

B rulează serviciul SSH, deci B decide dacă ceva ascultă pe adresa tunelului și dacă firewall-ul propriu al gazdei acceptă sursa. O permisiune de rețea pe server nu este permisiune pentru niciun cont de pe B, iar verificarea cheii gazdei și autentificarea utilizatorului se aplică în continuare ca din orice alt loc.

Testează mai întâi cazul pozitiv: o conexiune SSH nouă de la A la adresa tunelului lui B, acceptată cu cheia de gazdă așteptată. Apoi testează un alt egal sau un alt port și confirmă că este refuzat, pentru că o permisiune care permite totul în tăcere este de nedistins de una care funcționează până când contează. Ambele jumătăți ale acelui test sunt necesare, iar a doua este cea pe care oamenii o sar.

Notează adresele atribuite, rutele efective pe ambii clienți și regulile exacte pe server și pe B. Un ping reușit către gateway sau un port deschis pe server nu demonstrează nimic din toate acestea, fiindcă ambele pot fi adevărate în timp ce transferul între egali este încă blocat. Scrie acele numere cât timp tunelul este ridicat, pentru că adresa pe care o primește un client după reconectare poate fi alta.