Tilkobling kun med IPv6, tjeneste på IPv4: la en SOCKS-proxy bygge bro

Du trenger ikke en adresse i målets adressefamilie for å nå det, så lenge noe på veien er villig til å videresende. Applikasjonen kobler til proxyen, og proxyen åpner en andre tilkobling til målet. Det er to sockets med uavhengige adressefamilier, og ingenting i noen av protokollene krever at de stemmer overens. Det er videresending på applikasjonsnivå, ikke en native IPv4-vei, og forskjellen avgjør hva som vil virke og hva som ikke vil. Å forveksle de to er hvordan en bærbar datamaskin ender opp med å bli beskrevet som å ha IPv4-tilkobling når alt den har er en proxy.

To sockets, to adressefamilier

En SOCKS5-forespørsel navngir målet i en av tre former: en litteral v4-adresse, en litteral v6-adresse eller et navn som proxyen skal slå opp. Forespørselen beskriver hvor proxyen skal koble til, ikke hvordan klient-til-proxy-tilkoblingen ser ut.

Les disse adressetypene som tre uavhengige valg i én melding. En proxy som er tilgjengelig over IPv6, kan åpne en socket mot et IPv4-mål når den har fungerende IPv4-utgang og policyen tillater forespørselen. SOCKS5-spesifikasjonen definerer dem uten noen henvisning til klientens transport i det hele tatt.

Et kontrollert SSH-eksempel

Ta en SSH-vert du har tillatelse til å bruke, som svarer på IPv6 og selv kan nå en HTTPS-tjeneste som bare finnes på v4. OpenSSHs dynamiske videresending setter en lokal SOCKS-lytter på maskinen din mens innloggingsøkten går over v6.

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

Verten og kontoen ovenfor er eksempler, og loopback-bindingen holder lytteren på denne datamaskinen. Ikke erstatt den med en jokertegnbinding så et kontor kan dele en uautentisert proxy. ExitOnForwardFailure=yes finnes for at en mislykket videresending avslutter økten i stedet for å la en stille kommando kjøre i bakgrunnen.

Med økten kjørende ser forespørselen slik ut:

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

Loopback-tilkoblingen er ikke en IPv4-internettvei. Det som forlater maskinen din, er innloggingsøkten over v6, og det er den andre siden som åpner målsocketen. Formen socks5h delegerer også navneoppslag til den siden, noe som betyr noe når klienten ikke har sin egen IPv4-oppslagsvei.

Hva målet faktisk ser

Målet ser videresenderens utgangsadresse. Ingen adresse som tilhører den bærbare datamaskinen din vises der. En kilde-tillatelsesliste på den tjenesten må navngi videresenderen. Loggene vil også tilskrive trafikken til videresenderen. Skriv det i endringsjournalen før revisjonen, fordi en tillatelsesliste bygget rundt klientadresser feiler ved den første forespørselen.

Videresenderen er også stedet der de to halvdelene av samtalen er synlige, noe som er en nyttig egenskap under diagnostisering og en byrde hvis videresenderen deles uten policy.

Dette er ikke DNS64 eller NAT64

DNS64 svarer med syntetiserte poster som erstatter v4-mål, og NAT64 skriver om pakker langs en konfigurert vei. Ingen av dem beskriver det som skjer her, der én transportsamtale slutter og en annen begynner, og ingen syntetisert adresse forklarer resultatet. En vellykket forespørsel sier derfor ingenting om hvilke oversettelsestjenester leverandøren din driver, og proxyen kan kjøre vanlig NAT på sin egen utgang.

Begge mekanismene kan finnes i samme nettverk, så beskriv den du faktisk verifiserte i stedet for den som høres nærmest ut.

Kjenn omfanget før du lover det

OpenSSHs dynamiske videresending bærer TCP-tilkoblinger, ikke vilkårlig IP-trafikk, så UDP, ICMP og enhver protokoll som ignorerer proxyen trenger et annet støttet design. Behold SSH-vertnøkkelverifisering, serverens videresendingsbegrensninger og HTTPS-sertifikatvalidering, fordi proxyen er en ekstra betrodd deltaker og ikke en grunn til å svekke identitetskontroller. Hvis målet er å bære en VPNs ytre transport gjennom proxyen, må du verifisere at begge ender støtter den transporten i stedet for å anta at enhver SOCKS-lytter kan videresende den.

Ingenting av dette gjør klienten dual-stack, og ingenting av det trengs. Det får én applikasjon til å nå én tjeneste gjennom én videresender, noe som er en mindre påstand og langt lettere å verifisere.