Názory k článku Hamachi: vytvořte si vlastní VPN

Mam z toho takovy neprijemny pocit, ze mam spoustet nejaky proprietarni program jako root. Clovek si rekne, kdovi co to kam posila. No, mozna bych to s tou paranoiou nemel moc prehanet.

Jak se to na firewallu zakáže ?

?

Ja pouzivam toto:

# bibi.hamachi.cc has address 69.25.21.221
$IPTABLES -A FORWARD -d 69.25.21.221 -j LOG
$IPTABLES -A FORWARD -d 69.25.21.221 -j DROP

R.

Odněkud se ten spam posílat musí, ne? :)

Osetruje nejak Hamachi TCP komunikaci jdouci pres UDP tunel? Protoze pokud si pamatuju, tak na UDP se muzou data vesele ztracet a sitove prvky s tim nic delat nebudou, naproti tomu v TCP by se data stracet nemela.

P.S.: Pokud si Hamachi zajistuje bespecnost TCP sama, pak by mne zajimalo jak vyrazne je spozdeni pri urcitem objemu dat a chybovosti kanalu.

Ak sa v UDP tuneli strati nejaky paket z TCP spojenia, zabezpeci jeho opatovne poslanie IP stack OS. VPN sa o to nemusi starat.

TCP nad UDP čelí podobným problémům jako TCP nad IP.

Od toho, aby se ztracené pakety poslaly znovu, je tam právě to TCP. Naopak, ve většině případů je špatný nápad tunelovat TCP přes TCP tunel, protože to může ve finále způsobit víc škody než užitku (google na toto téma vyhledá řadu odborných článků). Jakýkoliv tunel by se neměl snažit o zlepšování spolehlivosti spojení, nad kterým běží, měl by spíš usilovat o to, aby vlastnosti tunelu byly co nejpodobnější vlastnostem tohoto spoje.

Ztrácí se pakety v UDP i TCP. Jediný rozdíl je v tom, že koncové body (koncové, nikoliv na cestě) v případě takové ztráty pošlou paket znovu.

kto by mal zaujem tak som si odlozil linky. bohuzial, nemal som moznost ich odzkusat:
http://wippien.com/source.php
http://en.wikipedia.org/wiki/Wippien
http://www.ntop.org/n2n/
http://www.vpnhosting.cz/index.php/N2n-na-VPNHosting.cz.html
http://en.wikipedia.org/wiki/Magic_(software)
http://vtun.sourceforge.net/
http://en.wikipedia.org/wiki/NeoRouter

pre dalsich hladacov:
http://en.wikipedia.org/wiki/Special:Search?search=Hamachi&fulltext=Search

su tam aj free licencie... takze ked tu niekto kompiluje balicky pre distra, tak to urcite uzivatelia ocenia.

salam alejkum

V současnosti bych doporučil hlavně n2n, současná verze bude asi brzo vyhlášená za 1.3 final, je stabilní a rychlá jak na windows, tak na linuxu, opensource a každý si může spustit vlastní hamachi síť včetně supernode.

Problem n2n asi bude, ze Windows verze je za penize. A to je pro me problem, protoze takovouto sit bych asi potreboval hlavne na spojeni s uzivateli Windows, kdyz je potreba kratce neco nastavit, pripadne si zahrat bzflag. Jinak bych asi zustal u tradicniho OpenVPN.

I kdyz ted se divam, ze na http://www.vpnhosting.cz/index.php/N2n-na-VPNHosting.cz.html je primo vytvorene GUI, ktere se da stahnout. To je pekne.

Tak vyskusaj TeamViewer ide krasne na Windows i Mac OS X, je tam bud VPN alebo File Transfer alebo Remote Support. Po nainstalovani dostanes vlastne "cislo" a k nemu pre zaciatok 4 miestny ciselny kod, ktory sa da nastavit a zmenit. ;)

vtun neodporucuju - jeho sifrovani je bastl a jde snadno prolomit.
jinak teda cele hamachi je dost podezrele VPN ma byt PRIVATE ale v jejich podani je to spis virtual public netvork

Jak může Hamachi přidělovat adresy z rozsahu 5.0.0.0/8, když podle IANA jsou UNALLOCATED ?
viz. http://www.iana.org/assignments/ipv4-address-space/

třeba proto, že to nejsou veřejné adresy ale pouze adresy v subnetu hamachi? (za předpokladu že jsem žádný z pojmů nezprasil ;)

To ze je (ty IP 5.0.0.0/8) hamachi ma v LAN a nejsou zatim pouzivana neznamena, ze nebou a clovek na ne nemuze chtit v budoucnu komunikovat. Je to prasarna, ktera ma "obejit" kolize lokalni LAN a VPN site.
Ciste by bylo si prefix 5/8 alokovat, dokud to neudela nekdo jiny....
Taky mam podezreni, ze traffic ktery vytece na hamachi serveru, projde virtualni siti plain-text a pak se zasifruje k dalsimu klientovi. Pokud to nema nejakou group encryption, tak pak nemam jistotu, ze data nekdo na serveru nesniffuje. Podobny problem maji "anonymni" proxy.


Hujer!

Ciste by bylo si prefix 5/8 alokovat, dokud to neudela nekdo jiny....

No, myslím že získat "áčko" už dneska není tak snadné jako kdysi...

Některým z nás byla Hamachim přidělena i IPv4 adresa z rozsahu 4.0.0.0/8 ... před pár lety.

Souhlasím. Hamachi používám asi ty 3-4 roky (když to ještě byla beta, před příchodem toho "premium" módu, který byl pak pozměněn na "zdarma pro nekomerční využití"), jak na MS Windows, tak na GNU/Linux jsem byl svědkem pingů nad 200ms a podobných věcí. Tudíž na "UDP hole punching" bych nespoléhal, s nat-traverse se mi jej podařilo spustit asi na 10% sítí, které jsem testoval (z počtu 20-25 sítí). Pingy klesly na 20-30ms hned poté, co jsem nastavil přesměrování veřejných portů z routeru. Mám tedy důvod domnívat se, že celá ta síť funguje spíš na principu Skype - využívá se klientů s veřejnou IP pro propojení těch "za NATem", u kterých se přímý UDP tunel nepodaří.
Problém je v tom, že skutečně verze pro GNU/Linux je dosti archaická a ani specifikaci přesměrovaných portů neumožňuje, je tedy (mimo nouzové případy) asi lepší použít něco jako OpenVPN s bridged mode. Hamachi tudíž používám jen na MS Windows (kvůli těm portům) na hry a použití jiné VPN bych si asi nedokázal reálně představit, uživatelé na druhém konci (čti: hráči) jsou rádi za pár kliků v MS Exploreru a vysvětlovat jim nějaké nastavení šifrování VPN klienta, ...

Abych to shrnul - Hamachi bývalo hodně svižné před lety, s rostoucím počtem uživatelů je kolikrát problém se vůbec přihlásit :(

Myslim ze je zbitocne riesit ci pouzitie daneho rozsahu ipciek je korektne,co a kam hamachi posiela a ako tie data lozia na trse.Hamachi je pre bezneho uzivatela ktory chce nieco zazdielat kamaratovy a nema verejnu ipcku,nevie nahodit sftp alebo chce si zahrat nejaku hru.Instalacia je ako icq/skype, rozhranie je podobne.Proste easy.
Skor mne vystava tazka ci takyto clanok, obsahovo a rozsahovo ma byt na roote.
Ten clanok je ako prelozene howto/readme k hamachi.

Víte že můžete mít v Hamachi síti jen 16 připojených míst a poté musíte nějaké odebrat z místa kterým jste to zakládali a nebo máte smůlu a musíte celou síť zahodit a začít úplně znovu?
Je jasné, že pravděpodobně nepotřebujete být připojeni na tolika míst zároveň. Ale nová místa vznikají i připojením na 5 minut, takže se vám snadno stane, že to celé musíte zahodit a udělat si novou síť, protože ono první místo kde je možné místa odebírat už dávno nevíte kde je.
Důsledky tohoto omezení jsou špatně dokumentovány, je potřeba na to myslet předem.

Nemusí, ne - mu - sí!

OpenVPN v P2P módu (tedy ne v klient-server módu) funguje i bez veřejné IP adresy (obě strany za NATem) díky UDP hole punchingu (který je daný implicitně tím, že OpenVPN používá defaultně UDP).

Mám to vyzkoušené a ověřené, funguje to spolehlivě. Ještě jsem se nesetkal s NATem přes který bych se tak neproboural (i když se říká, že na některé NATy UDP hole punching nefunguje, já jsem se s takovým NATem opravdu nikdy nesetkal).

Stačí na jedné straně nastavit OpenVPN adresu remote na veřejnou adresu protějšího stroje co dělá NAT, to samé udělat na druhé straně, spustit na obou stranách OpenVPN a ony už se probourají ;-)

i když se říká, že na některé NATy UDP hole punching nefunguje

To je velmi prosté. Vezměte si svůj příklad. Na jaký veřejný port se odesílají packety? Na stejné číslo, jako má port soukromý. A to vše funguje jenom proto, že rozumný NAT číslo odchozího portu nemění.

A teď si představte, že za stejným NATem se najde stejný chytrák jako vy. Pokud je NAT chytrý, tak stále ještě může oběma lidem nechat sdílet veřejný port, protože se bude lišit cílová IP adresa. Ale kdyby se celá situace opakovala i za druhým NATem, nebude možné udržet mapování a jeden z NATů změní odchozí port. Přesně tohle je automaticky neřešitelná situace.

Problém by bylo možné obejít volbou jiného portu. Ale to by se nejprve obě strany musely dohodnout. A na to už je třeba třetí strany s veřejnou adresou.

Na to aby se obě strany dohodly by možná stačilo, aby jen na obou stranách běžel nějaký skriptík, který by to propojil s Jabber sítí. Získali by jsme tím něco podobného jako Hamachi.

Nevíte někdo náhodou, jestli už to někdo neudělal?

Teda Hamachi sem instaloval na dost PC a nevím nic o tom že by měnilo DNS, nemá k tomu žádnej důvod

VLASTNÍ VPN si představuju dost jinak, než vázanou na server provozovaný kdoví kým a bežící na nejistém proprietárním SW... na základní zajišťění konektivity OK, ale tak akorát na hry nebo něco nedůležítého, jinak tady to PRIVATE ze zkraty VPN poněkud ztrácí význam...

Je mozne rozbehat neco podobne (vpn) na dev androidovi? ma nekto vedomosti?

NanoPhone, ale nezkoušel jsem, Androida nemám.

THX skusim...

Nechápu jak můžete na Rootu vyzdvihovat takovou uzavřenou proprietární sr*čku jako je Hamachi, vždyť to není o nic lepší než třeba Skype! Roote, Roote, jak hluboko si to klesnul :-( Hamachi má plnohodnotnou opensource alternativu - n2n. Supernode k n2n si můžete nainstalovat na vlastní server nebo je tu také veřejný supernode zdarma provozovaný na VPNHosting.cz.

Před lety to bylo docela spolehlivé na hraní po síti (Multiplayer).
Dnes se častěji ukazuje modrá šipka když spojujete dva clienty.

For je v tom že hamachi ti vytvoří vlastní sítovku, která se připojí přes server. A k němu se připojí další.

Takže pokud máš práva a sdílene data na druhém pc, stačí zadat \\ipadresa človička v hamachi a měl by jsi se na něj připojit. Stejné je to s vnc, tam zadaš IP adresu počítače z hamachi, kde ti běží vnc server a seš na pc vnc serveru

Tak nevim... zkusil jsem to nainstalovat a skoncim pri inicializaci virtualniho sitoveho adapteru na BSOD...
Nevim, mozna tomu vadi ty ostatni virtualni adaptery, mozna tomu vadi driver realne sitovky... kazdopadne dva pokusy na Viste a oba BSOD. Jeden pak na WinXP a take BSOD.
Doma jsem to uz radeji nezkousel... Kolega to jeste mozna riskne na MacOS, ale nevim jestli se odvazi pri soucasne uspesnosti...