Koneksyon na IPv6 lamang, serbisyong IPv4: hayaan ang SOCKS proxy na magtulay

Hindi mo kailangan ng address mula sa pamilya ng patutunguhan para maabot ito, hangga't may isang bagay sa landas na handang magpasa. Kumokonekta ang aplikasyon sa proxy, at nagbubukas ang proxy ng pangalawang koneksyon sa patutunguhan. Ito ay dalawang socket na may independiyenteng pamilya ng address, at wala sa alinman sa dalawang protocol ang nangangailangan na magtugma sila. Ito ay pagpapasa sa antas ng aplikasyon, hindi katutubong landas ng IPv4, at ang pagkakaibang ito ang nagtatakda kung ano ang gagana at ano ang hindi. Ang pagkalito sa dalawa ay kung bakit ang isang laptop ay inilalarawan na may koneksyong IPv4 samantalang ang tanging mayroon ito ay isang proxy.

Dalawang socket, dalawang pamilya ng address

Pinapangalanan ng kahilingang SOCKS5 ang patutunguhan sa isa sa tatlong anyo: literal na address na v4, literal na address na v6, o pangalang dapat lutasin ng proxy. Inilalarawan ng kahilingan kung saan dapat kumonekta ang proxy, hindi kung ano ang hitsura ng koneksyon ng kliyente sa proxy.

Basahin ang mga uri ng address na ito bilang tatlong independiyenteng pagpili sa loob ng isang mensahe. Ang proxy na maaabot sa pamamagitan ng IPv6 ay makakapagbukas ng socket ng patutunguhang IPv4 kapag may gumaganang labasan itong IPv4 at pinapayagan ng patakaran nito ang kahilingan. Ang espesipikasyon ng SOCKS5 ay tumutukoy sa mga ito nang walang anumang pagtukoy sa transportasyon ng kliyente.

Kontroladong halimbawa ng SSH

Kumuha ng SSH host na pinahihintulutan mong gamitin, na sumasagot sa IPv6 at makakaabot mismo sa serbisyong HTTPS na umiiral lamang sa v4. Naglalagay ang dynamic na forwarding ng OpenSSH ng lokal na tagapakinig ng SOCKS sa iyong makina habang dumadaan ang sesyon ng pag-login sa v6.

ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]

Ang host at account sa itaas ay mga halimbawa, at pinapanatili ng loopback binding ang tagapakinig sa kompyuter na ito. Huwag itong palitan ng wildcard binding upang makapagbahagi ang isang opisina ng proxy na walang pagpapatotoo. Umiiral ang ExitOnForwardFailure=yes upang tapusin ng nabigong forwarding ang sesyon sa halip na mag-iwan ng tahimik na utos na tumatakbo sa background.

Habang tumatakbo ang sesyon, ganito ang hitsura ng kahilingan:

curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/

Ang koneksyong loopback ay hindi landas ng internet na IPv4. Ang lumalabas sa iyong makina ay ang sesyon ng pag-login sa pamamagitan ng v6, at ang malayong panig ang nagbubukas ng socket ng patutunguhan. Ang anyong socks5h ay nagtatalaga rin ng paglutas ng pangalan sa panig na iyon, na mahalaga kapag walang sariling landas ng tagalutas ng IPv4 ang kliyente.

Ang aktwal na nakikita ng patutunguhan

Nakikita ng patutunguhan ang address ng labasan ng tagapasa. Walang address na pag-aari ng iyong laptop ang lumalabas doon. Ang listahan ng pinapayagang pinagmulan sa serbisyong iyon ay dapat magpangalan ng tagapasa. Itatalaga rin ng mga log nito ang trapiko sa tagapasa. Isulat ito sa talaan ng pagbabago bago ang pag-audit, dahil ang listahang pinapayagan na itinayo sa paligid ng mga address ng kliyente ay nabibigo sa unang kahilingan.

Ang tagapasa rin ang lugar kung saan nakikita ang dalawang kalahati ng usapan, na isang kapaki-pakinabang na katangian sa pag-diagnose at isang pasanin kung ang tagapasa ay ibinabahagi nang walang patakaran.

Ito ay hindi DNS64 o NAT64

Sumasagot ang DNS64 ng mga sintetikong rekord na pumapalit sa mga patutunguhang v4, at muling nagsusulat ang NAT64 ng mga packet sa isang naka-configure na landas. Wala sa dalawa ang naglalarawan ng nangyayari dito, kung saan nagtatapos ang isang usapan sa transportasyon at nagsisimula ang isa pa at walang sintetikong address ang nagpapaliwanag ng resulta. Kaya ang matagumpay na kahilingan ay walang sinasabi tungkol sa kung aling mga serbisyo ng pagsasalin ang pinapatakbo ng iyong provider, at maaaring magpatakbo ang proxy ng ordinaryong NAT sa sarili nitong labasan.

Ang parehong mekanismo ay maaaring umiral sa parehong network, kaya ilarawan ang tunay mong na-verify, hindi ang pinakamalapit na pakinggan.

Alamin ang saklaw bago ito pangakuan

Ang dynamic na forwarding ng OpenSSH ay nagdadala ng mga koneksyong TCP, hindi arbitraryong trapikong IP, kaya ang UDP, ICMP at anumang protocol na hindi pinapansin ang proxy ay nangangailangan ng ibang sinusuportahang disenyo. Panatilihin ang pag-verify ng key ng SSH host, ang mga paghihigpit sa forwarding ng server at ang pagpapatunay ng sertipiko ng HTTPS, dahil ang proxy ay karagdagang pinagkakatiwalaang kalahok, hindi dahilan para pahinain ang mga pagsusuri ng pagkakakilanlan. Kung ang layunin ay dalhin ang panlabas na transportasyon ng isang VPN sa pamamagitan ng proxy, i-verify na sinusuportahan ng dalawang dulo ang transportasyong iyon sa halip na ipagpalagay na anumang tagapakinig ng SOCKS ay makapagpasa nito.

Wala sa mga ito ang gumagawa sa kliyente na dual-stack, at wala sa mga ito ang kailangan. Ginagawa nitong maabot ng isang aplikasyon ang isang serbisyo sa pamamagitan ng isang tagapasa, na isang mas maliit na pag-aangkin at mas madaling i-verify.