Verbinding alleen IPv6, dienst op IPv4: laat een SOCKS-proxy de brug slaan

Je hebt geen adres uit de bestemmingsfamilie nodig om die te bereiken, zolang iets op het pad bereid is door te sturen. De toepassing verbindt met de proxy, en de proxy opent een tweede verbinding naar de bestemming. Dat zijn twee sockets met onafhankelijke adresfamilies, en niets in een van beide protocollen vereist dat ze overeenkomen. Dat is doorsturen op toepassingsniveau, geen native IPv4-pad, en dat onderscheid bepaalt wat wel en niet werkt. De twee door elkaar halen is hoe een laptop wordt beschreven als met IPv4-connectiviteit terwijl alles wat hij heeft een proxy is.

Twee sockets, twee adresfamilies

Een SOCKS5-verzoek noemt de bestemming in een van drie vormen: een letterlijk v4-adres, een letterlijk v6-adres of een naam die de proxy moet oplossen. Het verzoek beschrijft waar de proxy moet verbinden, niet hoe de verbinding van client naar proxy eruitziet.

Lees die adrestypen als drie onafhankelijke keuzes binnen een bericht. Een proxy die via IPv6 bereikbaar is, kan een socket voor een IPv4-bestemming openen wanneer hij een werkende IPv4-uitgang heeft en zijn beleid het verzoek toestaat. De SOCKS5-specificatie definieert ze zonder enige verwijzing naar het transport van de client.

Een gecontroleerd SSH-voorbeeld

Neem een SSH-host die je mag gebruiken, die op IPv6 antwoordt en zelf een HTTPS-dienst kan bereiken die alleen op v4 bestaat. De dynamische doorgifte van OpenSSH zet een lokale SOCKS-listener op je machine terwijl de aanmeldsessie via v6 loopt.

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

De host en het account hierboven zijn voorbeelden, en de loopback-binding houdt de listener op deze computer. Vervang die niet door een wildcard-binding zodat een kantoor een niet-geauthenticeerde proxy kan delen. ExitOnForwardFailure=yes bestaat zodat een mislukte doorgifte de sessie beëindigt in plaats van een stil commando op de achtergrond te laten lopen.

Terwijl de sessie loopt, ziet het verzoek er zo uit:

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

De loopback-verbinding is geen IPv4-internetpad. Wat je machine verlaat is de aanmeldsessie via v6, en de andere kant opent de socket naar de bestemming. De vorm socks5h delegeert ook de naamresolutie naar die kant, wat uitmaakt wanneer de client geen eigen IPv4-resolverpad heeft.

Wat de bestemming werkelijk ziet

De bestemming ziet het uitgaande adres van de doorgever. Geen enkel adres van jouw laptop verschijnt daar. Een bron-allowlist op die dienst moet de doorgever noemen. De logboeken zullen het verkeer ook aan de doorgever toeschrijven. Schrijf dat vóór de audit in het wijzigingsregister, want een allowlist rond clientadressen faalt bij het eerste verzoek.

De doorgever is ook de plek waar de twee helften van het gesprek zichtbaar zijn, wat een nuttige eigenschap is bij diagnose en een last als de doorgever zonder beleid wordt gedeeld.

Dit is geen DNS64 of NAT64

DNS64 antwoordt met gesynthetiseerde records die v4-bestemmingen vervangen, en NAT64 herschrijft pakketten langs een geconfigureerd pad. Geen van beide beschrijft wat hier gebeurt, waar het ene transportgesprek eindigt en het andere begint en geen gesynthetiseerd adres het resultaat verklaart. Een geslaagd verzoek zegt dus niets over welke vertaaldiensten je provider draait, en de proxy kan gewone NAT op zijn eigen uitgang uitvoeren.

Beide mechanismen kunnen in hetzelfde netwerk bestaan, dus beschrijf degene die je echt hebt geverifieerd in plaats van degene die het dichtst bij klinkt.

Ken de reikwijdte voordat je die belooft

De dynamische doorgifte van OpenSSH draagt TCP-verbindingen, geen willekeurig IP-verkeer, dus UDP, ICMP en elk protocol dat de proxy negeert hebben een ander ondersteund ontwerp nodig. Behoud SSH-hostkeysleutelverificatie, de doorgiftebeperkingen van de server en HTTPS-certificaatvalidatie, want de proxy is een extra vertrouwde deelnemer, geen reden om identiteitscontroles te verzwakken. Als het doel is het buitenste transport van een VPN door de proxy te dragen, verifieer dan dat beide uiteinden dat transport ondersteunen in plaats van aan te nemen dat elke SOCKS-listener het kan doorgeven.

Niets hiervan maakt de client dual-stack, en niets daarvan hoeft. Het zorgt ervoor dat één toepassing één dienst bereikt via één doorgever, wat een kleinere bewering is en veel gemakkelijker te verifiëren.