Anslutning endast IPv6, tjänst på IPv4: låt en SOCKS-proxy bygga bron

Du behöver inte en adress i målets adressfamilj för att nå det, så länge något på vägen är villigt att vidarebefordra. Programmet ansluter till proxyn, och proxyn öppnar en andra anslutning till målet. Det är två sockets med oberoende adressfamiljer, och ingenting i något av protokollen kräver att de stämmer överens. Det är vidarebefordran på programnivå, inte en inbyggd IPv4-väg, och skillnaden avgör vad som kommer att fungera och vad som inte gör det. Att blanda ihop de två är hur en bärbar dator beskrivs som att ha IPv4-anslutning när allt den har är en proxy.

Två sockets, två adressfamiljer

En SOCKS5-begäran namnger målet i en av tre former: en litteral v4-adress, en litteral v6-adress eller ett namn som proxyn ska slå upp. Begäran beskriver var proxyn ska ansluta, inte hur klient-till-proxy-anslutningen ser ut.

Läs dessa adresstyper som tre oberoende val i ett enda meddelande. En proxy som nås över IPv6 kan öppna en socket till ett IPv4-mål när den har fungerande IPv4-utgång och policyn tillåter begäran. SOCKS5-specifikationen definierar dem utan någon som helst hänvisning till klientens transport.

Ett kontrollerat SSH-exempel

Ta en SSH-värd som du har tillåtelse att använda, som svarar på IPv6 och själv kan nå en HTTPS-tjänst som bara finns på v4. OpenSSH:s dynamiska vidarebefordran placerar en lokal SOCKS-lyssnare på din maskin medan inloggningssessionen går över v6.

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

Värden och kontot ovan är exempel, och loopback-bindningen håller lyssnaren på den här datorn. Ersätt den inte med en jokerteckenbindning så att ett kontor kan dela en oautentiserad proxy. ExitOnForwardFailure=yes finns för att en misslyckad vidarebefordran ska avsluta sessionen i stället för att lämna ett tyst kommando som körs i bakgrunden.

Med sessionen igång ser begäran ut så här:

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

Loopback-anslutningen är inte en IPv4-internetväg. Det som lämnar din maskin är inloggningssessionen över v6, och det är den andra sidan som öppnar målsocketen. Formen socks5h delegerar också namnsuppslagningen till den sidan, vilket spelar roll när klienten inte har en egen IPv4-uppslagsväg.

Vad målet faktiskt ser

Målet ser vidarebefordrarens utgångsadress. Ingen adress som tillhör din bärbara dator visas där. En källtillåtelselista på den tjänsten måste namge vidarebefordraren. Dess loggar kommer också att tillskriva trafiken vidarebefordraren. Skriv det i ändringsjournalen före revisionen, eftersom en tillåtelselista byggd kring klientadresser misslyckas vid den första begäran.

Vidarebefordraren är också platsen där samtalets två halvor syns, vilket är en användbar egenskap vid diagnostik och en belastning om vidarebefordraren delas utan policy.

Detta är inte DNS64 eller NAT64

DNS64 svarar med syntetiserade poster som ersätter v4-mål, och NAT64 skriver om paket längs en konfigurerad väg. Ingen av dem beskriver vad som händer här, där ett transportsamtal slutar och ett annat börjar och ingen syntetiserad adress förklarar resultatet. En lyckad begäran säger därför ingenting om vilka översättningstjänster din leverantör driver, och proxyn kan köra vanlig NAT på sin egen utgång.

Båda mekanismerna kan finnas i samma nätverk, så beskriv den du faktiskt verifierade i stället för den som låter närmast.

Känn omfattningen innan du lovar den

OpenSSH:s dynamiska vidarebefordran bär TCP-anslutningar, inte godtycklig IP-trafik, så UDP, ICMP och varje protokoll som ignorerar proxyn behöver en annan stödd design. Behåll SSH-värdnyckelverifiering, serverns vidarebefordringsbegränsningar och HTTPS-certifikatvalidering, eftersom proxyn är en extra betrodd deltagare och inte en anledning att försvaga identitetskontroller. Om målet är att bära en VPN:s yttre transport genom proxyn, verifiera att båda ändarna stöder den transporten i stället för att anta att vilken SOCKS-lyssnare som helst kan vidarebefordra den.

Ingenting av detta gör klienten dual-stack, och ingenting av det behövs. Det får ett program att nå en tjänst genom en vidarebefordran, vilket är ett mindre påstående och mycket lättare att verifiera.