Připojení jen přes IPv6, služba na IPv4: nechte SOCKS proxy, ať to přemostí

K dosažení cíle nepotřebujete adresu z cílové rodiny, dokud je něco na cestě ochotno přeposílat. Aplikace se připojí k proxy a proxy otevře druhé připojení k cíli. To jsou dva sockety s nezávislými rodinami adres a nic v žádném z obou protokolů nevyžaduje, aby se shodovaly. Je to přeposílání na úrovni aplikace, nikoli nativní cesta IPv4, a tento rozdíl rozhoduje o tom, co bude fungovat a co ne. Záměna obojího je důvod, proč je notebook popisován jako mající konektivitu IPv4, když má jen proxy.

Dva sockety, dvě rodiny adres

Požadavek SOCKS5 pojmenovává cíl jednou ze tří forem: literální adresa v4, literální adresa v6 nebo jméno, které má proxy přeložit. Požadavek popisuje, kam se má proxy připojit, ne jak vypadá připojení klient–proxy.

Čtěte tyto typy adres jako tři nezávislé volby v jedné zprávě. Proxy dostupná přes IPv6 může otevřít socket cíle IPv4, kdykoli má funkční odchozí cestu IPv4 a její politika požadavek povoluje. Specifikace SOCKS5 je definuje zcela bez odkazu na transport klienta.

Kontrolovaný příklad se SSH

Vezměte SSH hostitele, kterého smíte používat, který odpovídá na IPv6 a sám dosáhne služby HTTPS existující jen na v4. Dynamické přesměrování OpenSSH umístí na váš stroj místní SOCKS posluchač, zatímco přihlašovací relace běží přes v6.

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

Hostitel a účet výše jsou příklady a vazba na loopback drží posluchač na tomto počítači. Nenahrazujte ji vazbou na všechny adresy, aby kancelář mohla sdílet neautentizovanou proxy. ExitOnForwardFailure=yes existuje proto, aby neúspěšné přesměrování ukončilo relaci, místo aby nechalo v pozadí tiše běžet příkaz.

Když relace běží, požadavek vypadá takto:

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

Spojení přes loopback není internetová cesta IPv4. Z vašeho stroje odchází přihlašovací relace přes v6 a socket cíle otevírá protistrana. Forma socks5h také deleguje překlad jmen na tuto stranu, což je důležité, když klient nemá vlastní cestu k resolveru IPv4.

Co cíl skutečně vidí

Cíl vidí odchozí adresu přeposílatele. Žádná adresa patřící vašemu notebooku se tam neobjeví. Seznam povolených zdrojů na této službě musí uvádět přeposílatele. Její logy také přisoudí provoz přeposílateli. Zapište to do záznamu o změně před auditem, protože seznam povolených postavený kolem adres klientů selže při prvním požadavku.

Přeposílatel je také místem, kde jsou vidět obě poloviny rozhovoru, což je užitečná vlastnost při diagnostice a závazek, pokud je přeposílatel sdílený bez politiky.

Toto není DNS64 ani NAT64

DNS64 odpovídá syntetizovanými záznamy, které zastupují cíle v4, a NAT64 přepisuje pakety po nakonfigurované cestě. Ani jedno nepopisuje, co se děje tady, kde jeden transportní rozhovor končí a druhý začíná a žádná syntetizovaná adresa výsledek nevysvětluje. Úspěšný požadavek tedy nic neříká o tom, jaké překladové služby váš poskytovatel provozuje, a proxy může na své odchozí cestě provozovat běžný NAT.

Oba mechanismy mohou existovat ve stejné síti, takže popište ten, který jste skutečně ověřili, ne ten, který zní nejblíž.

Znát rozsah, než ho slíbíte

Dynamické přesměrování OpenSSH přenáší TCP spojení, ne libovolný IP provoz, takže UDP, ICMP a jakýkoli protokol, který proxy ignoruje, potřebují jiný podporovaný návrh. Zachovejte ověřování klíče hostitele SSH, omezení přesměrování na serveru a validaci certifikátu HTTPS, protože proxy je další důvěryhodný účastník, nikoli důvod k oslabení kontrol identity. Pokud je cílem přenést vnější transport VPN přes proxy, ověřte, že oba konce tento transport podporují, místo abyste předpokládali, že jej jakýkoli SOCKS posluchač dokáže přeposlat.

Nic z toho nedělá klienta dvouskladbovým a nic z toho není potřeba. Způsobuje, že jedna aplikace dosáhne jedné služby přes jednoho přeposílatele, což je menší tvrzení a mnohem snadněji ověřitelné.