Vain IPv6 -yhteys, IPv4-palvelu: annetaan SOCKS-välityspalvelimen sillata
SOCKS-välityspalvelin ottaa vastaan yhden yhteyden ja avaa toisen, joten vain IPv6:n omaava asiakas saavuttaa IPv4-palvelun. Se on välitystä, ei natiivia IPv4-pääsyä.
Et tarvitse kohdeperheeseen kuuluvaa osoitetta saavuttaaksesi kohteen, kunhan jokin polulla on valmis välittämään. Sovellus yhdistää välityspalvelimeen, ja välityspalvelin avaa toisen yhteyden kohteeseen. Ne ovat kaksi pistoketta, joilla on toisistaan riippumattomat osoiteperheet, eikä kumpikaan protokolla vaadi niiden täsmäävän. Se on sovellustason välitystä eikä natiivi IPv4-polku, ja ero ratkaisee, mikä toimii ja mikä ei. Näiden kahden sekoittaminen on syy siihen, miksi kannettavaa kuvataan IPv4-yhteydellä, vaikka kaikki mitä sillä on, on välityspalvelin.
Kaksi pistoketta, kaksi osoiteperhettä
SOCKS5-pyyntö nimeää kohteen yhdessä kolmesta muodosta: kirjaimellinen v4-osoite, kirjaimellinen v6-osoite tai nimi, jonka välityspalvelin selvittää. Pyyntö kuvaa, mihin välityspalvelimen tulee yhdistää, ei sitä, miltä asiakkaan ja välityspalvelimen välinen yhteys näyttää.
Lue nämä osoitetyypit kolmena riippumattomana valintana yhdessä viestissä. IPv6:n kautta tavoitettavissa oleva välityspalvelin voi avata IPv4-kohdepistokkeen aina, kun sillä on toimiva IPv4-lähtö ja sen käytäntö sallii pyynnön. SOCKS5-määritys määrittelee ne viittaamatta lainkaan asiakkaan kuljetukseen.
Kontrolloitu SSH-esimerkki
Ota SSH-isäntä, jota sinulla on lupa käyttää, joka vastaa IPv6:lla ja pystyy itse saavuttamaan HTTPS-palvelun, joka on olemassa vain v4:llä. OpenSSH:n dynaaminen edelleenohjaus asettaa paikallisen SOCKS-kuuntelijan koneellesi, kun kirjautumisistunto kulkee v6:n yli.
ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]Yllä oleva isäntä ja tili ovat esimerkkejä, ja loopback-sidonta pitää kuuntelijan tässä tietokoneessa. Älä korvaa sitä jokerisidonnalla, jotta toimisto voisi jakaa todentamattoman välityspalvelimen. ExitOnForwardFailure=yes on olemassa, jotta epäonnistunut edelleenohjaus päättää istunnon sen sijaan, että taustalle jäisi äänetön komento.
Kun istunto on käynnissä, pyyntö näyttää tältä:
curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/Loopback-yhteys ei ole IPv4-internetpolku. Koneeltasi lähtee kirjautumisistunto v6:n yli, ja vastapuoli avaa kohdepistokkeen. Muoto socks5h myös siirtää nimien selvityksen sille puolelle, millä on merkitystä, kun asiakkaalla ei ole omaa IPv4-selvityspolkua.
Mitä kohde todella näkee
Kohde näkee välittäjän lähtöosoitteen. Yksikään kannettavaasi kuuluva osoite ei näy siellä. Kyseisen palvelun lähdeluettelon on nimettävä välittäjä. Sen lokit kohdistavat liikenteen myös välittäjään. Kirjoita se muutoskirjaan ennen auditointia, koska asiakasosoitteiden ympärille rakennettu sallittujen luettelo epäonnistuu ensimmäisellä pyynnöllä.
Välittäjä on myös paikka, jossa keskustelun kaksi puoliskoa ovat näkyvissä, mikä on hyödyllinen ominaisuus diagnosoinnissa ja rasite, jos välittäjää jaetaan ilman käytäntöä.
Tämä ei ole DNS64 tai NAT64
DNS64 vastaa syntetisoiduilla tietueilla, jotka edustavat v4-kohteita, ja NAT64 kirjoittaa paketit uudelleen määritettyä polkua pitkin. Kumpikaan ei kuvaa sitä, mitä täällä tapahtuu, missä yksi kuljetuskeskustelu päättyy ja toinen alkaa eikä mikään syntetisoitu osoite selitä tulosta. Onnistunut pyyntö ei siis kerro mitään siitä, mitä käännöspalveluja tarjoajasi käyttää, ja välityspalvelin voi ajaa tavallista NAT:ia omassa lähdössään.
Molemmat mekanismit voivat olla samassa verkossa, joten kuvaile se, jonka todella varmensit, älä sitä, joka kuulostaa lähimmältä.
Tunne laajuus ennen kuin lupaat sen
OpenSSH:n dynaaminen edelleenohjaus kantaa TCP-yhteyksiä, ei mielivaltaista IP-liikennettä, joten UDP, ICMP ja mikä tahansa välityspalvelimen sivuuttava protokolla tarvitsevat toisen tuetun mallin. Säilytä SSH-isäntäavaimen vahvistus, palvelimen edelleenohjausrajoitukset ja HTTPS-varmenteen validointi, koska välityspalvelin on ylimääräinen luotettu osapuoli, ei syy heikentää henkilöllisyyden tarkistuksia. Jos tavoitteena on kuljettaa VPN:n ulompi kuljetus välityspalvelimen kautta, varmista, että molemmat päät tukevat tätä kuljetusta sen sijaan, että olettaisit minkä tahansa SOCKS-kuuntelijan pystyvän välittämään sen.
Mikään tästä ei tee asiakkaasta kaksipinoista, eikä mitään siitä tarvita. Se saa yhden sovelluksen saavuttamaan yhden palvelun yhden välittäjän kautta, mikä on pienempi väite ja paljon helpompi vahvistaa.