U SSHFS bych to teda ocenil víc než u SSH. Se SSH jsem měl problémy asi jen jednou, když jsem byl připojený přes satelit a byla vyšší odezva, ale nebylo to nic extra hrozného.
U SSHFS jsem už narazil na problémy s vypršením dočasné adresy (RFC 4941), uspáním apod. U SSH to jednoduše řeší screen - návažu nové spojení a připojím se k běžícímu screenu. U SSHFS to znamená, že jádro si zamkne nějaký zámek a je problém přistoupit k file systému a tedy i odmountovat vytimoutovaný svazek se SSHFS.
Nenapadá mě žádný důvod, proč by se pocit z používání SSH měl zlepšit*, když jeho TCP spojení zabalíte do UDP. Přibude jen jedna slupka navíc. Jediné, co se dá pomocí OpenVPN vyřešit, je právě ta mobilita - při změně adresy se adresy uvnitř VPN nezmění a TCP spojení (s trochou štěstí) zůstane navázáno.
*) Jedině snad, pokud by byl TCP provoz omezován traffic shapingem víc, než UDP provoz. Ale to je pak spíše záležitost konkrétní sítě.
Nevím jak obecně, ale námi používané VPN běžící přes UDP předpokládá chyby na kanále a je poměrně agresivní při přeposílání paketů. Takže u "zaneřáděných sítí" je to opravdu rozdíl oproti TCP, které má timeout na intenzivní full duplex službu příliš dlouhý. Nevýhodou pak je, že se těch dat přenese kolikrát i řádově více, protože klient i server "spamují" i 10x za sekundu, což v případě pingu nad 100ms znamená stoprocentní přítomnost duplicit.
Toto neřeší přetíženou síť, ale nespolehlivou síť. My jsme to využili jedinkrát a to ve chvíli, kdy jeden z routerů začal náhodně zahazovat packety. Bylo potřeba změnit konfiguraci serveru, ale na ten se díky zmatenému routeru přes TCP prakticky nedalo dostat, protože při ztrátě několika packetů za sebou jdou timeouty k nekoneču a efektivní přenosová rychlost k nule. To ani na ten vim nestačilo. Lidé z IBM nám doporučili zkusit to přes VPN. Sice chvíli trvalo než nás přesvědčili (také jsme si klepali na čelo jak by tohle mohlo pomoci), ale opravdu to fungovalo.
Je sice hezke zminit, ze kdyz je server za klasickou NAT maskaradou N:1, je treba provest zvenku portNAT. Ale to je standardni zalezitost bezna pro vsechny servery takto umistene.
Dulezitejsi mi spis prijde problem toho skriptu pusteneho pres SSH. Server oznami IP na ktere se pustil, coz je ale interni IP. Tato predana IP je klientu zhola k nicemu. Ten potrebuje verejnou IP.
Kdepak, mosh-client se připojuje na IP adresu, kterou oznámí místně spuštěný skript mosh v netcat režimu, tedy na tu samou, na kterou se navazuje SSH spojení. Ze vzdálené strany se zjišťuje jen číslo UDP portu a šifrovací klíč.
Jenom je potřeba, aby čísla portů na externí adrese odpovídala interním číslům portů.
Taky si pochvaluju tenhle aktualni clanek. Zahledl jsem to pred par dny a trochu pohledal:
-pokud klient a server neni na verejny ip, musite zajistit pruchod udp na vysokejch portech, coz je muj problem
-protokol je dost novinka,neni to vyzkouseny casem
-tunely jsou otazka
-X forward zatim neni
-nekdo to castecne srovnava s autossh
A to je to, co se chci zeptat - ma tu nekdo zkusenosti s autossh? Zkusil jsem to jednou, ale vysledkem bylo, ze mi viselo okno s heslem a neslo zabit
S tím číslováním paketů je to docela chytře vyřešené, protože OCB používá sůl a ta je použitá jako sekvenční číslo, které se inkrementuje.
"OCB requires that each plaintext be paired with a
unique 128-bit nonce over the life of the encryption key.
We use an incrementing 63-bit sequence number and di-
rection flag for this purpose."
Zdroj: http://mosh.mit.edu/mosh-paper-draft.pdf
Upřímně řečeno, já jsem na podobné auto banovací věci dost opatrný. Ono se samozřejmě špatně pozná, jak přispěly, ale tak nějak subjektivně mám pocit, že zatím jsem s nimi měl víc starostí, než jaký mají přínos. Vždycky proto vyžaduju nějakou možnost, jak to co nejjednodušeji (a hlavně ne přes zabanované spojení) odblokovat.
Jako extrémní variantu řešení bych poradil pořídit si nějaký virtuální počítač (hodně firem nabízí na zkoušku zadarmo nebo za pár šupů) a přihlásit se z něj (pokud se používá denyhost, předpookládám, že SSH nebude omezené jen na předem definované IP).