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.
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.
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.
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.
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.
Implementacni ukazka by nebyla? Ono je krasne se tvarit, ze je vse OK, ale uvedomte si, kde konci mocnost sitove vrstvy... a ze VPN koncentrator muze byt soucasti ploche site a nikoli vasi stanice... to jako tyden budete tvrdit, ze jasne, vse je OK, ale kdyz stanice chtela data, tak na ne ma jako tyden cekat? S podobnymi principy byste se mozna uplatnil u meziplanetarnich prenosu - zkuste to Certovi navrhnout, treba Vase genitalni myslenky pouzije...:-)
Technicky nejde o zadny extra problem - pri zmene ISP staci data chvili na obou stranach bufferovat, po sestaveni noveho VPN tunelu se jede dal.
Bufferovat treba pakety TCP spojeni... super, zkuste si otevrit nejakou knizku o TCP/IP. Ufff...
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.
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)
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.
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
Ale stejně je hezké že si akademici hrají a vymýšlejí hlouposti jako IPv6 a mobilní adresy. :)
Neco podobneho si urcite myslelo spousta lidi, kdyz Vint s
Jonem pracovali na TCP/IP :-)
Je videt, ze jste podstatu problemu vubec nepochopil.... Muzete mi rici, cim a jak udrzujete persistentni "on" stav VPN tunelu pokud cestujete ruznymi ISP a tedy mate v tu chvili k dispozici ruzne moznosti dostupnosti Internetove infrastruktury? Mozna by Vam to zlatem vyvazila spousta firem... - staci nabidnout.
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.
Priznam se, ze v umisteni reklamy na "Ploty - pletivo - oplocení" hned za clanek o problematice mobility v IPv6 tusim sestym smyslem nejaky postranni umysl. Ale jaky?
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.
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?
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í.