Názory k článku Postavte si VPN pomocí sshuttle, bude vám stačit přístup na SSH

Vyzkoušel jsem a dodám pár vlastních postřehů

1) Na cílovém stroji musí být nějaká síť, nějaká jiná, než jen veřejná IP. Protože zadaný rozsah prostě musí být na cílovém stroji. Žádné vlastní IP rozsahy, jako třeba u PPTP. nebo N2N. Pokud na cílovém stroji nemáte roota, a ani žádnou podsíť, nedá se to provozovat.

2) Při přesměrování veškerého rozsahu jsem dostával Broken Pipe. Teprve uvedením cílového stroje za parametr -x to začalo fungovat. Nechce se mi věřit, že by ten nástroj své vlastní spojení nedokázal blacklistovat pro přesměrování

3) Je to jen jednosměrné. Není možné komunikovat z cílového stroje na svůj a třeba si na klientovi zřídit server. K tomu bude opět potřeba ssh -R

1) trochu nerozumím: zkusil jsem proti Linuxu a FreeBSD, oba mají jen veřejnou IP a šlo to, spojení se tváří jako z cílového stroje (efektivně NAT) - což jsem z popisu očekával.
2) tohle proti Linuxu nenastalo, proti BSD ano
3) to IMHO nevadí, k tomu to ani není určeno, tohle je na VPN-like přístup někam, kde VPN nemám, nechci mít, nenapadlo mě dopředu, že bude potřeba nebo z nějakých důvodů nelze zřídit. Na server na klientovi je potřeba (je lepší) použít nějakou normální VPN, třeba L2TP/IPsec s možností reconnect, směrovacích tabulek, firewallu.

1) má smysl jen pokud fakt chci směrovat veškerý provoz přes ten tunel. Pokud chci si ten cílový stroj udělat jako stroj, který mám "hned vedle na stejném subnetu", tak to nejde. Jenže nevidím moc důvod proč všechno honit přes jeden stroj, snad jako nepřítel státu, kterého sledují.

Proč hned nepřítel státu? Můžete tak chtít například obejít blokování/sledování provozu zaměstnavatelem.

nebo prostě jste jenom na veřejné wifi...

No nejde: pokud musíte použít (viz původní bod 2) parametr -x, tak se tunelem přímo na ten stroj nedostanete.
Pokud ten parametr použít nemusíte, dostanete se tam.
A co všechno budete tunelem honit přece určuje ta cílová maska, v příkladu 0/0. Když tam dáte co já vím 192.168.4.0/24, tak do tunelu půjde jen komunikace směřující do té sítě a nic jiného.
Jestliže je ssh server za NATem (port forwarding), tak dokonce ani to -x nebude vadit (ale neověřoval jsem).
Takže jde o to, co od toho chcete a většinou to i dostanete, když zadáte vhodné parametry.

Fajn nastroj. SSH tunel je v Cine jistota, wireguard, shadowsocks, openvpn jsou vsechny po par minutach utnuty, a IP vpn serveru strcena do cerne diry, uz si na nej z Ciny ani nepingnete.

Vetsinou pouzivam dynamic port forwarding ( -D) a na vzniklou socks proxy mam nasmerovany Firefox; foxyproxy na pravidla (nektere rozsahy posilam na jiny vpn server na pripojeni ke klientum, nektere veci naprimo). Zbytek systemu se mi hodi mit naprimo (pristupuju k serverum v Cine).

Dalsi nevyhoda sshuttle, na kterou jsem ted narazil: pokud mate na stroji nativni funkcni ipv6, to zustane aktivni i po nastartovani tunelu a provoz pujde casto pres nej (ok, beru, rikam 0/0) a neprisel jsem na jiny zpusob, nez z rozhrani ipv6 adresu odstranit.

ipv6 má prioritu, takže se použije pokud lze, SSH tunel by musel vytvářet také ipv6...

Pokud vim, prohlizece pouzivaji Happy Eyeballs algoritmus (https://superuser.com/questions/403716/how-do-client-applications-know-to-use-ipv4-or-ipv6).

Bylo by fajn, kdyby mel sshuttle prepinac jako --blackhole-ipv6, aby se uzivatel nemusel rucne starat o odstraneni ipv6 konektivity v pripade, ze chce vsechno hnat pres tunel.

ja to pouzivam pre remmina

ja pouzivam ssh + tinyproxy a v chrome pouzivam proxy switcher

Jak se to vyrovnava s vypadky ssh spojeni? Treba sshfs jsem musel dat 3 radky konfigurace, aby se spojeni obnovilo do 10 sekund misto pulhodinovyho timeoutovani zakoncenyho uplnym spadnutim.

Ano, slibuji to už velmi dlouho. Mám ho v seznamu úkolů teď úplně nahoře, tak snad to bude brzy.

Meril tomu nekdo vykon/zatez CPU na klientu/serveru?

zatížení asi nebude vysoké, ssh má pevnou block size a to bývá největší brzda díky potřebě ACK z druhé strany, takže většinu času se jen čeká a nepálí se instrukce.