Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: Martin 27. 08. 2010, 15:28:39
-
Mam asi 150 klientu s timto nastavenim:
remote domena.tld
port 5000
tls-client
dev tap
pull
mute 10
ca xxx.pem
cert xxx.pem
key xxx.pem
comp-lzo
verb 3
#vista patch
route-method exe
route-delay 2
bezi to tedy na protokolu UDP. pouzivam to vyhradne pro VNC administraci, bohuzel vsak zjistuji ze ve srovnani s Hamachi se to chova priserne... obrovsky pocet packet loss. Logika mi tedy rika prejit na TCP.
Problem nastal, kdyz zjistuji ze bych do clienta musel pridat radek: proto tcp-client
Lze to udelat nejak autoamticky? napriklad pres push? nebo nejaky redirect? Jsem pro jakykoli reseni, hromadna zmena nepripada v uvahu, hlavne proto ze vsichni klienti nejsou pripojeni a v dohledne dobe ani nebudou.
Pomuze vubec zmena na TCP u packet loss ?
Nakonec mam tedy zalozni plan, ktery pocita s 2 mi sitemi a postupnym nenucenym prechodem... ale radeji bych nejakou automatiku.
Diky za rady i pripominky k jinym vecem ohledne konfigurace.
-
VNC samo o sobe jede prec TCP, takze tim ze budes tunelovat TCP skrz TCP si asi moc nepomuzes.
-
Pomuze vubec zmena na TCP u packet loss ?
Ne, bude to ještě horší. (Pokud tedy packet loss na UDP není vyvoláván uměle za účelem znevýhodnění UDP protokolu proti TCP).
-
Ne, bude to ještě horší. (Pokud tedy packet loss na UDP není vyvoláván uměle za účelem znevýhodnění UDP protokolu proti TCP).
a prave si myslim ze to bude jeden z problemu
Hlavne si nedokazu vysvetlit proc openvpn ma 80% packet loos a Hamachi 0%.
A co se tyce TCP packetu VNC, ty se schovaji prece do UDP packetu toho tunelu ne?
-
Tak ted jsem mel moznost otestovat na lince CDMA od O2. vypada to asi takto:
openvpn:
Odpověď od 10.0.1.30: bajty=32 čas=86ms TTL=127
Odpověď od 10.0.1.30: bajty=32 čas=104ms TTL=127
Odpověď od 10.0.1.30: bajty=32 čas=113ms TTL=127
Odpověď od 10.0.1.30: bajty=32 čas=102ms TTL=127
Odpověď od 10.0.1.30: bajty=32 čas=101ms TTL=127
Odpověď od 10.0.1.30: bajty=32 čas=89ms TTL=127
Odpověď od 10.0.1.30: bajty=32 čas=97ms TTL=127
Vypršel časový limit žádosti.
Vypršel časový limit žádosti.
Vypršel časový limit žádosti.
Vypršel časový limit žádosti.
Odpověď od 10.0.1.30: bajty=32 čas=169ms TTL=127
Odpověď od 10.0.1.30: bajty=32 čas=98ms TTL=127
Odpověď od 10.0.1.30: bajty=32 čas=96ms TTL=127
Odpověď od 10.0.1.30: bajty=32 čas=83ms TTL=127
Odpověď od 10.0.1.30: bajty=32 čas=82ms TTL=127
Vypršel časový limit žádosti.
Vypršel časový limit žádosti.
Vypršel časový limit žádosti.
Vypršel časový limit žádosti.
Vypršel časový limit žádosti.
Vypršel časový limit žádosti.
Vypršel časový limit žádosti.
Vypršel časový limit žádosti.
Odpověď od 10.0.1.30: bajty=32 čas=211ms TTL=127
Odpověď od 10.0.1.30: bajty=32 čas=308ms TTL=127
Odpověď od 10.0.1.30: bajty=32 čas=136ms TTL=127
Odpověď od 10.0.1.30: bajty=32 čas=87ms TTL=127
Odpověď od 10.0.1.30: bajty=32 čas=106ms TTL=127
Odpověď od 10.0.1.30: bajty=32 čas=105ms TTL=127
Odpověď od 10.0.1.30: bajty=32 čas=95ms TTL=127
Odpověď od 10.0.1.30: bajty=32 čas=100ms TTL=127
Odpověď od 10.0.1.30: bajty=32 čas=98ms TTL=127
Vypršel časový limit žádosti.
Vypršel časový limit žádosti.
Vypršel časový limit žádosti.
Vypršel časový limit žádosti.
Vypršel časový limit žádosti.
Vypršel časový limit žádosti.
Vypršel časový limit žádosti.
Odpověď od 10.0.1.30: bajty=32 čas=172ms TTL=127
Odpověď od 10.0.1.30: bajty=32 čas=118ms TTL=127
Vypršel časový limit žádosti.
a hamachi:
Odpověď od x.x.x.x: bajty=32 čas=92ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=81ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=108ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=85ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=83ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=82ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=81ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=79ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=77ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=95ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=84ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=90ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=90ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=77ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=96ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=84ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=95ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=78ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=96ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=94ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=91ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=151ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=89ms TTL=128
Odpověď od x.x.x.x: bajty=32 čas=78ms TTL=128
prechod na TCP bohuzel nepomhl :) Nevite nekdo co s tim ??
-
Beru zpet predchozi prispevek, spatne jsem to testoval, je to funkcni.
Uz zbyva tedy jen otazka jak resit tu hromadnou zmenu ?
-
Uz zbyva tedy jen otazka jak resit tu hromadnou zmenu ?
Nedelat ji. Domluvit se s tim, kdo UDP zahazuje, popr. zmenit providera.
TCP over TCP je zlo.
http://www.mail-archive.com/gnhlug-discuss@mail.gnhlug.org/msg19655.html
Mimo to, jestli to pouzivas jenom pro tunelovani VPN, neni lepsi pouzit ad hoc ssh tunel?
-
Nepouzivaji nahodou dva klienty stejny klic?
-
Nepouzivaji nahodou dva klienty stejny klic?
ano pouzivaji, je to problem?
-
Nedelat ji. Domluvit se s tim, kdo UDP zahazuje, popr. zmenit providera.
TCP over TCP je zlo.
http://www.mail-archive.com/gnhlug-discuss@mail.gnhlug.org/msg19655.html
Mimo to, jestli to pouzivas jenom pro tunelovani VPN, neni lepsi pouzit ad hoc ssh tunel?
Musim mit pristup k nekolika sluzbam, takze obecny IP tunel mi prijde vhod.
Dohoda s ISP neni mozna, jelikoz kazdy ma jineho ISP, resit jeste toto, zblaznim se...
Mozna ze TCP over TCP je zlo, ale prozatim funguje neporovnatelne lepe, tezko rict jestli je to opravdu tim.
-
Ano, je :) To je ten duvod, proc to chvilku jede, chvilku nejede. Bud to musite explicitne povolit v konfiguraci serveru nebo se klienti pretahuji a pak jeden navaze spojeni a druhy vypadne, nacez druhy zacne navazovat spojeni (a navaze) a vykopne toho prvniho.
-
Ano, je :) To je ten duvod, proc to chvilku jede, chvilku nejede. Bud to musite explicitne povolit v konfiguraci serveru nebo se klienti pretahuji a pak jeden navaze spojeni a druhy vypadne, nacez druhy zacne navazovat spojeni (a navaze) a vykopne toho prvniho.
a nejedna se o: duplicate-cn ?
projistotu prikladam konfiguraci serveru:
mode server
tls-server
local doemna.tld
port 5000
dev tap0
ifconfig 10.0.1.100 255.255.255.0
ifconfig-pool 10.0.1.1 10.0.1.90 255.255.255.0
duplicate-cn
ca /etc/openvpn/cacert.pem
cert /etc/openvpn/cert.pem
key /etc/openvpn/key.pem
dh /etc/openvpn/dh1024.pem
log-append /var/log/openvpn/xxx
status /var/run/openvpn/xxx 10
#route na qsoft
push "route 10.0.2.0 255.255.255.0 10.0.1.100"
user nobody
group nogroup
comp-lzo
verb 3
keepalive 10 120
persist-key
persist-tun
-
Dohoda s ISP neni mozna, jelikoz kazdy ma jineho ISP, resit jeste toto, zblaznim se...
Jestli ono to nebude u ISP na cestě ke koncentrátoru VPN, kterou procházejí všichni. Běžní provideři UDP příliš neomezují. Jako road warrior se připojuji z různých míst na standardní port udp/1194 a téměř nikdy nemám problém. Pokud ano, použiju ssh -D.
-
Tak jsem zase tu, po par mesicich provozu tunelu pres TCP je to radikalne lepsi avsak je to porad horsi nez Hamachi.
Nenapada Vas zpusob jak to zlepsit? Dela to hlavne u WIFI spojeni, ktere maji packet loss.
Napada me snizit delku sifrovani, popripade jej uplne vypnout, snizit velikost packetu nebo tak neco... je to mozne?
Popripade poradte uplne jiny VPN system na stejnym principu? (PC->SERVER)
-
pokud akceptujete nesifrovani, a pripadne to provozujete pres hamachi - muzete jeste zkusit n2n tunel - pred nedavnem tady nebo na abc byl clanek.
-
pokud akceptujete nesifrovani, a pripadne to provozujete pres hamachi - muzete jeste zkusit n2n tunel - pred nedavnem tady nebo na abc byl clanek.
Potvrzuju N2N je něco jako hamachi, ale open source a funguje obstojně. Jeho nevýhodou může být to, že pokud neproleze přes NATy, tak není jiná šance jak se spojit, což si myslím, že by u klasické VPN mělo jít aspoň oklikou relayovat přes server
-
Ano, je :) To je ten duvod, proc to chvilku jede, chvilku nejede. Bud to musite explicitne povolit v konfiguraci serveru nebo se klienti pretahuji a pak jeden navaze spojeni a druhy vypadne, nacez druhy zacne navazovat spojeni (a navaze) a vykopne toho prvniho.
Takze nakonec uznavam ze jste mel pravdu. Cim vice klientu v jedne siti je tim horsi je stav.
parametr: duplicate-cn v konfiguraci mam
Netusite nekdo jak tento problem odstranit?
-
Tak uz mam castecne odpoved. OS se instaluje z image, takze vsechny TAP zarizeni maji stejnou MAC, tim se pretahujou o spojeni.
Zatim se mi bohuzel nepodarilo vygooglovat jak toto obejit.
-
Tak uz mam castecne odpoved. OS se instaluje z image, takze vsechny TAP zarizeni maji stejnou MAC, tim se pretahujou o spojeni.
Zatim se mi bohuzel nepodarilo vygooglovat jak toto obejit.
Bohuzel se mi stale nepodarilo zjistit jak ignorovat MAC a identifikaci prevest treba na interneni IP, tak aby TAP adapter zustal. Dokonce sem se dival i do zdrojaku openvpn.
Jediny provizorni reseni co me napada je do updatu softwaru pridat skript na pregenerovani MAC (odinstalovat a nainstalovat novy TAP adapter). Bohuzel vsak reseni neni 100% ni(aktualizuje jen nektere klienty) a je jeste potencionalne nebezpecne (v nekterych SW vyskakuje varovna hlaska nepodapsaneho ovladace, kterou uzivatel nemusi odkliknout, pak ztrati TAP adapter).
Nejake napady? Diky
-
Rozhodne bych si vygeneroval ruzne klice pro klienty, adresar ccd pro prirazeni pevne IP, rozhodne UDP, zajimave parametry na serveru max-clients a txqueuelen, rozhodne rezim route (tun) misto bridge.
-
A proč tolik zavrhujete tcp? U zákazníka jsme se pokoušeli přes mizerné linky (O2 ADSL, ale daleko od ústředny) zprovoznit OpenVPN, přes UDP vyloženě tragédie, s TCP to šlape výborně.
-
A proč tolik zavrhujete tcp?
Nejspíš proto, že TCP over TCP může dělat psí kusy ohledně congestion controll apod.