Nakikinig ang Redsocks sa loopback pero hindi kailanman dumarating ang trapikong VPN

Bumangon ang isang tunel, nakakapag-ping ang kliyente sa gateway, at namamatay ang bawat kahilingang web sa landas ng proxy. Tumatakbo ang prosesong redsocks at nakikinig ang port nito, kaya mukhang malusog ang serbisyo mula sa gateway mismo. Ang nabibigo ay ang hakbang ng paghahatid: ang packet na itinuro muli mula sa tunel ay hindi lumalapag sa socket na inilunsad mo. Dapat magtugma ang address ng pagkakatali at ang target ng pagtuturo muli, at karaniwang isa lamang sa kanila ang sinusuri.

Saan talaga lumalapag ang itinurong muli na packet

Gumagamit ang transparent na proxy sa isang gateway ng REDIRECT sa talahanayang nat sa PREROUTING upang muling isulat ang destinasyon ng papasok na koneksyon patungo sa lokal na port. Ang naisulat na destinasyon ay lokal na address na nakikita mula sa interface kung saan dumating ang packet, hindi ang loopback address ng prosesong inilunsad sa ibang lugar. Ang tagapakinig na nakatali lamang sa 127.0.0.1 ay tumatanggap ng koneksyong lokal na dati sa host, at ito mismo ang kasong patuloy na gumagana habang nabibigo ang trapiko ng tunel. Ang sariling loopback ng kliyente ay ikatlong address at hindi kailanman target ng tuntunin ng gateway.

Kaya bago hawakan ang mga kredensyal sa itaas na antas, itatag ang dalawang katotohanan: sa aling lokal na address muling nagsusulat ang tuntunin, at sa aling address nakatali ang socket ng proxy.

Basahin ang tagapakinig at ang tuntunin ng pagtuturo muli nang magkasama

I-print ang talahanayan ng socket at ang mga tuntuning nat sa isang pagdaan, dahil ang tuntuning tumuturo sa port na walang nagmamay-ari ay mukhang kapareho ng tuntuning tumuturo sa maling address. Ipinapakita ng sudo ss -ltnp | grep redsocks ang address ng pagkakatali at ang prosesong may-ari. Ipinapakita ng sudo iptables -t nat -S PREROUTING ang target ng REDIRECT, at ipinapakita ng sudo iptables -t nat -L PREROUTING -v -n kung may tumugma rito.

Ang paglundag sa isang chain ng gumagamit na tinatawag na REDSOCKS ay walang naiaabot maliban kung umiiral ang chain na iyon at nagdadala ng mga inilaan na pagbubukod at ng aksyong REDIRECT. Basahin ang chain na nilulundagan nito gamit ang sudo iptables -t nat -S REDSOCKS sa halip na ipagpalagay na ang pangalan ang gumagawa ng trabaho.

Pagkatapos ay ihambing ang dalawang halaga. Kung ang tuntunin ay nagtuturo muli sa address ng gateway sa port 12345 at iniuulat ng tagapakinig ang 127.0.0.1:12345, ipinapaliwanag ng pagkakaiba ang kabiguan nang walang karagdagang diagnosis.

Itali nang makitid, pagkatapos ay limitahan kung ano ang makakaabot dito

Ang halimbawang konfigurasyon sa itaas na antas ay naglalagay ng tagapakinig sa loopback para sa magandang dahilan: tumatanggap ang transparent na proxy ng koneksyon sa ngalan ng sinumang makakaabot dito. Ang pagpalit ng pagkakatali sa 0.0.0.0 ay nag-aayos ng paghahatid at sabay na nagbubukas ng port sa bawat interface, na isang pagbabago sa seguridad, hindi neutral na pagkukumpuni. Mas mainam na itali sa partikular na lokal na address na pinupuntirya ng pagtuturo muli, at panatilihing sarado ang port sa mga interface na hindi pinagkakatiwalaan. Kung hindi maiiwasan ang mas malawak na pagkakatali, magdagdag ng tuntunin ng firewall sa host na nagpapahintulot lamang sa saklaw ng pinagmulan ng tunel at sa sariling lokal na trapiko ng gateway.

Ang pagbukas ng port sa pampublikong interface ay hindi kailanman kailangan para sa itinurong muli na trapikong VPN, dahil nagtatapos ang koneksyon nang lokal pagkatapos ng muling pagsulat. Huwag ilantad ang proxy sa internet upang gumana ang lokal na pagtuturo muli.

Patunayan ito gamit ang bagong koneksyon mula sa kliyente

Subukan mula sa tunay na kliyente ng VPN gamit ang bagong koneksyong TCP, hindi mula sa shell sa gateway. Sinasanay ng curl -sS -o /dev/null -w '%{http_code}\n' http://example.com sa kliyente ang itinurong muli na landas mula simula hanggang wakas.

Pagkatapos ay tiyakin na ang direktang koneksyon sa tagapakinig mula sa hindi pinagkakatiwalaang network ay tinatanggihan pa rin, at ang sariling pataas na koneksyon ng proxy ay hindi muling nahuhuli ng parehong tuntunin. Ang paulit-ulit na paghuli ay lumilitaw bilang proxy na kumokonekta sa sarili at hindi kailanman tinatapos ang kahilingan. Idagdag ang destinasyon ng proxy sa hanay ng pagbubukod, o markahan ang mga palabas na packet nito upang laktawan sila ng chain.

Sa huli, tandaan kung ano ang hindi saklaw ng landas na ito. Ang karaniwang TCP na pagtuturo muli ng redsocks ay hindi ginagawang trapikong SOCKS ang UDP, QUIC o DNS, at ang mga pribadong destinasyon ay karaniwang nangangailangan ng malinaw na pagbubukod. Ang matagumpay na lokal na pagsubok ay nagpapatunay lamang ng landas ng loopback na hindi kailanman naging problema.