Názory k článku
Nginx 1.31 nabízí podporu HTTP Forward Proxy

Šlo by přes ten ngx_http_tunnel_mo­dule směrovat RDP(s) ?

Slo, jen to musis patricne nakonfigurovat - kam tomu dovolis se pripojovat (idealne whitelistem).

V podstate to je analogie k tunelum v SSH, jen over HTTP/S.

Je tam malej rozdíl, je potřeba do toho streamu přihodit na začátek to CONNECT kam:port HTTP/1.1\r\n\r\n a v opačným směru tomu sežrat 200 CONNECTED\r\n\r\n, a jde tím protáhnout cokoli tcp.

Dá se to udělat třeba injectnutou librarkou, která se pověsí na connect() pro existující binárku, proti tomu (na localhost) bindnutému ssh tunelu je to maličko složitější, tam stačí se connectit na ten přesměrovanej localhost.

Když použijete tunel skrze SSH, funguje to tak, že se nejprve ustaví šifrované SSH spojení s tunelem, a pak se tím tunelem protáhne spojení jiného protokolu, třeba RDP. Dá se to dělat dvěma různými způsoby – buď si to SSH spojení umí vytvořit přímo aplikace, kterou používáte pro RDP (případně skrze vloženou knihovnu); nebo to SSH spojení s tunelem vytvoříte někde mimo, a aplikace vytvářející SSH tunel vytvoří někde naslouchající port, a veškerý provoz, který je směrován na ten naslouchající port, pošle skrze ten SSH tunel na druhou stranu. Tohle umí třeba OpenSSH klient. RDP klient pak nemusí umět nic speciálního – prostě se připojí na ten naslouchající port, tj. lokální konec toho tunelu. Jako kdyby tam byl RDP server. Jenže tam není RDP server, ale ústí toho tunelu, který na druhém konci směřuje na nějaký RDP server.

No a úplně stejně to funguje s tím HTTP CONNECT. Nejprve ustavíte HTTP (dnes spíš HTTPS) spojení, v něm se zavolá ten CONNECT – a pak všechna data posílaná do tohoto spojení projdou tím tunelem. Takže opět existují stejné dvě možnosti – buď si RDP klient umí ten HTTP/S CONNECT tunel vytvořit sám, nebo ho vytvoříte někde vedle a RDP klienta nasměrujete na lokální ústí (nebo spíš vstup) do toho tunelu.

Dlouhá slovní masturbace, která opakuje už jednou řečené a nic hodnotného se z toho člověk nedozví.

Pro ekvivalent chování ssh tunelu se dá použít utilita proxytunnel.

proxytunnel -E -a 13389 -p proxy.example­.com:443 -d rdp.lan:3389

Šlo by to zvládnout i socatem, ale ten neumí tls, takže by se před něj případně musel dát stunnel.

Je to stejny - potrebujete klienta co sestavi tunel.
Ani u SSH se prece nepripojujete na port 22 tou aplikaci kterou chcete tunelovat.

Unaset connect() je ponekud zbytecne, beznejsi je, aby se tunel vytvoril jako lokalni naslouchajici port (nebo jako named pipe / socket), ktery si aplikace otevre.

Moje pripominka ale byla k serverove strane - ze nechcete tomu typicky dovolit provadet cokoliv a mit otevreny tunel - jsem nasazoval reverse proxy (apache) a v logu koukam ze jedno z prvnich pokusu byl cinsky sken/pokus o CONNECT (samozrejme neuspesny, protoze cely connect mame zakazany).