Vlákno názorů k článku Změní se význam adresy? od Ondra - Koneckonců, vyzkoušejte si to na Hamachi. Mam v...

Koneckonců, vyzkoušejte si to na Hamachi. Mam v okolí víc Wifi providerů a změna providera nezpůsobí žádné problémy aplikacím, které jedou přes toto VPN

Tak si zkuste stáhnou Hamachi (www.hamachi.cz). Přes tohle VPN udržím všechna spojení i když přehodím providera na wifině (pokud to stihnu do vypršení timeoutů, což jsou řádově minutu)

Týden je samozřejmě blbost.

Souhlas se Zdenkem i Davidem Rohlederem.

TCP spojení je identifikováno zdrojovou adresou + portem a cílovou adresou + portem. K jeho provozu jsou dále potřeba na obou stranách i další důležité stavové údaje, např. stav TCP spojení, SEQ čísla, MSS, RTT, retransmit timer, TX fronta, aj.

Žádný údaj klíčový pro udržení TCP spojení se při změně ISP nezmění. Fyzickou adresu notebooku na cestách totiž skrývá VPN tunel, aplikace jako WWW browser nebo SSH klient si díky tunelu myslí, že interface síťové karty notebooku je ten obvyklý, z domácí sítě. Ničeho si nevšimnou.

Tyto hrátky mohou mít hluboký smysl, souhlas!

Já jen chci říct, že místo složité přestavby IPV6 lze řešit věc tím, že vhodně implementuju VPN tunel. A může to jet klidně po IPV4.

Představme si to tak, že svůj počítač kdesi ve světě s mou domácí sítí bude spojen přes X VPN tunelů současně (z každé aktuálně dostupné sítě jeden tunel). Je-li k dispozici jeden nebo více funkčních tunelů, použije se kterýkoli a různé části tohotéž TCP spojení tečou třeba i různými tunely. Jakmile ale není k dispozici žádný funkční tunel, spojení, která mají nastaven TCP keepalive nebo aplikační timeouty, popadají.

Já jsem v ssh nic nenastavoval. To je nastavení TCP keepalivů.

Vy jste asi natvrdej, nebo co.. Když něco funguje o úroveň výše, tak to logicky současně funguje i na všech nižších úrovních, protože SSH žádné nízkoúrovňové triky nepoužívá.

Pokud SSH vydrží hodiny bez spojení, je to díky tomu že v okamžiku shození linky 1) mezi klientem a serverem nebyly žádné neACKnuté TCP segmenty 2) v době výpadnu klient ani server nic neposílali 3) byl vypnut TCP keepalive 4) byl vypnutý SSH keepalive. Při vhodné modifikaci VPN tunelu lze dokonce restrikce 1) až 3) obejít.

Absolutně bez problémů, timeouty se dají nastavit různě, co mne dokáže vytočit je nastavení timeoutů na příliš krátkou dobu, tak jak to mají např. Windows a při každém kratičkém výpadku jde spojení do kytek.

IMHO je to opravdu podle toho popisu celkem realizovatelné, VPN tunel je přece jenom vnější obálka, která se aplikací vůbec netýká.

Mně osobně třeba vydrží ssh session klidně i 2 hodiny bez připojení, a po obnovení konektivity jede vše OK. Je to sice triviální případ, kdy stačí mít vhodně nastavené keepalive pakety, ale i ten zbytek by šel určitě vyřešit.

A vy prosim zkuste v technicke diskusi vynechat osobni invektivy.

To by asi neklaplo, viz predchozi reakce, drtiva vetsina aplikaci vyzaduje nejakou reakci, ktere se jaksi takto nedocka. Osobne ani neznam mnoho aplikaci, ktere by dokazaly komunikovat timto zpusobem.

To uz vubec nezminuji bezpecnostni diru, kterou jste prave vytvoril. Timeout je prave od toho aby vyprsel a ne od toho aby se oblboval. Prave z toho duvodu si aplikace zjistuji zda skutecne dochazi ke komunikaci a kdyz ne, tak spojeni proste utnou. Chudak ten, kdo by mel poskytovat takto nejakou sluzbu, sem zvedav jak si hodlate poradit s omezenymi zdroji a omesit pocet konexi, kdyz je podle vas naprosto vporadku je takto udrzovat.

Implementační ukázka: proč? Dneska je beztak všechno bezstavové nebo plně restartovatelné, takže nějaká perzistence TCP session je vcelku šumafuk. Zbytek Vašeho příspěvku nestojí za reakci.

Proč by VPN klient a VPN koncentrátor nemohli utnout tunel, a přitom se před aplikacemi tvářit že spojení dál existuje? TCP jde oblbnout vcelku lehce- pošlu fake ACKy které nastaví WINSZ 0, takže všechno pozastavím a bufferovat se bude minimum. Až se spojení obnoví, obnovím původní hodnoty a výměna dat se zase rozběhne. Pokud to někdo používá, lze průběžně posílat i fake TCP keepalive.

Samozřejmě tím nevyřeším timeouty které se zhusta používají na aplikační úrovni, ale to rozhodně nejde považovat za neodstranitelný nedostatek IPv4 protokolu.

To, ze VPN tunel neni persistentni, je pouze nedostatek v jeho implementaci. Technicky nejde o zadny extra problem - pri zmene ISP staci data chvili na obou stranach bufferovat, po sestaveni noveho VPN tunelu se jede dal.

To, o cem pise Pavel Satrapa, je dost akademicke, viz posledni odstavec clanku. Vylepsit existujici VPN tunely je mnohem snazsi reseni.

Btw: Je zde pripadna analogie s "letitymi" GSM sitemi. Volam vzdy jedinecne cislo daneho ucastnika (zadny smerovaci prefix), agent (domaci operator volaneho ucastnika) zajisti propojeni do cilove site (domaci sit nebo roaming), a to i za cenu delsi trasy smerovani hovoru. Zajimave je, ze v ramci pokryti jedne site se mobil muze pohybovat po velkem prostoru (handover mezi bunkami), ale nelze provest handover mezi sitemi ruznych operatoru. Pusobi to ale snad nekomu vetsi potize?

Vzhledem k tomu že konektivita mezi domácí bránou a internetem je zhruba o 2 řády lepší (a levnější) než ta z mobilního přístupového bodu tak dvojí routing nepředstavuje absolutně žádný problém.

Ano, perzistentní to není (i když by principielně mohlo být). Pro mobilní a perzistentní přístup zatím potřebuji něco jako remote desktop. Ale stejně by perzistentní mobilita byla k ničemu, protože obvyklá doba přesunu z jedné internetové kavárny do druhé je podstatně delší než TCP timeouty, takže bych stejně schytal RST.

Nemluve o tom, ze takto veskera data bezi nejdrive na domaci branu a posleze naprosto zbytecne zpet kamsi do neznama. Kdezto kdyby klient vedel kde mobilni stanice je (znal jeji aktualni IP), komunikoval by primo.

Bez nejmenších problémů používám na cestách pevnou IP adresu, dokonce z vnitřní sítě. VPN tunel funguje, klient je pro Windows i Linux.

Ale stejně je hezké že si akademici hrají a vymýšlejí hlouposti jako IPv6 a mobilní adresy. :)

To snad ted jeste nejde ne? Musim mit adresu, ze site ke ktere se pripojuji.