Pripojenie len cez IPv6, služba na IPv4: nech SOCKS proxy to premostí

Na dosiahnutie cieľa nepotrebujete adresu z cieľovej rodiny, pokiaľ je niečo na ceste ochotné preposielať. Aplikácia sa pripojí k proxy a proxy otvorí druhé pripojenie k cieľu. Sú to dva sockety s nezávislými rodinami adries a nič v žiadnom z protokolov nevyžaduje, aby sa zhodovali. Je to preposielanie na úrovni aplikácie, nie natívna cesta IPv4, a tento rozdiel rozhoduje o tom, čo bude fungovať a čo nie. Zámena oboch je dôvod, prečo sa notebook opisuje ako majúci pripojenie IPv4, hoci má iba proxy.

Dva sockety, dve rodiny adries

Požiadavka SOCKS5 pomenúva cieľ jednou z troch foriem: literálna adresa v4, literálna adresa v6 alebo názov, ktorý má proxy preložiť. Požiadavka opisuje, kam sa má proxy pripojiť, nie ako vyzerá pripojenie klient–proxy.

Čítajte tieto typy adries ako tri nezávislé voľby v jednej správe. Proxy dostupná cez IPv6 môže otvoriť socket cieľa IPv4, kedykoľvek má funkčný výstup IPv4 a jej politika povoľuje požiadavku. Špecifikácia SOCKS5 ich definuje úplne bez odkazu na transport klienta.

Kontrolovaný príklad so SSH

Vezmite SSH hostiteľa, ktorého smiete používať, ktorý odpovedá na IPv6 a sám dokáže dosiahnuť službu HTTPS existujúcu iba na v4. Dynamické presmerovanie OpenSSH umiestni na váš stroj lokálny SOCKS poslucháč, kým prihlasovacia relácia beží cez v6.

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

Hostiteľ a účet vyššie sú príklady a väzba na loopback drží poslucháč na tomto počítači. Nenahrádzajte ju väzbou na všetky adresy, aby kancelária mohla zdieľať neautentizovanú proxy. ExitOnForwardFailure=yes existuje preto, aby neúspešné presmerovanie ukončilo reláciu, namiesto toho aby nechalo v pozadí ticho bežať príkaz.

Keď relácia beží, požiadavka vyzerá takto:

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

Spojenie cez loopback nie je internetová cesta IPv4. Z vášho stroja odchádza prihlasovacia relácia cez v6 a socket cieľa otvára vzdialená strana. Forma socks5h tiež deleguje preklad názvov na tú stranu, čo je dôležité, keď klient nemá vlastnú cestu k resolveru IPv4.

Čo cieľ skutočne vidí

Cieľ vidí výstupnú adresu preposielača. Neobjaví sa tam žiadna adresa patriaca vášmu notebooku. Zoznam povolených zdrojov na tej službe musí uviesť preposielača. Jej záznamy tiež pripíšu prevádzku preposielačovi. Zapíšte to do záznamu zmien pred auditom, pretože zoznam povolených postavený okolo adries klientov zlyhá pri prvej požiadavke.

Preposielač je aj miestom, kde sú viditeľné obe polovice rozhovoru, čo je užitočná vlastnosť pri diagnostike a záťaž, ak sa preposielač zdieľa bez politiky.

Toto nie je DNS64 ani NAT64

DNS64 odpovedá syntetizovanými záznamami, ktoré zastupujú ciele v4, a NAT64 prepisuje pakety pozdĺž nakonfigurovanej cesty. Ani jedno neopisuje, čo sa deje tu, kde sa jeden transportný rozhovor končí a druhý začína a žiadna syntetizovaná adresa nevysvetľuje výsledok. Úspešná požiadavka preto nič nehovorí o tom, aké prekladové služby váš poskytovateľ prevádzkuje, a proxy môže na svojom výstupe spúšťať bežný NAT.

Oba mechanizmy môžu existovať v tej istej sieti, preto opíšte ten, ktorý ste skutočne overili, a nie ten, ktorý znie najbližšie.

Poznajte rozsah, kým ho sľúbite

Dynamické presmerovanie OpenSSH prenáša TCP spojenia, nie ľubovoľnú IP prevádzku, takže UDP, ICMP a každý protokol, ktorý ignoruje proxy, potrebujú iný podporovaný návrh. Zachovajte overovanie kľúča hostiteľa SSH, obmedzenia presmerovania servera a validáciu certifikátu HTTPS, pretože proxy je ďalší dôveryhodný účastník, nie dôvod oslabiť kontroly identity. Ak je cieľom preniesť vonkajší transport VPN cez proxy, overte, že oba konce podporujú tento transport, namiesto toho aby ste predpokladali, že ho dokáže preposlať akýkoľvek SOCKS poslucháč.

Nič z toho nerobí klienta dvojitým zásobníkom a nič z toho nie je potrebné. Umožňuje jednej aplikácii dosiahnuť jednu službu cez jedného preposielača, čo je menšie tvrdenie a oveľa ľahšie overiteľné.