abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
dnes 17:02 | Pozvánky

Přijďte si popovídat o open source obecně a openSUSE konkrétně s dalšími uživateli a vývojáři. Oslava nového vydání openSUSE Leap se uskuteční 16. prosince od 17:00 v nových prostorách firmy SUSE v Praze. K dispozici bude nějaké občerstvení a DVD pro ty, kdo je sbírají nebo ještě mají mechaniku. Po párty v kanceláři se bude pokračovat v některé z hospod v okolí.

Miška | Komentářů: 1
dnes 14:55 | Zajímavý software

Byla vydána verze Alpha 1.0 otevřeného operačního systému pro chytré hodinky AsteroidOS. Podporovány jsou hodinky LG G Watch, LG G Watch Urbane, Asus ZenWatch 2 a Sony Smartwatch 3. Ukázka ovládání hodinek na YouTube. Jaroslav Řezník přednášel o AsteroidOS na chytrých hodinkách (videozáznam) na letošní konferenci OpenAlt.

Ladislav Hagara | Komentářů: 0
dnes 13:30 | Zajímavý software

Byly uvolněny zdrojové kódy známé rogue-like hry DoomRL. Počátky hry jsou v roce 2002. Je napsána ve FreePascalu a zdrojový kód je nyní k dispozici na GitHubu pod licencí GNU GPL 2.0. Autor pracuje na nové hře Jupiter Hell, která je moderním nástupcem DoomRL a na jejíž vývoj shání peníze prostřednictvím Kickstarteru.

Blaazen | Komentářů: 0
dnes 13:15 | Pozvánky

Přijďte s námi oslavit vydání Fedory 25. Na programu budou přednášky o novinkách, diskuse, neřízený networking atd. Release Party se bude konat 16. prosince v prostorách společnosti Etnetera. Na party budou volně k dispozici také propagační materiály, nová DVD s Fedorou 25 a samozřejmě občerstvení. Přednášky budou probíhat v češtině. Pro více informací se můžete podívat na web MojeFedora.cz. Jen připomínám, že tentokrát jsme zavedli

… více »
frantisekz | Komentářů: 0
včera 16:38 | Komunita

Byly zveřejněny videozáznamy přednášek a workshopů z letošní konference OpenAlt konané 5. a 6. listopadu v Brně. K videozáznamům lze přistupovat ze stránky na SuperLectures nebo přes program konference, detaily o vybrané přednášce nebo workshopu a dále kliknutím na ikonku filmového pásu. Celkově bylo zpracováno 65 hodin z 89 přednášek a workshopů.

Ladislav Hagara | Komentářů: 0
včera 11:30 | Komunita

Bylo oznámeno, že bude proveden bezpečnostní audit zdrojových kódů open source softwaru pro implementaci virtuálních privátních sítí OpenVPN. Audit provede Matthew D. Green (blog), uznávaný kryptolog a profesor na Univerzitě Johnse Hopkinse. Auditována bude verze 2.4 (aktuálně RC 1, stabilní verze je 2.3.14). Audit bude financován společností Private Internet Access [reddit].

Ladislav Hagara | Komentářů: 4
včera 06:00 | Komunita

Na YouTube byl publikován Blender Institute Reel 2016, ani ne dvouminutový sestřih z filmů, které vznikly za posledních 10 let díky Blender Institutu. V institutu aktuálně pracují na novém filmu Agent 327. Dění kolem filmu lze sledovat na Blender Cloudu. Videoukázka Agenta 327 z června letošního roku na YouTube.

Ladislav Hagara | Komentářů: 0
včera 01:02 | Zajímavý článek

Minulý týden byly vydány verze 1.2.3 a 1.1.7 webového poštovního klienta Roundcube. V oznámení o vydání bylo zmíněno řešení bezpečnostního problému nalezeného společností RIPS a souvisejícího s voláním funkce mail() v PHP. Tento týden byly zveřejněny podrobnosti. Útočník mohl pomocí speciálně připraveného emailu spustit na serveru libovolný příkaz. Stejně, jak je popsáno v článku Exploit PHP’s mail() to get remote code execution z roku 2014.

Ladislav Hagara | Komentářů: 1
8.12. 16:00 | Nová verze

Byla vydána verze 0.98 svobodného nelineárního video editoru Pitivi. Z novinek lze zmínit například přizpůsobitelné klávesové zkratky. Videoukázka práce s nejnovější verzí Pitivi na YouTube.

Ladislav Hagara | Komentářů: 1
8.12. 15:00 | Zajímavý software

Stop motion je technika animace, při níž je reálný objekt mezi jednotlivými snímky ručně upravován a posouván o malé úseky, tak aby po spojení vyvolala animace dojem spojitosti. Jaký software lze pro stop motion použít na Linuxu? Článek na OMG! Ubuntu! představuje Heron Animation. Ten bohužel podporuje pouze webové kamery. Podpora digitálních zrcadlovek je začleněna například v programu qStopMotion.

Ladislav Hagara | Komentářů: 5
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 808 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně

24.8.2014 02:28 vidim
OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně
Přečteno: 617×
Ahoj, na server se připojuji přes tun rozhraní a protokol udp. Problém je, že když se z klienta připojím na server, pak spojení po chvíli přestane fungovat a na klientovi vidím že nelze doručit udp datagramy (vypisuje openvpn klient) a na serveru v logu ping-restart. Po chvíli se klient znovu připojí a pak už to funguje stabilně. Zde jsou konkrétní nastavení:
server:
...
inactive 86400
max-clients 10
keepalive 5 60
...

klient:
...
nobind
keepalive 5 60
ping-timer-rem
persist-tun
persist-key
...
Zbytek konfigurace se týká hlavně zapnutí komprese, certifikátů a šifer. V čem může být problém?

Řešení dotazu:


Odpovědi

24.8.2014 02:30 vidim
Rozbalit Rozbalit vše Re: OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně
Konkrétně na klientovi se objevuje: "write UDPv4: Network is unreachable (code=101)".
24.8.2014 02:53 Marian Schmotzer
Rozbalit Rozbalit vše Re: OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně
Ahoj nepushujes nejake routy do openvpn ? Mono ze si prepises route a potom sa nevie dostat openvpn na server.
24.8.2014 03:11 vidim
Rozbalit Rozbalit vše Re: OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně
Spoustu, ale žádnou z nich si nepřepíšu routu na openvpn server.
24.8.2014 12:10 Marian Schmotzer
Rozbalit Rozbalit vše Re: OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně
Skor som myslel ci neprepisujes nejaku routu na lokalny router cez ktory ides na internet. Ked mas openvpn zapnute vies pingunt vpn server? Skus tcp spojenie namiesto udp ci nahodov ti to nieco nezahadzuje po ceste
24.8.2014 20:44 vidim
Rozbalit Rozbalit vše Re: OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně
Routou to být nemůže, když to ihned po připojení kompletně (dostanu se všude jak do internetu tak do vpn sítě) funguje krátkou dobu, poté se to odpojí a po nějaké době zase připojí a pak už jede stabilně. Kromě toho neroutuji nic ze subnetu kde leží můj router. Vyzkouším přepnout na tcp, ale nevím, proč by nemělo udp fungovat a zrovna jenom na poprvé. Kvalita spojení klient vs. vpn server je dobrá. Když pinguji bez vytvořeného tunelu na server, tak se pakety neztrácejí (teda občas jeden za hodně dlouhou dobu).
31.8.2014 04:41 vidim
Rozbalit Rozbalit vše Re: OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně
No tak já to vzdávám. Od té chvíle, co jsem tady položil ten dotaz, tak se ten problém neobjevil, předtím vždycky a už to nějakou dobu trvalo. Pokud se problém objeví, tak zase vzkřísím tuto diskuzi, ale zatím to vypadá že si se mnou hraje zákon schválnosti ...
7.10.2014 01:11 vidim
Rozbalit Rozbalit vše Re: OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně
Tak po nějaké době se problém znovu objevil. Nepomohlo štelování keepalive ani přepnutí na tcp. Na tcp je to vypadávání nenápadnější než při udp - tam píše unreachable, u tcp najednou přestane fungovat do ping-restart. Už vážně nevím, kde hledat. Pingoval jsem do internetu jak ze serveru, tak z klienta a spojení bylo dobré, ale openvpn stejně padal - respektive zase padnul napoprvé a stalo se, že po delší době i napodruhé.
7.10.2014 10:57 NN
Rozbalit Rozbalit vše Re: OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně
V logu ten rozpad vypada jak?
7.10.2014 12:33 vidim
Rozbalit Rozbalit vše Re: OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně
Klient:
Tue Oct  7 12:07:08 2014 Initialization Sequence Completed
Tue Oct  7 12:14:34 2014 write UDPv4: Network is unreachable (code=101)
Tue Oct  7 12:14:34 2014 write UDPv4: Network is unreachable (code=101)
Tue Oct  7 12:14:34 2014 write UDPv4: Network is unreachable (code=101)
Tue Oct  7 12:14:34 2014 write UDPv4: Network is unreachable (code=101)
Tue Oct  7 12:14:34 2014 write UDPv4: Network is unreachable (code=101)
Tue Oct  7 12:14:34 2014 write UDPv4: Network is unreachable (code=101)
Tue Oct  7 12:15:33 2014 [r.domena.cz] Inactivity timeout (--ping-restart), restarting
Tue Oct  7 12:15:33 2014 SIGUSR1[soft,ping-restart] received, process restarting
Tue Oct  7 12:15:35 2014 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Tue Oct  7 12:15:43 2014 UDPv4 link local: [undef]
Tue Oct  7 12:15:43 2014 UDPv4 link remote: [AF_INET]X.X.X.X:1194
Tue Oct  7 12:15:45 2014 [r.domena.cz] Peer Connection Initiated with [AF_INET]X.X.X.X:1194
Tue Oct  7 12:15:47 2014 Preserving previous TUN/TAP instance: tun0
Tue Oct  7 12:15:47 2014 Initialization Sequence Completed
Server nevypisuje chybu žádnou a po výpadku začíná klasicky s:
TLS: Initial packet from ...
Během výpadku jsem paralelně pingoval skze tunel a mimo přímo na server. V tunelu výsledný výpadek 74/1065 paketů, mimo vypadl pouze 1/1065.
7.10.2014 12:40 vidim
Rozbalit Rozbalit vše Re: OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně
Ale objevil jsem konečně v tom přímém pingu na server zajímavost, celý výpadek začíná po: "ping: sendmsg: Network is unreachable". Ale klasicky to způsobí výpadek jednoho pingu a fyzicky jsem nikdy výpadek nepostřehl (proč se tak děje nevím - ovladače, networkmanager v kde ... ?). Tak nevím, proč zrovna toto vadí openvpn tunelu. Ten by měl snad být proti tomuhle odolný ne?
7.10.2014 17:19 trubicoid
Rozbalit Rozbalit vše Re: OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně
ten Network is unreachable mas na klientovi? jakou on ma sitovku? vidis neco v dmesg?

me to delalo u notebooku s intel wifi, problem byl s firmwarem, musel jsem dat starsi, v dmesg bylo neco jako

Sep 20 19:35:28 [kernel] [ 2038.990586] wlp24s0: associated

Sep 20 19:35:28 [kernel] [ 2038.990746] wlp24s0: deauthenticating from X by local choice (Reason: 3=DEAUTH_LEAVING)

Sep 20 19:35:32 [kernel] [ 2042.997788] wlp24s0: authenticate with X

Sep 20 19:35:32 [kernel] [ 2042.999318] wlp24s0: send auth to X (try 1/3)

Sep 20 19:35:32 [kernel] [ 2043.000350] wlp24s0: authenticated

Sep 20 19:35:32 [kernel] [ 2043.001060] wlp24s0: associate with X (try 1/3)

Sep 20 19:35:32 [kernel] [ 2043.002929] wlp24s0: RX AssocResp from X (capab=0x411 status=0 aid=6)

Sep 20 19:35:32 [kernel] [ 2043.007153] wlp24s0: associated

a tak porad dokola
7.10.2014 21:58 vidim
Rozbalit Rozbalit vše Re: OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně
02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 34)
Ale v dmesg nevidím odpojování. S tím jsem míval problémy kdysi také na intel wifi síťovce, kde ale paradoxně openvpn tohle přežívalo v pohodě (i když byly výpadky delší).

Nicméně podle syslog se zdá, že v tu dobu se obnovovala IP adresa z DHCP serveru. To NetworkManager neumí obnovu bez výpadku?
Oct  7 12:14:29 vidim-notebook NetworkManager[1391]: <info> (wlan0): DHCPv4 state changed renew -> expire
Oct  7 12:14:29 vidim-notebook dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 3 (xid=0x7820b435)
Oct  7 12:14:29 vidim-notebook NetworkManager[1391]: <info> (wlan0): DHCPv4 state changed expire -> preinit
Oct  7 12:14:32 vidim-notebook dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8 (xid=0x7820b435)
Oct  7 12:14:34 vidim-notebook dhclient: DHCPREQUEST of 192.168.54.33 on wlan0 to 255.255.255.255 port 67 (xid=0x7820b435)
Oct  7 12:14:34 vidim-notebook dhclient: DHCPOFFER of 192.168.54.33 from 192.168.54.1
Oct  7 12:14:34 vidim-notebook kernel: [682278.099693] [UFW BLOCK] IN=wlan0 OUT=wlan0 MAC=6c:88:14:55:34:80:00:0d:b9:0d:3e:5c:08:00 SRC=192.168.54.1 DST=192.168.54.33 LEN=389 TOS=0x10 PREC=0x00 TTL=127 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=369 
Oct  7 12:14:34 vidim-notebook kernel: [682278.189984] [UFW BLOCK] IN=wlan0 OUT=wlan0 MAC=6c:88:14:55:34:80:00:0d:b9:0d:3e:5c:08:00 SRC=192.168.54.1 DST=192.168.54.33 LEN=389 TOS=0x10 PREC=0x00 TTL=127 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=369 
Oct  7 12:14:34 vidim-notebook dhclient: DHCPACK of 192.168.54.33 from 192.168.54.1
Oct  7 12:14:34 vidim-notebook NetworkManager[1391]: <info> (wlan0): DHCPv4 state changed preinit -> bound
Oct  7 12:14:34 vidim-notebook NetworkManager[1391]: <info>   address 192.168.54.33
Oct  7 12:14:34 vidim-notebook NetworkManager[1391]: <info>   prefix 24 (255.255.255.0)
Oct  7 12:14:34 vidim-notebook NetworkManager[1391]: <info>   gateway 192.168.54.1
Oct  7 12:14:34 vidim-notebook NetworkManager[1391]: <info>   nameserver '192.168.54.1'
Oct  7 12:14:34 vidim-notebook NetworkManager[1391]: <info>   domain name 'in.X.net'
Oct  7 12:14:34 vidim-notebook dhclient: bound to 192.168.54.33 -- renewal in 1710 seconds.
Oct  7 01:26:37 vidim-notebook avahi-daemon[1051]: message repeated 2 times: [ Withdrawing workstation service for tun0.]
Oct  7 12:14:34 vidim-notebook avahi-daemon[1051]: Withdrawing address record for 192.168.54.39 on wlan0.
Oct  7 12:14:34 vidim-notebook avahi-daemon[1051]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 192.168.54.39.
Oct  7 12:14:34 vidim-notebook avahi-daemon[1051]: Interface wlan0.IPv4 no longer relevant for mDNS.
Oct  7 12:14:34 vidim-notebook avahi-daemon[1051]: Joining mDNS multicast group on interface wlan0.IPv4 with address 192.168.54.33.
Oct  7 12:14:34 vidim-notebook avahi-daemon[1051]: New relevant interface wlan0.IPv4 for mDNS.
Oct  7 12:14:34 vidim-notebook avahi-daemon[1051]: Registering new address record for 192.168.54.33 on wlan0.IPv4.
Oct  7 12:14:35 vidim-notebook NetworkManager[1391]: <info> Policy set 'mojewifi' (wlan0) as default for IPv4 routing and DNS.
Oct  7 12:14:35 vidim-notebook dbus[1011]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
Oct  7 12:14:36 vidim-notebook dbus[1011]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
7.10.2014 22:01 vidim
Rozbalit Rozbalit vše Re: OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně
Ještě to raději zkusím bez firewallu na klientovi, protože to vypadá na blokaci DHCP renewalu, ale nakonec to projde tak nevím.
7.10.2014 22:08 vidim
Rozbalit Rozbalit vše Re: OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně
Tak ne, i bez zapnutého firewallu se to děje. Zajímavé je, že z DHCP dostávám pokaždé jinou IP a zajímavé, že se to děje až po openvpn připojení. Druhý dhcp server v síti není a openvpn jede přes tun, tudy broadcasty neprolezou ...
8.10.2014 11:24 trubicoid
Rozbalit Rozbalit vše Re: OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně
asi je teda divny to dhcp nebo networ manager, neumi ten networ manager i primo openvpn? ze by se to pak treba netlouklo

ja mel problem s openvpn serverem v bridge mode, tam nejak to br0 nekdy nemelo stejny MAC jako eth0 a tim padem server dostaval jiny IP, ne to pro nej rezervovany pres MAC

ted uz to nedela, MAC je stejny a IP dostavam spravny, asi byla nekde chybka a opravili ji

9.10.2014 01:15 vidim
Rozbalit Rozbalit vše Re: OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně
Když navážu tunel přímo pomocí NetworkManager, tak to spadne za chvíli také. Žádná změna. S mac adresy problém není, alespoň "ip link" vypisuje pořád stejné.
9.10.2014 01:27 vidim
Rozbalit Rozbalit vše Re: OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně
Zajímavý je ale log z mého dhcp serveru:
Oct  9 00:56:50 rimmer dhcpd: DHCPDISCOVER from 6c:88:14:55:34:80 via eth0.1
Oct  9 00:56:50 rimmer dhcpd: ICMP Echo reply while lease 192.168.54.35 valid.
Oct  9 00:56:50 rimmer dhcpd: Abandoning IP address 192.168.54.35: pinged before offer
Oct  9 00:56:53 rimmer dhcpd: DHCPDISCOVER from 6c:88:14:55:34:80 via eth0.1
Oct  9 00:56:55 rimmer dhcpd: DHCPOFFER on 192.168.54.43 to 6c:88:14:55:34:80 (vidim-notebook) via eth0.1
Oct  9 00:56:55 rimmer dhcpd: Added new forward map from vidim-notebook.dyn.X.net to 192.168.54.43
Oct  9 00:56:55 rimmer dhcpd: added reverse map from 43.54.168.192.in-addr.arpa to vidim-notebook.dyn.X.net
Oct  9 00:56:55 rimmer dhcpd: DHCPREQUEST for 192.168.54.43 (192.168.54.1) from 6c:88:14:55:34:80 (vidim-notebook) via eth0.1
Oct  9 00:56:55 rimmer dhcpd: DHCPACK on 192.168.54.43 to 6c:88:14:55:34:80 (vidim-notebook) via eth0.1
Přijde mi to ale jako nelogické chování - proč odmítat opětovně přidělit IP, která je moje? Nebo se můj dhcp klient špatně ptá a server reaguje korektně?
9.10.2014 08:44 trubicoid
Rozbalit Rozbalit vše Re: OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně
on ti ji neperideli, protoze na ni pingne a je uz obsazena

nebezi na klientu dva dhcp klienti, co se perou?

jinak muzes zakazat v serveru ten ping-check
7.10.2014 17:00 Milan Roubal | skóre: 25
Rozbalit Rozbalit vše Re: OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně
nerozchazi se cas mezi klientem a serverem?
7.10.2014 21:59 vidim
Rozbalit Rozbalit vše Re: OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně
Ne, na obou běží ntpd a čas je OK.
2.11.2014 01:14 vidim
Rozbalit Rozbalit vše Re: OpenVPN spojení vždy po chvívi napoprvé vypadne, po znovupřipojení funguje normálně
Tak problém jsem vyřešil zabitím dhcp klienta po probuzení z režimu spánku, po tomto ho totiž networkmanager spustí znova a ten okamžitě chce novou IP adresu a dostane se ta správná a pak už to funguje dobře.

Pro ty, kdo by se potýkal s tím samým. Distribuce Kubuntu 14.04, řešení:
vytvořit skript např. /etc/pm/sleep.d/99_kill_dhclient s obsahem:

#!/bin/bash
case "$1" in
    hibernate|suspend)
        echo ""
        ;;
    thaw|resume)
        killall dhclient
        ;;
    *)
        ;;
esac
exit $?

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.