Uelekezaji wa sera dhidi ya SOCKS: tabaka gani hufanya proksi kweli

Umeongeza njia ya sera inayotuma trafiki ya mteja wa VPN kwa mwenyeji anayeendesha kisikilizaji cha SOCKS kwenye lango 1080. Pakiti zinafika, kisikilizaji hakiandiki kitu, na muunganisho unabaki kining'inia. Njia haina tatizo: mruko unaofuata huchagua pakiti inakwenda wapi, na SOCKS ni mazungumzo ambayo mteja lazima aanzishe. Linganisha miundo mitatu ambayo watu kwa kawaida wanamaanisha wanapotuma trafiki kupitia proksi, na itakuwa wazi ni sehemu gani inayokosekana katika usanidi wako.

Uelekezaji, DNAT na SOCKS hubadilisha mambo tofauti

Njia ya sera huandika upya uamuzi wa tabaka 3. Mistari miwili inatosha kutuma trafiki ya mteja mmoja kwa mruko unaofuata uliochaguliwa:

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

Baada ya hapo kernel humkabidhi pakiti 10.50.0.2, wakati lengo la awali likiwa bado kichwani mwa IP. Ikiwa 10.50.0.2 ni kipanga njia, husambaza pakiti. Ikiwa ni mwenyeji mwenye daemon wa SOCKS kwenye 1080, pakiti haijaelekezwa kwa kitu chochote kinachoweza kuipokea, na DNAT kwenye lango 1080 pia haisaidii, kwa sababu pakiti iliyotafsiriwa bado hubeba mzigo wa awali wa programu badala ya salamu ya SOCKS.

SOCKS5 huanza na baiti ya toleo, orodha ya mbinu, ubadilishanaji wa uthibitishaji na ombi linalotaja lengo. Hiyo ni data ya programu. Hakuna kiingilio cha uelekezaji au lengo la netfilter kinachoitengeneza, na hilo ni linganisho katika mstari mmoja: uelekezaji huchagua njia, SOCKS huomba seva ifanye muunganisho wa pili.

Kisa cha kwanza: programu yenyewe inaweza kuzungumza SOCKS

Wakati programu ina mpangilio wa proksi, hii ni njia fupi zaidi na haihitaji mabadiliko ya kernel. Ielekeze kwa kisikilizaji, toa taarifa za kuingia ikiwa seva itaziomba, na uamue kama majina hutatuliwa kienyeji au hupewa proksi. Kwenye curl hizi ni bendera tofauti, na tofauti ni muhimu wakati lengo linatatuliwa kutoka upande wa proksi pekee:

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

Programu zinazopuuza vigeu vya mazingira vya proksi, au zinazofungua soketi mbichi, haziwezi kusaidiwa kwa njia hii. Vivinjari na zana nyingi za HTTP ziko sawa; mteja wa mchezo, daemon wa barua au faili binary yoyote ya muuzaji kwa kawaida hayuko sawa. Mpaka ni kwa kila programu na kila itifaki, ndiyo sababu chaguo hili ni bora kwa majaribio na dhaifu kama jibu kwa VPN yote.

Kisa cha pili: kipatanishi kinachobadilisha mikondo ya IP kuwa vikao vya proksi

Kwa programu zinazoshindwa kuzungumza SOCKS, ubadilishaji lazima utokee katika kitu kinachomaliza trafiki ya IP na kufungua vikao vya proksi kwa niaba yao. Sehemu hiyo inamiliki kiolesura cha handaki, inakubali mikondo iliyochaguliwa na uelekezaji wa sera, hufanya makubaliano ya mkono ya SOCKS kwa kila mmoja na kuunda upya majibu. Njia huelekeza trafiki kwake; kipatanishi ndicho kinachounda kikao.

Soma nyaraka zake kabla ya kukikabidhi subnetwork nzima. Vipatanishi vingi hubeba TCP vizuri na hushughulikia UDP kupitia ushirika wa UDP wa SOCKS5 pekee, na hakuna kimoja kinachobadilisha ICMP kuwa trafiki ya proksi, kwa hivyo ping iliyofanikiwa haisemi kitu kuhusu njia ya proksi. DNS ni mtego mwingine: ikiwa kipatanishi hutatua majina kienyeji, rekodi za ndani pekee hutatuliwa kuwa jibu lisilo sahihi, au kuwa hakuna kitu.

Kuzuia mizunguko ni maelezo ya uendeshaji yanayouma. Miunganisho ya kipatanishi yenyewe kwa seva ya SOCKS haipaswi kuelekezwa tena ndani ya kipatanishi, kwa hivyo trafiki yake inahitaji msamaha katika kanuni au anwani maalum ya chanzo. Ukikosea hivi, kikao cha proksi kitajaribu kujifanyia proksi yenyewe.

Kisa cha tatu: mwenyeji kwa kweli ni lango lililoelekezwa

Wakati mwingine usanidi unaofanya kazi hauna SOCKS kabisa. Mwenyeji wa mbali husambaza pakiti au kuzifanyia NAT, na kanuni ya msingi wa chanzo huchagua tu kama njia ya kutoka. Muundo huo ni halali, na unaeleza kwa nini usanidi ulionakiliwa hufanya kazi kwenye mtandao mmoja na kushindwa kwenye mwingine: kanuni ni ile ile, sehemu inayokosekana ni huduma ya usambazaji upande wa pili.

Kisa hivyo vitatu hutenganishwa haraka. Angalia kile kinachosikiliza kweli, kisha uangalie baiti za kwanza zinazofika kwa mwenyeji:

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

Baiti ya kwanza ya mzigo wa mteja halisi wa SOCKS ni 0x05, toleo lililo kwenye salamu. Ikiwa nakala inaonyesha data ya awali ya programu badala yake, hakuna daemon wa SOCKS atakayejibu, kwa sababu mazungumzo hayakuanza kamwe. Ikiwa hakuna kinachosikiliza kwenye 1080, mwenyeji ni lango, na swali linakuwa kama husambaza na kama kuna njia ya kurudi.

Chagua tabaka kwa maswali manne

Je, programu ina mpangilio wa proksi? Itumie na usimame hapo. Je, trafiki ina UDP au ICMP ambazo lazima ziendelee kuishi? Ni lango lililoelekezwa au la NAT pekee hubeba ICMP, na UDP inahitaji ushirika wa SOCKS5 ambao pande zote mbili zinaunga mkono. Je, kila mchakato kwenye mashine, pamoja na yale huwezi kusanidi, lazima ufunikwe? Basi unahitaji kipatanishi kinachomiliki kiolesura na kumaliza mikondo. Je, unaweza pia kuchukua uelekezaji wake, DNS na misamaha ya kuzuia mizunguko? Ikiwa sivyo, lango la kawaida litagharimu kidogo kuendesha.

Tofauti moja inafaa kuwekwa wazi. Chaguo la socks-proxy la mteja wa VPN lenyewe linaeleza jinsi muunganisho wa handaki la nje unafika kwa seva yake, na halisemi kitu kuhusu kubadilisha mikondo ya ndani ya mteja. Mambo haya mawili huchanganywa kila mara katika tiketi moja. Amua ni uhusiano gani unahitaji kabla ya kugusa njia.