Politika enkursigado kontraŭ SOCKS: kiu tavolo efektive prokuras trafikon

Vi aldonis politikan itineron, kiu sendas la trafikon de VPN-kliento al gastiganto, kie funkcias SOCKS-aŭskultanto sur pordo 1080. La pakaĵoj alvenas, la aŭskultanto registras nenion, kaj la konekto pendas. Nenio malĝustas pri la itinero: sekva salto elektas, kien pakaĵo iras, kaj SOCKS estas konversacio, kiun kliento devas komenci. Komparu la tri arkitekturojn, kiujn homoj kutime celas, kiam ili sendas trafikon tra proksilo, kaj estos klare, kiu peco mankas en via agordo.

Enkursigado, DNAT kaj SOCKS ŝanĝas malsamajn aferojn

Politika itinero reskribas decidon de tavolo 3. Du linioj sufiĉas por sendi la trafikon de unu kliento al elektita sekva salto:

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

Post tio, la kerno transdonas la pakaĵon al 10.50.0.2, dum la origina celo ankoraŭ estas en la IP-kapo. Se 10.50.0.2 estas enkursigilo, ĝi plusendas la pakaĵon. Se ĝi estas gastiganto kun SOCKS-demono sur 1080, la pakaĵo ne estas adresita al io, kio povus akcepti ĝin, kaj ankaŭ DNAT al pordo 1080 ne helpas, ĉar tradukita pakaĵo ankoraŭ portas la originan aplikaĵan utilŝarĝon anstataŭ SOCKS-saluton.

SOCKS5 komenciĝas per versia bajto, listo de metodoj, interŝanĝo de aŭtentigo kaj peto, kiu nomas la celon. Tio estas aplikaĵaj datumoj. Nek enkursiga rikordo nek netfilter-celo generas ĝin, kaj jen la komparo en unu linio: enkursigado elektas vojon, SOCKS petas servilon fari duan konekton.

Kazo unu: la aplikaĵo mem povas paroli SOCKS

Kiam la programo havas proksilan agordon, tio estas la plej mallonga vojo kaj ĝi bezonas neniun kernan ŝanĝon. Direktu ĝin al la aŭskultanto, provizu akreditaĵojn se la servilo petas ilin, kaj decidu, ĉu nomoj estas solvitaj loke aŭ transdonitaj al la proksilo. Ĉe curl tiuj estas malsamaj flagoj, kaj la diferenco gravas kiam la celo solviĝas nur de la proksila flanko:

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

Aplikaĵoj, kiuj ignoras proksilajn medivariablojn aŭ malfermas krudajn ingojn, ne povas esti helpitaj ĉi tiel. Retumiloj kaj plej multaj HTTP-iloj estas en ordo; ludkliento, retpoŝta demono aŭ arbitra vendista binara dosiero kutime ne. La limo estas por ĉiu aplikaĵo kaj ĉiu protokolo, tial ĉi tiu opcio estas bonega por testado kaj malforta kiel respondo por la tuta VPN.

Kazo du: adaptilo, kiu konvertas IP-fluojn en proksilajn sesiojn

Por programoj, kiuj ne povas paroli SOCKS, la konverto devas okazi en io, kio finas IP-trafikon kaj malfermas proksilajn sesiojn nome de ili. Tiu komponanto posedas tunelan interfacon, akceptas la fluojn, kiujn elektis politika enkursigado, plenumas la SOCKS-manpremon por ĉiu el ili kaj rekonstruas la respondojn. La itinero direktas trafikon al ĝi; la adaptilo estas tio, kio kreas la sesion.

Legu ĝian dokumentaron antaŭ ol konfidi al ĝi tutan subreton. Multaj adaptiloj bone portas TCP kaj pritraktas UDP nur per SOCKS5 UDP-asocio, kaj neniu el ili transformas ICMP en proksilan trafikon, do sukcesa ping diras nenion pri la proksila vojo. DNS estas la alia kaptilo: se la adaptilo solvas nomojn loke, nur-internaj rikordoj solviĝas al malĝusta respondo, aŭ al nenio tute.

Bukla preventado estas la operacia detalo, kiu mordas. La propraj konektoj de la adaptilo al la SOCKS-servilo ne rajtas esti enkursigitaj reen en la adaptilon, do ĝia trafiko bezonas escepton en la regulo aŭ dediĉitan fontadreson. Faru tion malĝuste kaj la proksila sesio provos prokuri sin mem.

Kazo tri: la gastiganto estas fakte enkursigita enirejo

Foje la funkcianta agordo enhavas tute neniun SOCKS. La fora gastiganto plusendas pakaĵojn aŭ aplikas NAT al ili, kaj la font-bazita regulo simple elektas ĝin kiel eliron. Tiu dezajno estas legitima, kaj ĝi klarigas, kial kopiita agordo funkcias en unu reto kaj malsukcesas en alia: la regulo estas identa, la mankanta peco estas plusenda servo ĉe la alia flanko.

La tri kazoj apartiĝas rapide. Kontrolu, kio efektive aŭskultas, kaj poste rigardu la unuajn bajtojn, kiuj atingas la gastiganton:

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

La unua utilŝarĝa bajto de vera SOCKS-kliento estas 0x05, la versio en la saluto. Se la kaptaĵo montras anstataŭe originajn aplikaĵajn datumojn, neniu SOCKS-demono respondos, ĉar la intertraktado neniam komenciĝis. Se nenio aŭskultas sur 1080, la gastiganto estas enirejo, kaj la demando fariĝas, ĉu ĝi plusendas kaj ĉu ekzistas revena vojo.

Elektu la tavolon per kvar demandoj

Ĉu la programo havas proksilan agordon? Uzu ĝin kaj haltu tie. Ĉu la trafiko inkluzivas UDP aŭ ICMP, kiuj devas postvivi? Nur enkursigita aŭ NAT-enirejo portas ICMP, kaj UDP bezonas SOCKS5-asocion, kiun subtenas ambaŭ flankoj. Ĉu ĉiu procezo sur la maŝino devas esti kovrita, inkluzive tiujn, kiujn vi ne povas agordi? Tiam vi bezonas adaptilon, kiu posedas la interfacon kaj finas fluojn. Ĉu vi ankaŭ povas transpreni ĝian enkursigadon, DNS kaj esceptojn por bukla preventado? Se ne, la simpla enirejo kostos malpli por funkciigi.

Unu distingo indas esti tenata klare. La propra opcio socks-proxy de VPN-kliento priskribas, kiel la ekstera tunela konekto atingas sian servilon, kaj diras nenion pri konverto de la internaj klientaj fluoj. La du konstante konfuziĝas en la sama bileto. Decidu, kian rilaton vi bezonas, antaŭ ol tuŝi itineron.