Já bych si tedy VPN založenou na TCP-over-TCP nedovolil označit ani náhodou za něco co funguje „k naprosté spokojenosti“. Vypadá to, že to funguje, ale jen do chvíle, než na přenosové trase dojde k prvnímu výpadku nebo zpoždení.
Více v známém článku Why TCP Over TCP Is A Bad Idea.
Zase tak pomalé to není. Dá se z toho stabilně vytáhnout přes 5Mbit/s download (podotýkám, že to připojení je z principu nesymetrické, podobně jako ADSL), ale v tomhle případě se snad nebavíme o A++ grade VPN připojení.
Popravdě, DNS tunel používám jen díky wifi síti dotované jihomoravským krajem, respektive provozované pod IDS JMK. To je přesně ten typ zkriplené konektivity, kde jediné, co funguje je port 80 a 443 a pak ještě DNS překlady a ping.
Pokud máš nestabilní připojení, kde je vysoká latence a navíc se sem tam nějaký packet ztratí, už se ten efekt TCP-in-TCP projeví.
Z tohoto pohledu je tedy lepší pro VPN používat protokoly, které neřeší retransmisi ztracených dat, ale nechat to řešit až v tunelovaných protokolech (hezkým příkladem je sada protokolů AH/ESP používaných pro IPSec, který má mimochodem fallback i na UDP), a nebo již zmiňovaná VPN over DNS nebo VPN over ICMP.
Donutil jsi mě v práci rebootovat do linuxu a vyzkoušet to na naší konektivitě.
Použil jsem speedtest.cesnet.cz a naměřené rychlosti jsou 25Mbit/s download a 22Mbit/s upload.
Konektivita v práci je 250Mbit, noťas připojen přes 100Mbit rozhraní, konektivita k mému VPN serveru je 100/60Mbit
Tím jsem myslel, že můžeš použít třeba OpenDNS nebo googlí DNS nebo cokoliv jiného. Ten iodine má výhodu v tom, že je schopen udělat autodetekci a vybrat si nejvhodnější protokol/DNS dotaz. V případě, že je otevřená komunikace do světa na portu udp/53, bude posílat přímá data, pokud by tam byla nějaká inspekce na sedmé vrstvě, bude posílat DNS dotazy.
DNS VPN se nedá použít skrz HTTP proxy, ale to ani není potřeba. Jelikož můžeš udělat DNS překlad (to už by musela být skutečně dojebaná síť, která by nedovolila ani DNS překlady), o „proxy“ se ti postará DNS server, vůči kterému budeš dělat DNS překlady (klidně i ten, co ti síť vnutí přes DHCP).
Nastuduj si, jak funguje překlad DNS na IP, a pak si jen uvědom, že místo regulérních DNS dotazů posíláš data, co se jako DNS dotaz tváří.
Pokud se někde ve vnitřní síti vynucuje přístup přes proxy, pak není důvod aby tam fungovalo externí DNS, protože překlad stejně bude dělat ta proxy, a pokud něco není potřeba, tak to logicky každý rozumný admin/bezpečák zakáže, IMO nic výjimečného např. ve firemním prostředí
C:\Users\xxx>ping www.seznam.cz
Ping request could not find host www.seznam.cz. Please check the name and try again.
C:\Users\xxx>nslookup www.seznam.cz
Server: xxx.cz
Address: 10.xxx
*** xxx.cz can't find www.seznam.cz: Non-existent domain
Pokud je dostupný neomezený přístup na port 443, je asi nejjednodušší SSH na portu 443 a na něm spustit SSH tunel, ať už statický, nebo dynamický.
Pokud je na portu 443 nějaké DPI zařízení, které pustí jen TLS provoz, je nejlepší mít na web serveru podporu režimu proxy a příkazem HTTP CONNECT se zase spojit k nějakému SSH serveru. To by mohl být zajímavý námět na další článek :)
SSH na port 443 skrz HTTP proxy používám, se zapnutým dynamickým port forwardingem (-D parametr) se to chová jako SOCKS proxy, kterou spousta aplikací umí přímo použít a ostatní lze většinou donutit prográmkem FreeCap či WideCap. Nebo lze přes FreeCap spustit http proxy jako třeba Proxy+ a tu pak použít v aplikaci, která umí jen HTTP proxy a nefunguje přes FreeCap.
Výhoda je, že lze nastavovat po aplikacích zda se bude komunikovat přímo či přes tunel, taká je daleko snazší to spustit, v podstatě stačí nakopírovat a spustit putty, což může i běžný uživatel. VPN potřebuje instalovat síťové rozhraní, což může jen admin.
Výhoda VPN je snazší přepínání celého provozu přímo/přes VPN a větší univerzálnost, přes SSH tunel asi nepojedou aplikace vyžadující UDP.
SSLH jsem chtěl zkusit pro multiplex OpenVPN a SSH, ale nakonec jsem se ktomu nedokopal, protože sem tu OpenVPN zas až tak nutně nepotřeboval.
Každopádně mi vrtá hlavou zda se při tunelování TCP spojení přes SSH rovněž může vyskytnout TCP over TCP problém, když defacto také tuneluji TCP spojení přes jiné TCP spojení.
Každopádně mi vrtá hlavou zda se při tunelování TCP spojení přes SSH rovněž může vyskytnout TCP over TCP problém, když defacto také tuneluji TCP spojení přes jiné TCP spojení.
Nikoli, SSH tunelování pomocí příkazů -L, -R a -D koncept TCP-in-TCP nepoužívá, místo toho jde o sérii tří nezávislých TCP spojení, kde první jde od klienta a končí na SSH klientovi/serveru (pro -L,-D resp. -R), druhé je vlastní SSH spojení na SSH server/klienta a odtamtud pokračuje třetí nezávislé TCP spojení z SSH serveru/klienta na tunelovaný server.
Jediný případ, který může být nebezpečný z hlediska TCP-in-TCP je spouštění PPP protokolu nad SSH, nebo tunelování pomocí tun zařízení (přepínač -w).
Jinak samozřejmě, SSH tunelování (pomocí příkazů -L, -R a -D) nepodporuje UDP, ale ono UDP-over-TCP by stejně moc dobře nefungovalo.
Tak určitě. :-) Já vím, že to samozřejmě nemůže za žádnou cenu fungovat, ale i přesto to osobně využívám přes deset let :-)
Na stejné IP mi běží primární UDP VPNka a pokud se na ni nedostanu, mám další instanci na TCP portu 443, kterou mohu použít v případech, že je UDP provoz blokovaný.
Rád bych potvrdil všechny teorie o tom, že TCP VPN nemůže fungoval, ale bohužel nemůžu sloužit, nikdy jsem nenarazil na problém :-( A to jako klienty používám Linux, OS X i iOS zařízení (iPhone a iPad)...
Ano, TCP-over-TCP určitě není dobrý nápad, ale vlastní zkušenost říká, že se to používat dá (zvlášť myslím ty případy, kdy člověku nic jiného nezbývá).
Teď používám OpenVPN po UDP, předtím jsem ale několik let používal OpenVPN po TCP a nenarazil jsem na problém (přičemž jsem dokonce míval OpenVPN server na ADSL lince).
A ještě předtím (páni, to už je víc jak deset let) jsem tuneloval ppp skrz ssh a také to fungovalo. A dokonce jsem tuto kombinaci zkoušel přes GPRS (mobil připojený přes IrDA) a taky to šlo. :-)