sshuttle față de un VPN complet: ce acoperă de fapt metoda sa

sshuttle este ales pentru că SSH funcționează deja și criptografia pare familiară, iar acest raționament sare peste singura întrebare care decide dacă se potrivește. Ce pachete părăsesc mașina, ce cont le poartă pe cealaltă parte și cât privilegiu local cere instrumentul. Aceste trei răspunsuri diferă în funcție de metoda de redirecționare, așa că o configurație care funcționează pentru o aplicație poate eșua în tăcere pentru următoarea. Prezentarea de mai jos începe cu protocolul de care aplicația are într-adevăr nevoie.

Începeți cu protocolul de care are nevoie aplicația

Suportul pentru protocoale în sshuttle 2.0 depinde de metoda pe care o alegeți. Metodele NAT și nft din Linux gestionează TCP și DNS, iar TPROXY adaugă UDP general. Fiecare platformă și metodă are propriile limite, iar macOS interceptează printr-un mecanism complet diferit. Notați versiunea instalată, metoda aleasă și protocoalele de care are nevoie aplicația înainte de a alege ceva.

O cerere TCP funcțională dovedește deci foarte puțin despre o aplicație UDP sau despre fiecare interogare DNS. sshuttle tratează TCP și ca fluxuri în loc să tuneleze pachete IP întregi, așa că o concluzie despre debit împrumutată de la un VPN obișnuit nu se transferă. Comparați mecanismul pe care îl rulați efectiv cu sarcina pe care o aveți efectiv.

De ce are nevoie clientul local

Aranjamentul documentat al clientului cere root sau sudo, pentru că instalează reguli locale de interceptare în loc să creeze o interfață de tunel. Acest singur fapt schimbă povestea securității: un proces cu acel privilegiu poate redirecționa traficul întregii mașini, nu doar al unei aplicații. Tratați privilegiul ca parte a proiectării și nu ca detaliu de instalare.

Confirmați ce reguli a instalat instrumentul și că dispar la ieșire. O sesiune care se prăbușește și lasă reguli de interceptare poate trimite traficul într-o gaură neagră mult după ce operatorul crede că legătura a dispărut, iar simptomul arată ca o defecțiune de rețea, nu ca o regulă rămasă.

sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip route

Prima comandă este forma unei invocări tipice, cu prefixul de care aveți într-adevăr nevoie. A doua arată ce a instalat instrumentul, iar a treia confirmă că nu a apărut nicio interfață de tunel, ceea ce este rezultatul așteptat pentru această proiectare.

Ce rulează partea îndepărtată

Partea îndepărtată este un cont SSH autorizat plus un mediu de ajutor Python compatibil. O autentificare reușită într-un shell restricționat nu acordă automat permisiunea de a rula acel ajutor, iar un cont care poate rula ajutorul nu ajunge automat la fiecare serviciu țintă. Ambele fapte aparțin cererii de acces și nu notițelor de depanare.

Protejați verificarea identității gazdei și autentificarea contului. Acceptarea unei chei de gazdă necunoscute pentru ca prima conexiune să funcționeze elimină verificarea că partea îndepărtată este mașina dorită, iar aici cântărește mai mult decât la o redirecționare pentru un singur scop.

Limitați contul de la distanță la serviciile de care are nevoie fluxul de lucru și negociați acest domeniu cu cei care operează gazda. Ei fac parte din relația de încredere, iar nicio setare de pe partea clientului nu schimbă asta.

Unde se află granița de încredere

Redirecționarea unei conexiuni API private prin SSH nu autorizează fiecare operație API. TLS-ul aplicației și autentificarea în aplicație se aplică în continuare, iar instrumentul nu poate face sigur un serviciu fără autentificare. Nici un salt suplimentar de la gazda de la distanță nu este automat același segment protejat ca canalul SSH, pentru că acea a doua conexiune urmează orice politică are gazda de la distanță.

Scrieți granița într-o singură propoziție: traficul către aceste prefixe iese prin acest cont pe acea gazdă. Dacă propoziția are nevoie de un paragraf de excepții, proiectarea face mai mult decât susține documentația ei și merită o a doua privire înainte de a ajunge în producție.

Dovediți-o pentru fiecare protocol, apoi alegeți instrumentul

Testați fiecare protocol necesar cu o cerere inofensivă, inclusiv calea resolverului și familiile de adrese pe care le folosește aplicația. Includeți o deconectare în test, ca comportamentul de eșec permis al aplicației să devină un rezultat cunoscut și nu o surpriză în timpul unui incident. O sesiune care redirecționa corect cât timp era activă nu spune nimic despre ce se întâmplă când cade.

Pentru câteva servicii numite explicit, o redirecționare locală obișnuită este mai ușor de deținut și de auditat. Pentru traficul aplicațiilor care se potrivește metodei sale, sshuttle oferă o cale de mijloc legitimă. Când cerința este conectivitate IP largă, o proiectare VPN este răspunsul onest, iar alegerea urmează acoperirea și responsabilitatea operațională și nu un clasament al algoritmilor de criptare.