Dotaz: OpenVPN - nelze se spojit. Jinde (ok)

[power]

Snažil jsem se to vtěsnat do názvu ale pro pořádek. Mám server a 2 klienty. Server je řádně nakonfigurován a spuštěn. Klient to samé ale navzájem je nelze spojit. Bohužel jak server tak i klient v jiné síti jsou za routerem ale mají na sebe propuštěný port 1194. Co je zajímavé tak jsem udělal pokus a pokud server udělám úplně jinde na PC kde je přímo veřejně na internetu tak se na něj není problém připojit. Také opačně pokud server ponechám tam kde je (ten za tím routerem) a z toho PC na veřejným internetu udělám klienta, tak se taky spojí.

Poznámka: Na obou PC které nelze spojit byla openVPN klient-klient a ta byla bez problémů. Jenže já potřebuju na server připojit 2 sítě a routovat do nich podsítě. Proto volím možnost server-klient která ale právě mě z neznámého důvodu nejde. Přikládám logy serveru a klienta

Server

Thu Jun 21 14:44:38 2007 NOTE: --user option is not implemented on Windows
Thu Jun 21 14:44:38 2007 NOTE: --group option is not implemented on Windows
Thu Jun 21 14:44:38 2007 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct  1 2
006
Thu Jun 21 14:44:38 2007 Diffie-Hellman initialized with 1024 bit key
Thu Jun 21 14:44:38 2007 TLS-Auth MTU parms [ L:1576 D:140 EF:40 EB:0 ET:0 EL:0
]
Thu Jun 21 14:44:38 2007 TAP-WIN32 device [Připojení k místní síti 5] opened: \\
.\Global\{F79C1344-B9A4-4B84-832D-F97B4529D295}.tap
Thu Jun 21 14:44:38 2007 TAP-Win32 Driver Version 8.4
Thu Jun 21 14:44:38 2007 TAP-Win32 MTU=1500
Thu Jun 21 14:44:38 2007 Notified TAP-Win32 driver to set a DHCP IP/netmask of 1
92.168.100.1/255.255.255.0 on interface {F79C1344-B9A4-4B84-832D-F97B4529D295} [
DHCP-serv: 192.168.100.0, lease-time: 31536000]
Thu Jun 21 14:44:38 2007 Sleeping for 10 seconds...
Thu Jun 21 14:44:48 2007 NOTE: FlushIpNetTable failed on interface [196611] {F79
C1344-B9A4-4B84-832D-F97B4529D295} (status=259) : žádná další data nejsou k disp
ozici.
Thu Jun 21 14:44:48 2007 Data Channel MTU parms [ L:1576 D:1450 EF:44 EB:135 ET:
32 EL:0 AF:3/1 ]
Thu Jun 21 14:44:48 2007 Listening for incoming TCP connection on [undef]:1194
Thu Jun 21 14:44:48 2007 TCPv4_SERVER link local (bound): [undef]:1194
Thu Jun 21 14:44:48 2007 TCPv4_SERVER link remote: [undef]
Thu Jun 21 14:44:48 2007 MULTI: multi_init called, r=256 v=256
Thu Jun 21 14:44:48 2007 IFCONFIG POOL: base=192.168.100.5 size=16
Thu Jun 21 14:44:48 2007 MULTI: TCP INIT maxclients=60 maxevents=64
Thu Jun 21 14:44:48 2007 Initialization Sequence Completed

Klient

Thu Jun 21 15:14:59 2007 OpenVPN 2.0.7 i586-mandriva-linux-gnu [SSL] [LZO] [EPOLL] built on Mar 15 2007
Thu Jun 21 15:14:59 2007 WARNING: you are using user/group/chroot without persist-key/persist-tun -- this may cause restarts to fail
Thu Jun 21 15:14:59 2007 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Thu Jun 21 15:14:59 2007 LZO compression initialized
Thu Jun 21 15:14:59 2007 Control Channel MTU parms [ L:1576 D:140 EF:40 EB:0 ET:0 EL:0 ]
Thu Jun 21 15:14:59 2007 Data Channel MTU parms [ L:1576 D:1450 EF:44 EB:135 ET:32 EL:0 AF:3/1 ]
Thu Jun 21 15:14:59 2007 Local Options hash (VER=V4): '31fdf004'
Thu Jun 21 15:14:59 2007 Expected Remote Options hash (VER=V4): '3e6d1056'
Thu Jun 21 15:14:59 2007 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Thu Jun 21 15:14:59 2007 Attempting to establish TCP connection with 212.27.212.102:1194

Tím to končí

Asi jste si všimli že server běží na Woknech ale jinou možnost nemám a zjistil jsem že openVPN je narosto stejný jako v Linuxu.

Prosím pokud byste měl někdo nápad...

Dík

Odpovědi

[koulinek]

V prve rade bych zkusil tcpdump, pripadne nakou obdobu pro Windows (treba wireshark je i pro win) kdyz uvadite ze server bezi tam a zkusil bych odchytnout zda se pakety od klienta skutečne skrz ten router dostanou kam maji a neni problem nekde cestou.

[power]

Ale jak jsem psal, v modu klient-klient to fungovalo. Uvedené nástroje neznám ale zkusím je nastudovat. K čemu slouží a jak se dají lehce použít abych zjistil v čem může být chyba?

[koulinek]

Tyto nástroje slouží k inspekci síťového provozu a k následné diagnostice problémů či anomálií, pak sledovat logy, a znovu prověřit konfigurační soubory.

[dan]

Je na serveru i klientovi správně nastavený čas? Nejednou mi nešlo openvpn právě kvůli rozhašeným hodinám.

[power]

Hodiny jsou OK. Chci je spojit kvůli docházkovému systému který na obou běží takže hodiny jsou v pohodě.

[Dejv]

Ne, ze bych si byl jisty, ze poradim, ale asi by se hodil konfigurak, nejlepe obou stroju

Dejf

[power]

OK

Server

# server
mode server

# tls jako server
tls-server

# port, 1194 = default
port 1194

# protokol, tcp/udp
proto tcp-server

# nastavi zarizeni
dev tap

# adresa serveru
ifconfig 192.168.100.1 255.255.255.0

# rozsah adres pro klienty
ifconfig-pool 192.168.100.5 192.168.100.20 255.255.255.0

# soucasne prihlaseni vice klientu
duplicate-cn

# certifikat certifikacni autority
ca ca.crt

# certifikat serveru
cert server.crt

# klic serveru
key server.key

# parametry pro Diffie-Hellman protokol
dh dh1024.pem

# logy serveru
;log-append /var/log/openvpn.log

# status serveru
;status /var/run/vpn.status 10

# uzivatel pod kterym bezi server
user nobody

# skupina pod kterou bezi server
group nogroup

# udrzuje spojeni nazivu, 10 (ping) a 120 (ping-restart)
keepalive 10 120

# komprese prenasenych dat
comp-lzo

# ukecanost serveru
verb 3

Klient

# server ke kteremu se pripojujeme
remote 212.27.x.x

# tls jako klient
tls-client

# port, 1194 = default
port 1194

# protokol, tcp/udp
proto tcp-client

# nastaveni zarizeni
dev tap

# povoluje stazeni konfigurace ze severu
pull

# certifikat certifikacni autority
ca ca.crt

# certifikat klienta
cert client1.crt

# certifikat klienta
key client1.key

# uzivatel pod kterym bezi klient
user nobody

# skupina pod kterou bezi klient
group nogroup

# opakovani radku v logu
mute 10

# logy klienta
log-append /var/log/openvpn.log

# status klienta
status /var/run/vpn.status 10

# komprese prenasenych dat
comp-lzo

# ukecanost klienta
verb 3

[power]

Ještě dodám pro upřesnění že jeden z pokusů o vyloučení závady byl ten že jsem si cvičmo zkusil zpojit ve stejné síti, tak to šlo pokud jsem zadal lokální adresu ale pokud jsem v klientuvi změnil adresu na veřejnou 212.27.x.x Tak nastal ten samý problém. Vůbec to nechápu. Ani nevím co jsem tím vyloučil když tak nad tím zapřemejšlím.

[Dejv]

Tak jsem jenom tak v rychlosti znovu proletel ty logy a tu konfiguraci, a mam dotaz: mas na serveru otevreny ten TCP port 1194? Klient totiz skonci na pokusu sestavit spojeni, takze to by tomu asi odpovidalo.

Dejf

[power]

Ano mám. Ale jak jsem říkal z jiného PC se stejným nastavením (konfigurákem) se tam dostanu. Klient je taky v pohodě protože s ním se na jinej server taky spojím. Vůbec mi to hlava nebere.

[Dramon]

Jednoduchá kontrola zda se dostanete z internetu k serveru je pomocí telnet "212.27.x.x 1194"
Telnet by se měl spojit a začít na Vás vypisovat srdíčka a jiné znaky :). Pokud se tak nestane, ani se nesnažte hledat chybu ve VPN, ale zkontrolujte konfiguraci routeru (jestli jsem dobře pochopil, že server je za routerem).
Jinak bude konfigurace asi v pořádku, já bych jen použil v těchto případech místo zařízení tap zařízení tun. Respektive mám zafixováno, že tap se používá na bridgování (má to být ekvivalen LAN karty) a tun pro routování (Poin-to-Point zařízení)
BTW- Větu "Bohužel jak server tak i klient v jiné síti jsou za routerem ale mají na sebe propuštěný port 1194." jsem pochopil, že máte díru na portu 1194 i v případě klienta. Jestli ano, tak ji klidně zavřete. OpenVPN vytváří z klienta jen odchozí spojení a nepotřebuje mít žádný průchod přes firewall/router z venku dovnitř.

[power]

Aaa no vida klient se tam přes telnet připojí a v logu na serveru je to i zaznamenáno.

[Dramon]

Fajn, takže pokud se z PC, kde je OpenVPN klient, dostanete pomocí telnetu, tak to začíná být zajímavé, protože podle logu Vám to přestane "fungovat" v okamžiku, kdy by mělo dojít ke spojení klienta se serverem, což není vidět ani v logu klienta, ani v logu serveru. :)
Tak teď možná nastal čas na malé schémátko se zapojením a IP adresami všech 3 PC. Včetně sítí za klienty, které chcete propagovat, pls :). Klidně přihoďte i routovací tabulky těch strojů. No a doufám, že v konfiguračních souborech nechybí nic podstatného. Tím myslím, že vypadají, že jste je ručně zkrátil, tak doufám, že jen o komentáře :))

[power]

Server:

        Veřejná IP v Internetu -> Router         -> Místní Síťová IP koncového PC
        212.27.x.x             -> 192.168.1.100  -> 192.168.1.202

klient1:

        Veřejná IP v Internetu -> Router         -> Místní Síťová IP koncového PC
        80.95.x.x             -> 192.168.10.100  -> 192.168.10.210

klient2:

        Veřejná IP v Internetu -> Router         -> Místní Síťová IP koncového PC
        81.27.x.x                                -> 81.27.x.x(přímo v internetu)Zde spojení se serverem funguje

Jinak z konfiguráku klienta jsem opravdu vyjmul pouze kometáře. A stejný konfigurák jsem zkusil i na klient2 a tam také fungoval. Ještě mě napadlo na straně klienta1 je poskytovatel který permanentně blokuje všechny porty. Když jsem zkoušel variantu klient-klient, která tam fungovala tak jsem si u něj musel žádat o otevření portu 1194 UDP pro příchozí pakety. Není možné že teď naopak když nepotřebuju příchozí ale odchozí by měl provider nějakým způsobem povolit 1194 TCP? To jsem asi napsal blbost co?

[Dramon]

Ještě jednou jsem se díval na Váš konfigurák a musím říct, že včera v noci jsem nebyl v kondici, protože jsem přehlídnul, že u serveru rozepisujete direktivu "server" na "mode server", "tls-server", "ifconfig" a "ifconfig-pool" a chybí vám tam direktiva [push "route-gateway 192.168.100.1"]. Ale to by nemělo mít vliv na funkci :)

Jinak ale pořád řešíme problém, že neproběhne ani spojení. Takže otázky zní: máte v /dev/ zařízení tap ?? Spouštíte to pod rootem ?? Můžete na tom Linuxu zkusit zjistit, zda z něj odchází pakety pomocí "tcpdump -i ethX dst port 1194"??
Pořád mě není jasné, jaktože když z klienta 1 projde telnet, OpenVPN klient se "nedobouchá". To usuzuji z toho logu serveru. Provider by Vás sice blokovat mohl, ale to be neprošel ani ten Telnet.
Bylo by možné na Vašem Windows serveru zjistit, zda tam nějaké pakety docházejí?? Dalo by se to sledovat na jednom z Vašich routerů ??
Jinak u spojení klient<->klient se navazuje spojení oboustraně, u klient->server jen v naznačeném směru. A ne UDP jak píšete, ale TCP, jak je napsáno v .CONF souboru.
Vzhledem k tomu, že nebridgujete, jsem v pokušení poslat Vám odladěné konfigurační soubory co používám a zajímalo by mě, co by se stalo :)) Máte zájem nebo to je otázka cti rozchodit ty stávající ??

[power]

No trochu moc informací na konci pracovní doby Rozhodně bych měl zájem o ten konfigurák. Stávající někam schovám a pokud by se spojení povedlo asi bych je dal v zapomění. BTW push route jsem si chtěl nechat na konec protože opravdu potřebuju routovat ze serveru do klienta ale popravdě řečeno zatím moc nechápu co kde a jak mám routovat a shazovalo mi to druhou místní síť kterou jsem se asi špatnou konfigurací snažil routovat do VPNky.. Ať ušetřím otázky na zaslání konfiguráku poslal jsem Vám e-mail.

[power]

Ještě jeden poznatek na tom klientovi1 kde je WinXP zůstává neaktivní ikonka připojení tam zařízení (nespojený kabel) nevím jestli to něco znamená jestli se nemá spojit až při samotném připojení na server. O serveru jsem si jist že je správně nakonfigurován když se mi na něj klient 2 připojí.

[Dramon]

Na poslanání souborů pracuji, ale jaké WinXP?? Vždyť v logu klienta mate ...madriva.. ??
V tom pripade (pokud to jsou Windows):
-máte práva administrátora?? - ve Windows jsou nutná, což se dá ve finále obejít, ale pro zkoušení je prostě potřebujete
-jaký používáte personální Firewall?? Mohou s nimi být trochu problémy, ale řešitelné to opět je, takže zatím jen informačně.

Jinak odpojená ikona je OK. Směrování a routování můžeme řešit v okamžiku, kdy se Vám to spojí :)))))
Jo, add správná konfigurace serveru - nenechte se zmást fakty :)))

[power]

Aha omlouvám se za zmatení ten log je z mého pracovního PC s mandrivou, který jsem zkoušel místo vzdáleného klienta1 (btw pracovní PC je připojený do stejné sítě jako server) a když mu v remote nechám řádku veřejné adresy, nepřipojí se a log je stejný jako u původního klienta1 proto jsem použil právě tento. Chtěl jsem vědět zda se Linux od jinud nespojí, protože klient2, který funguje pracuje také na mandrivě a tak jsem to chtěl porovnat.

Jinak na klient1 PC se hlásím jako administrator jsou tam WinXP, Firewall vypnutý. Používá se přes router. Na serveru je Win server 2003.

[Dramon]

Pokud je klient na stejné síti jako server a zadá se mu vnější adresa, tak to ani moc fungovat nebude, protože většinou routerů něco takového jakou routeback nezvládne. HW zařízení hlavně levnější kategorie určitě ne, dražší se asi dají nastavit a Linux jako FW to moc často nastavené nemá.
Nabízí se otázka: opravdu je tento log na 100% stejný??

[power]

Jsem já to blbec. Tady je log toho Win Klienta:

Tue Jun 26 15:04:02 2007 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct  1 2
006
Tue Jun 26 15:04:02 2007 IMPORTANT: OpenVPN's default port number is now 1194, b
ased on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earl
ier used 5000 as the default port.
Tue Jun 26 15:04:02 2007 WARNING: No server certificate verification method has
been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Tue Jun 26 15:04:02 2007 LZO compression initialized
Tue Jun 26 15:04:02 2007 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:
0 EL:0 ]
Tue Jun 26 15:04:02 2007 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:
32 EL:0 AF:3/1 ]
Tue Jun 26 15:04:02 2007 Local Options hash (VER=V4): 'd79ca330'
Tue Jun 26 15:04:02 2007 Expected Remote Options hash (VER=V4): 'f7df56b8'
Tue Jun 26 15:04:02 2007 UDPv4 link local: [undef]
Tue Jun 26 15:04:02 2007 UDPv4 link remote: 212.27.212.102:1194

[Mag]

Ja jsem nedavno taky resil nefunkcni OpenVPN z Winu na Linuch a nakonec to vyresilo pouhe zapnuti sluzby "Smerovani a vzdaleny pristup". Tak to ocheckujte..

[power]

Službu jsem spustil i na obou PC. Nic se nezměnilo

[power]

to Dramon:

Váš konfigurák na klienta zafungoval. Aby se spojil s mojím serverem vyměnil jsem konfigurák i na serveru. Dopadlo to ovšem takto:

Wed Jun 27 09:49:37 2007 NOTE: --user option is not implemented on Windows
Wed Jun 27 09:49:37 2007 NOTE: --group option is not implemented on Windows
Wed Jun 27 09:49:37 2007 Diffie-Hellman initialized with 1024 bit key
Wed Jun 27 09:49:37 2007 TLS-Auth MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0
]
Wed Jun 27 09:49:37 2007 There is a problem in your selection of --ifconfig endp
oints [local=192.168.111.252, remote=192.168.111.253].  The local and remote VPN
 endpoints cannot use the first or last address within a given 255.255.255.252 s
ubnet.  This is a limitation of --dev tun when used with the TAP-WIN32 driver.
Try 'openvpn --show-valid-subnets' option for more info.
Wed Jun 27 09:49:37 2007 Exiting

Změnil jsem tedy dev na tap ale...

Wed Jun 27 09:56:12 2007 NOTE: --user option is not implemented on Windows
Wed Jun 27 09:56:12 2007 NOTE: --group option is not implemented on Windows
Wed Jun 27 09:56:12 2007 Warning: cannot open --log file: /var/log/openvpn/openv
pn.log: Syst�m nem��e nal�zt uvedenou cestu.   (errno=3)
Wed Jun 27 09:56:12 2007 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct  1 2
006
Wed Jun 27 09:56:12 2007 Diffie-Hellman initialized with 1024 bit key
Wed Jun 27 09:56:12 2007 TLS-Auth MTU parms [ L:1576 D:140 EF:40 EB:0 ET:0 EL:0
]
Wed Jun 27 09:56:12 2007 WARNING: Since you are using --dev tap, the second argu
ment to --ifconfig must be a netmask, for example something like 255.255.255.0.
(silence this warning with --ifconfig-nowarn)
Wed Jun 27 09:56:12 2007 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a
--route option and no default was specified by either --route-gateway or --ifcon
fig options
Wed Jun 27 09:56:12 2007 OpenVPN ROUTE: failed to parse/resolve route for host/n
etwork: 192.168.111.0
Wed Jun 27 09:56:12 2007 TAP-WIN32 device [P�ipojen� k m�stn� s�ti 5] opened: \\
.\Global\{F79C1344-B9A4-4B84-832D-F97B4529D295}.tap
Wed Jun 27 09:56:12 2007 TAP-Win32 Driver Version 8.4
Wed Jun 27 09:56:12 2007 TAP-Win32 MTU=1500
Wed Jun 27 09:56:12 2007 ERROR: There is a clash between the --ifconfig local ad
dress and the internal DHCP server address -- both are set to 192.168.111.252 --
 please use the --ip-win32 dynamic option to choose a different free address fro
m the --ifconfig subnet for the internal DHCP server
Wed Jun 27 09:56:12 2007 Exiting

Začínám mít pocit že ten server je nějakej prokletej nebo vůbec tahle snaha o VPN.

[Dramon]

Pardon. To je tak, kdyz clovek upravuje konfigurak aby tam nenechal informace o vnitrni siti:) Zkuste misto 253 na konci dat 252. To zarizeni radeji tun
Ze jsem paranoidni neznamena ze po mne nejdou :)))

[power]

No tak nevím.

Options error: local and remote/netmask --ifconfig addresses must be different
Use --help for more information.

Pak jsem zkusil změnit počáteční adresu na ....20

Wed Jun 27 13:33:12 2007 Diffie-Hellman initialized with 1024 bit key
Wed Jun 27 13:33:12 2007 TLS-Auth MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0
]
Wed Jun 27 13:33:12 2007 There is a problem in your selection of --ifconfig endp
oints [local=192.168.111.20, remote=192.168.111.252].  The local and remote VPN
endpoints must exist within the same 255.255.255.252 subnet.  This is a limitati
on of --dev tun when used with the TAP-WIN32 driver.  Try 'openvpn --show-valid-
subnets' option for more info.
Wed Jun 27 13:33:12 2007 Exiting

Už jsem se do toho krapet zamotal. Nemáte prosím ICQ nebo tak něco?

[Dramon]

Tak jsem se dival, ze jsem Vam lehce lhal - tu adresu v server.conf jsem na konci nemenil. Problem bude asi v tom, ze mi vsechny servery jedou na linuxu a Windows na to kouka jinak. Vyzkousim si to pod Windws a dam vedet.
Dnes jsem bohuzel na sluzebce, takze realne to vidim iztra odpolko

[power]

OK zatím díky. Kdyžtak jestli máte nějakej ten IM napsal byste mi ho do mailu na dobu řešení tohoto problému? Možná by se tím hodně urychlilo. Vidím že Vy mi asi můžete opravdu pomoct z této zdánlivě podivné situace

[power]

Prosím ozvěte se mi na ICQ. Rozdejchal jsem jí ale nevím jestli to byl správnej způsob. Také bych potřeboval asi krapet píchnout s Push

[tomfi]

Asi nejzajmavejsi by bylo udelat log toho co se tam deje... a to na urovni odchozich a prichozich paketu. Proste spustit napr. tethereal nebo podobne na obou stranach ... zaznamenat celou konverzaci tak jak probehne a pak se na to podivat ... co k cemu pasuje a jestli tam neni neco co z jedne strany odeslo a na druhou nedorazilo ... tipoval bych ze se po ceste neco ztratilo a konec ;)

[power]

Ještě se zeptám. Dal jsem na server (má vnitřní adresu 192.168.1.202)

push "route 192.168.1.0 255.255.255.0"

Z klienta ale pingnu jen ten server na adrese 192.168.1.202 ostatní v síti 192.168.1.0 nevidím. nechybí mi tam něco?