Policy routing kumpara sa SOCKS: aling layer ang tunay na nagpo-proxy ng trapiko

Nagdagdag ka ng policy route na nagpapadala ng trapiko ng isang VPN client sa host na nagpapatakbo ng SOCKS listener sa port 1080. Dumarating ang mga packet, walang itinatala ang listener, at nakabitin ang koneksyon. Wala namang mali sa ruta: pinipili ng susunod na hop kung saan pupunta ang packet, at ang SOCKS ay usapan na dapat simulan ng client. Ihambing ang tatlong arkitektura na karaniwang ibig sabihin ng mga tao kapag nagpapadala ng trapiko sa proxy, at magiging malinaw kung aling bahagi ang kulang sa iyong setup.

Binabago ng routing, DNAT at SOCKS ang magkaibang bagay

Ang policy route ay nagsusulat muli ng desisyon sa layer 3. Dalawang linya lang ang sapat para ipadala ang trapiko ng isang client sa napiling susunod na hop:

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

Pagkatapos nito, ibinibigay ng kernel ang packet sa 10.50.0.2 habang nasa IP header pa rin ang orihinal na destinasyon. Kung ang 10.50.0.2 ay router, ipinapadala nito ang packet. Kung ito ay host na may SOCKS daemon sa 1080, hindi naka-address ang packet sa anumang kayang tumanggap nito, at hindi rin nakakatulong ang DNAT sa port 1080, dahil ang naisaling packet ay nagdadala pa rin ng orihinal na payload ng app sa halip na SOCKS greeting.

SOCKS5 ay nagsisimula sa version byte, listahan ng method, palitan ng authentication at request na nagpapangalan sa destinasyon. Data ng app iyon. Walang routing entry at walang netfilter target ang gumagawa nito, at iyon ang paghahambing sa isang linya: pumipili ng landas ang routing, hinihiling ng SOCKS sa server na gumawa ng ikalawang koneksyon.

Unang kaso: kayang magsalita ng SOCKS ng app mismo

Kapag may proxy setting ang programa, ito ang pinakamaikling landas at hindi nito kailangan ng pagbabago sa kernel. Ituro ito sa listener, magbigay ng credentials kung hinihingi ng server, at magpasya kung lokal na nire-resolve ang mga pangalan o ipinapasa sa proxy. Sa curl, magkaibang flag ang mga ito, at mahalaga ang pagkakaiba kapag mula sa panig ng proxy lang nire-resolve ang destinasyon:

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

Ang mga app na binabalewala ang proxy environment variables, o nagbubukas ng raw socket, ay hindi matutulungan sa ganitong paraan. Maayos ang mga browser at karamihan ng HTTP tool; ang game client, mail daemon o arbitraryong binary ng vendor ay karaniwang hindi. Ang hangganan ay kada app at kada protocol, kaya napakahusay ang opsyong ito para sa pagsubok at mahina bilang sagot para sa buong VPN.

Ikalawang kaso: adapter na nagko-convert ng IP flow sa proxy session

Para sa mga program na hindi kayang magsalita ng SOCKS, kailangang mangyari ang conversion sa isang bagay na nagtatapos ng IP traffic at nagbubukas ng proxy session sa ngalan nila. Pag-aari ng component na iyon ang tunnel interface, tinatanggap nito ang mga flow na pinili ng policy routing, ginagawa ang SOCKS handshake para sa bawat isa at muling binubuo ang mga tugon. Itinuturo ng ruta ang trapiko patungo rito; ang adapter ang gumagawa ng session.

Basahin ang dokumentasyon nito bago ipagkatiwala ang isang buong subnet. Maraming adapter ang mahusay magdala ng TCP at pinoproseso ang UDP sa pamamagitan lamang ng SOCKS5 UDP association, at wala sa kanila ang nagko-convert ng ICMP sa proxy traffic, kaya walang sinasabi ang matagumpay na ping tungkol sa proxy path. Ang DNS ang isa pang patibong: kung lokal na nire-resolve ng adapter ang mga pangalan, ang internal-only na record ay nire-resolve sa maling sagot, o sa wala.

Ang pag-iwas sa loop ang detalyeng pang-operasyon na kumakagat. Ang sariling koneksyon ng adapter sa SOCKS server ay hindi dapat i-routing pabalik sa adapter, kaya kailangan ng trapiko nito ng exception sa rule o nakalaang source address. Kapag nagkamali rito, susubukan ng proxy session na i-proxy ang sarili nito.

Ikatlong kaso: ang host ay talagang naka-rutang gateway

Minsan walang SOCKS sa gumaganang setup. Ipinapadala ng remote host ang mga packet o ginagawa itong NAT, at pinipili lang ito ng rule na nakabatay sa source bilang labasan. Lehitimo ang disenyong iyon, at ipinapaliwanag nito kung bakit gumagana ang kinopyang configuration sa isang network at nabigo sa iba: magkapareho ang rule, ang kulang na bahagi ay serbisyo ng pagpapasa sa kabilang panig.

Mabilis na naghihiwalay ang tatlong kaso. Suriin kung ano ang tunay na nakikinig, pagkatapos tingnan ang mga unang byte na nakakarating sa host:

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

Ang unang payload byte ng tunay na SOCKS client ay 0x05, ang version sa greeting. Kung ang capture ay nagpapakita ng orihinal na app data sa halip, walang SOCKS daemon ang sasagot, dahil hindi kailanman nagsimula ang negosasyon. Kung walang nakikinig sa 1080, ang host ay gateway, at ang tanong ay kung nagpapasa ito at kung may return path.

Piliin ang layer gamit ang apat na tanong

May proxy setting ba ang programa? Gamitin ito at huminto doon. May UDP o ICMP ba ang trapiko na dapat mabuhay? Ang naka-rutang gateway o NAT gateway lang ang nagdadala ng ICMP, at kailangan ng UDP ng SOCKS5 association na sinusuportahan ng dalawang dulo. Kailangan bang masakop ang bawat proseso sa makina, kasama ang mga hindi mo ma-configure? Kung gayon, kailangan mo ng adapter na nagmamay-ari ng interface at nagtatapos ng flow. Kaya mo bang akuin din ang routing, DNS at mga exception sa pag-iwas sa loop nito? Kung hindi, mas mura pang patakbuhin ang simpleng gateway.

May isang pagkakaibang dapat panatilihing malinaw. Ang sariling socks-proxy option ng VPN client ay naglalarawan kung paano naaabot ng panlabas na tunnel connection ang server nito, at walang sinasabi tungkol sa pag-convert ng panloob na flow ng client. Palaging napagkakamalang magkapareho sa iisang ticket. Magpasya kung aling ugnayan ang kailangan mo bago hawakan ang isang ruta.