> a kolik dat se vejde do bufferu proxy?
Podle toho, co by kdo použil, jak by si to nastavil atd. Možná by se takováto jednoduchá proxyna dala vyrobit i z nc, ale netuším moc, jak se tento nástroj chová.
> Pokud se vše nepovede doručit na první dobrou, kdo se bude starat o retrans?
Ta proxy, aspoň na úrovni TCP. Pokud ale například umře spojení, je nutné udělat novou session, s tím proxyna už nic nenadělá.
mně připadá, že to je škrábání se špatnou nohou za špatným uchem.
To raději to ssh co nejdříve ukončit a na dané "proxy" si mountnout FS vhodnějším protokolem, což mimochodem se také často dělá.
Z těhle obcházení limitů vznikají hodně zákeřné problémy a je lepší ty technologie používat tak, jak jsou testované.
Uznávám, že je to ohack, ale proxyna na této vrstvě nemá jiné možnosti než útočník. Ten taky může poslat falešný ACK po TCP a mělo by to způsobit přinejhorším DoS. Stejnětak tento hack.
Jinak řečeno, budou-li problémy s tímto hackem, máme něco špatně zabezpečeno.
Co se týče použití jiného protokolu, je to samozřejmě taky cesta, otázkou ale zůstává, který protokol použít, abychom dostali odpovídající zabezpečení, stejnou funkcionalitu a podporu na druhé straně. To záleží na situaci.
tenhle hack může zlobit tehdy, když síť má příliš vysoké latence nebo se vnější vinou sníží propustnost, proxy nebude mít neomezený buffer a jednou jí dojde, client bude mít falešné informace o tom co je již posláno a může dojít ke ztrátě dat, v zajištění integrity bych viděl velký problém. Pokud mi někdo posílá falešná ACK, neměl bych to řešit na téhle úrovni, ale o trochu níže.
nfsv4 se používá se kerberosem, iscsi s ipsecem, pokud data tečou přímo na pásky, je tady několik nativní rozšíření pro iscsi (v praxi jsem potkal t10 s ibm storage system).
Podpora na druhé straně je problém, pokdu se jedná o nějaký enterprise storage system, moc na výběr často není, vždy je možnost to protlouct hrubou silou a multiplikovat ssh spojení tak abych měl odpovídající průtok. Rozhodně bych se ale nepouštět do tebou navrhnovaného hacku, raději bych zajistit integrační server, který na jedné straně bude mít blízké ssh klienty a na druhé nějaký vhodnější protokol, viz odstavec hore.
Opakuju, pokud falešné ACKy mohou způsobit problém jako ztrátu integrity, je to zranitelnost, protože totéž může udělat útočník na síti. Neznám všechny detaily SSH, ale není to úplně noname záležitost, a předpokládám, že se TCP ACK bere jen jako taková první aproximace. Tzn. pokud ACK dorazí, víme, že data nemusíme posílat znovu, ale nevíme, co vlastně dorazilo druhé straně.
Spoléhání se na ACK mimochodem není dobré ani pokud síti věřím. Pokud na druhé straně třeba spadne aplikace, dojde místo nebo něco podobného, ACK nejspíš dorazí, ale data se nezpracují, jak bych chtěl. Takže stejně nemohu na aplikační vrstvě rozhodnout o provedení akce jen podle ACKu, ale potřebuju i něco jako ACK na aplikační vrstvě. Tedy na vyšší vrstvě, ne na nižší.
Ad co se stane, když se proxyně zaplní buffer: Pak by měla přestat posílat další ACKy zpátky.