Forbindelse kun på IPv6, tjeneste på IPv4: lad en SOCKS-proxy bygge bro

Du har ikke brug for en adresse i destinationsfamilien for at nå den, så lenge noget på vejen er villigt til at videresende. Applikationen forbinder til proxyen, og proxyen åbner en anden forbindelse til destinationen. Det er to sockets med uafhængige adressefamilier, og intet i nogen af protokollerne kræver, at de passer sammen. Det er videresendelse på applikationsniveau, ikke en native IPv4-vej, og den forskel afgør, hvad der virker, og hvad der ikke gør. At forveksle de to er måden, hvorpå en bærbar ender med at blive beskrevet som havende IPv4-forbindelse, når alt, hvad den har, er en proxy.

To sockets, to adressefamilier

En SOCKS5-anmodning angiver destinationen i en af tre former: en litteral v4-adresse, en litteral v6-adresse eller et navn, som proxyen skal slå op. Anmodningen beskriver, hvor proxyen skal forbinde, ikke hvordan klient-til-proxy-forbindelsen ser ud.

Læs disse adressetyper som tre uafhængige valg i en meddelelse. En proxy, der kan nås over IPv6, kan åbne en socket til en IPv4-destination, når den har fungerende IPv4-udgang, og dens politik tillader anmodningen. Specifikationen for SOCKS5 definerer dem uden nogen henvisning til klientens transport.

Et kontrolleret SSH-eksempel

Tag en SSH-vært, du har tilladelse til at bruge, som svarer på IPv6 og selv kan nå en HTTPS-tjeneste, der kun findes på v4. OpenSSH-dynamisk videresendelse sætter en lokal SOCKS-lytter på din maskine, mens login-sessionen kører over v6.

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

Værten og kontoen ovenfor er eksempler, og loopback-bindingen holder lytteren på denne computer. Erstat den ikke med en wildcard-binding, så et kontor kan dele en uautoriseret proxy. ExitOnForwardFailure=yes findes, for at en mislykket videresendelse afslutter sessionen i stedet for at efterlade en tavs kommando kørende i baggrunden.

Med sessionen kørende ser anmodningen sådan ud:

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

Loopback-forbindelsen er ikke en IPv4-internetvej. Det, der forlader din maskine, er login-sessionen over v6, og det er den anden side, der åbner destinations-socketten. socks5h-formen delegerer også navneopløsning til den side, hvilket betyder noget, når klienten ikke har sin egen IPv4-resolvervej.

Hvad destinationen faktisk ser

Destinationen ser videresenderens udgangsadresse. Ingen adresse, der tilhører din bærbare, vises der. En kilde-tilladelsesliste på den tjeneste skal angive videresenderen. Dens logs vil også tilskrive trafikken til videresenderen. Skriv det i ændringsjournalen før revisionen, fordi en tilladelsesliste bygget omkring klientadresser fejler ved den første anmodning.

Videresenderen er også stedet, hvor de to halvdele af samtalen er synlige, hvilket er en nyttig egenskab under diagnosticering og en byrde, hvis videresenderen deles uden politik.

Det er ikke DNS64 eller NAT64

DNS64 svarer med syntetiserede poster, der repræsenterer v4-destinationer, og NAT64 omskriver pakker langs en konfigureret vej. Ingen af dem beskriver, hvad der sker her, hvor en transportsamtale slutter og en anden begynder, og ingen syntetiseret adresse forklarer resultatet. En vellykket anmodning siger derfor intet om, hvilke oversættelsestjenester din udbyder driver, og proxyen kan køre almindelig NAT på sin egen udgang.

Begge mekanismer kan findes i samme netværk, så beskriv den, du faktisk har verificeret, i stedet for den, der lyder nærmest.

Kend omfanget, før du lover det

OpenSSH's dynamiske videresendelse bærer TCP-forbindelser, ikke vilkårlig IP-trafik, så UDP, ICMP og enhver protokol, der ignorerer proxyen, har brug for et andet understøttet design. Bevar SSH-værtsnøgleverifikation, serverens videresendelsesbegrænsninger og HTTPS-certifikatvalidering, fordi proxyen er en ekstra betroet deltager og ikke en grund til at svække identitetskontroller. Hvis målet er at bære en VPN's ydre transport gennem proxyen, skal du verificere, at begge ender understøtter den transport, i stedet for at antage, at enhver SOCKS-lytter kan videresende den.

Intet af dette gør klienten dual-stack, og intet af det behøver. Det far en applikation til at nå en tjeneste gennem en videresender, hvilket er en mindre påstand og langt lettere at verificere.