Rutare bazată pe politici versus SOCKS: ce strat face de fapt proxying

Ați adăugat o rută de politică ce trimite traficul unui client VPN către un host care rulează un ascultător SOCKS pe portul 1080. Pachetele ajung, ascultătorul nu înregistrează nimic, iar conexiunea rămâne blocată. Ruta nu are nimic greșit: următorul salt alege unde merge un pachet, iar SOCKS este o conversație pe care clientul trebuie să o înceapă. Comparați cele trei arhitecturi la care oamenii se referă de obicei când trimit trafic printr-un proxy, și devine clar ce piesă lipsește din configurația dumneavoastră.

Rutarea, DNAT și SOCKS schimbă lucruri diferite

O rută de politică rescrie o decizie de strat 3. Două linii sunt suficiente pentru a trimite traficul unui client către un următor salt ales:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

După aceea, nucleul predă pachetul către 10.50.0.2, cu destinația originală încă în antetul IP. Dacă 10.50.0.2 este un router, acesta redirecționează pachetul. Dacă este un host cu un demon SOCKS pe 1080, pachetul nu este adresat către nimic ce l-ar putea accepta, iar DNAT către portul 1080 nici nu ajută, pentru că un pachet tradus încă poartă încărcătura originală a aplicației în locul unui salut SOCKS.

SOCKS5 începe cu un octet de versiune, o listă de metode, un schimb de autentificare și o cerere care numește destinația. Acelea sunt date de aplicație. Nicio intrare de rutare și nicio țintă netfilter nu le generează, și aceasta este comparația într-o singură linie: rutarea alege o cale, SOCKS cere unui server să facă o a doua conexiune.

Primul caz: aplicația poate vorbi SOCKS singură

Când programul are o setare de proxy, aceasta este calea cea mai scurtă și nu necesită nicio modificare în nucleu. Îndreptați-o spre ascultător, furnizați acreditări dacă serverul le cere, și decideți dacă numele sunt rezolvate local sau transmise proxy-ului. La curl acestea sunt steaguri diferite, iar diferența contează când destinația este rezolvată doar din partea proxy-ului:

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

Aplicațiile care ignoră variabilele de mediu pentru proxy, sau care deschid socketuri brute, nu pot fi ajutate astfel. Browserele și majoritatea instrumentelor HTTP sunt în regulă; un client de joc, un demon de poștă sau un binar arbitrar al unui furnizor de obicei nu. Granița este pe aplicație și pe protocol, de aceea această opțiune este excelentă pentru testare și slabă ca răspuns pentru întregul VPN.

Al doilea caz: un adaptor care convertește fluxurile IP în sesiuni de proxy

Pentru programele care nu pot vorbi SOCKS, conversia trebuie să aibă loc într-un ceva care termină traficul IP și deschide sesiuni de proxy în numele lor. Acea componentă deține o interfață de tunel, acceptă fluxurile selectate de rutarea pe politici, execută strângerea de mână SOCKS pentru fiecare dintre ele și reconstruiește răspunsurile. Ruta direcționează traficul către ea; adaptorul este ceea ce creează sesiunea.

Citiți documentația înainte de a-i încredința o întreagă subrețea. Multe adaptoare transportă bine TCP și tratează UDP doar printr-o asociere UDP SOCKS5, iar niciunul nu transformă ICMP în trafic de proxy, așa că un ping reușit nu spune nimic despre calea proxy. DNS este cealaltă capcană: dacă adaptorul rezolvă numele local, înregistrările doar interne se rezolvă la răspunsul greșit, sau la nimic.

Prevenirea buclelor este detaliul operațional care mușcă. Conexiunile proprii ale adaptorului către serverul SOCKS nu trebuie rutate înapoi în adaptor, așa că traficul lui are nevoie de o excepție în regulă sau de o adresă de sursă dedicată. Greșiți aici și sesiunea de proxy va încerca să facă proxy sieși.

Al treilea caz: hostul este de fapt un gateway rutat

Uneori configurația care funcționează nu conține deloc SOCKS. Hostul îndepărtat redirecționează pachete sau aplică NAT asupra lor, iar regula bazată pe sursă pur și simplu îl alege ca ieșire. Acel design este legitim și explică de ce o configurație copiată funcționează într-o rețea și eșuează în alta: regula este identică, piesa lipsă este un serviciu de redirecționare de cealaltă parte.

Cele trei cazuri se despart repede. Verificați ce ascultă efectiv, apoi uitați-vă la primii octeți care ajung la host:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

Primul octet de încărcătură al unui client SOCKS real este 0x05, versiunea din salut. Dacă captura arată în schimb date originale ale aplicației, niciun demon SOCKS nu va răspunde, pentru că negocierea nu a început niciodată. Dacă nimic nu ascultă pe 1080, hostul este un gateway, iar întrebarea devine dacă redirecționează și dacă există o cale de întoarcere.

Alegeți stratul cu patru întrebări

Programul are o setare de proxy? Folosiți-o și opriți-vă acolo. Traficul include UDP sau ICMP care trebuie să supraviețuiască? Doar un gateway rutat sau NAT transportă ICMP, iar UDP are nevoie de o asociere SOCKS5 pe care ambele capete o suportă. Fiecare proces de pe mașină trebuie acoperit, inclusiv cele pe care nu le puteți configura? Atunci aveți nevoie de un adaptor care deține interfața și termină fluxurile. Puteți prelua și rutarea, DNS-ul și excepțiile de prevenire a buclelor? Dacă nu, gateway-ul simplu va costa mai puțin de operat.

O distincție merită păstrată clară. Opțiunea socks-proxy proprie a unui client VPN descrie cum conexiunea tunelului exterior ajunge la serverul său și nu spune nimic despre conversia fluxurilor interne ale clientului. Cele două sunt confundate constant în același tichet. Decideți ce relație aveți nevoie înainte de a atinge o rută.