Înainte de a înlocui IPsec cu Shadowsocks, scrieți sarcinile care lipsesc

Trei servicii, un tunel: o aplicație web, o bază de date și un folder partajat. Cineva propune înlocuirea IPsec cu Shadowsocks pentru că e mai simplu de administrat. Dezbaterea despre criptare care urmează ratează esența, fiindcă tunelul face mai multe sarcini deodată și doar una dintre ele ține de cifruri. Notați aceste sarcini înainte de a compara produse. Lista e scurtă, iar orice punct poate anula schimbarea.

Începeți cu modul în care traficul este capturat

Protocolul are două jumătăți. O componentă locală acceptă o conexiune, criptează un flux care începe cu adresa destinației și îl trimite către o componentă îndepărtată. Jumătatea îndepărtată deschide o conexiune către acea destinație și retransmite octeții. UDP urmează aceeași formă cu datagrame. Aceasta este redirecționare pentru fluxurile pe care le capturează și nu spune nimic despre fluxurile pe care nu le capturează. O aplicație care vorbește explicit un proxy este ușoară; tot restul are nevoie de un adaptor sau de reguli de rutare ca să fie capturat.

Documentați metoda de captare pentru fiecare aplicație înainte de a compara orice altceva. Traficul necapturat iese pe calea obișnuită și nimeni nu observă până când un serviciu nu se comportă altfel în afara biroului.

Numiți fiecare destinație și fiecare protocol

Jumătatea îndepărtată trebuie să ajungă la fiecare serviciu intern. O sesiune criptată funcțională către acel gazdă nu adaugă o rută de la el la baza de date și nu face numele interne să se rezolve pe client. Enumerați adrese, porturi și protocoale în loc să scrieți că LAN-ul este inclus.

Adăugați cazurile care strică proiectele ordonate: DNS intern, aplicații care ignoră setările de proxy și orice flux care trebuie pornit de la server către client. Fiecare are nevoie de o înțelegere explicită, nu de o presupunere.

Criptarea nu este autorizare

Metodele AEAD documentate din Shadowsocks oferă criptare autentificată, așa că a respinge întreaga familie ca nesigură este greșit. La fel de greșit este să lăsăm acest fapt să răspundă la întrebarea despre acces. Cineva trebuie să decidă cine ajunge la ce serviciu, cum se retrage accesul când o persoană pleacă, unde sunt păstrate secretele și care componentă impune granița. Un singur secret comun dă fiecărui deținător aceeași anvergură, iar plecarea unei persoane devine o rotație pentru toți.

Puneți configurația IPsec actuală la aceeași măsură. Eticheta ei nu dovedește că regulile sunt corecte, iar compararea unei versiuni lustruite a unui proiect cu o versiune vagă a celuilalt nu decide nimic.

Enumerați controalele care există astăzi pe ambele părți, apoi judecați cu ce lipsuri puteți trăi.

Numărați munca de operare

Fiecare înlocuire are nevoie de un responsabil pentru pachetele de client, actualizările serverului, rotația acreditărilor și tratarea defecțiunilor. Observați ce face fiecare aplicație când tunelul nu este disponibil: eșuează, reîncearcă pe calea locală sau așteaptă. Acel comportament vine din implementare, nu din numele protocolului.

Pentru o aplicație web, un proxy îngust poate fi suficient. Pentru acces la întreaga rețea cu permisiuni pe persoană, piesele suplimentare costă de obicei mai mult decât tunelul pe care l-au înlocuit.

Decizia nu este care produs sună mai sigur. Este care proiect termină sarcinile enumerate cu controale pe care echipa le va întreține cu adevărat.