Adott egy Debian szerver OpenVpn-nel, és több Windowsos kliens, szintén OpenVpn-nel. Ragyogóan működik, de a kapcsolódás után a szerver körüli belső hálózatot a kliens nem látja. Tudna valaki segíteni? Ide beszúrom az OpenVpn config. fájlokat:
Szerver:
port 1194
proto tcp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
crl-verify /etc/openvpn/crl.pem
dh /etc/openvpn/dh1024.pem
server 10.9.9.0 255.255.255.0
ifconfig-pool-persist /etc/openvpn/ipp.txt
push "route 10.9.10.0 255.255.255.0" # local route
keepalive 10 120
comp-lzo
;client-to-client # clients see each other
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
verb 3
mute 20
Kliens:
dev tun
tun-mtu 1500
remote xxx.com 1194
proto tcp-client
pull
tls-client
ca ca.crt
cert nagyp.crt
key nagyp.key
cipher BF-CBC
keysize 128
comp-lzo
verb 3
Minden segítséget köszönök.
Nagy Péter
- 3248 megtekintés
Hozzászólások
Hali,
Megneztem a sajat szerveremen a konfigot es jonak tunik a tied.
Tuzfalat nezted a kliensen?
Routing tabla a csatlakozas elott es utan?
Lehet hogy van valami bejegyzes regrol amivel akad. (routing tablaban)
Ja es persze admin jog kell a kliensen is a csatlakozashoz, mert routing push van.
Szoval nezd meg hogy az adott account-nak van-e admin joga a local gepen, vagy futtasd a klienst admin joggal, hogy menjen a route push.
Persze nezd meg a log-ot, hogy mit mond a kliens a csatlakozas kozben.
Udv.
- A hozzászóláshoz be kell jelentkezni
Kösz, nézem.
- A hozzászóláshoz be kell jelentkezni
A kliensen a route kimenete:
Csatlakozás előtt:
===========================================================================
Kapcsolatlista:
0x1 ........................... MS TCP Loopback interface
0x2 ...00 03 0d 27 ce a7 ...... Realtek RTL8139 családú PCI gyors Ethernet NIC - Packet Scheduler Miniport
0x3 ...00 0e 35 f4 b6 93 ...... Intel(R) PRO/Wireless 2200BG Network Connection - Packet Scheduler Miniport
0x4 ...00 ff b1 a1 dd 9a ...... TAP-Win32 Adapter V9 - Packet Scheduler Miniport
0x5 ...00 ff 25 b8 4a 6b ...... TeamViewer VPN Adapter - Packet Scheduler Miniport
===========================================================================
===========================================================================
Aktˇv Łtvonalak:
H l˘zati c‚l H l˘zati maszk µtj r˘ Kapcsolat Metrika
0.0.0.0 0.0.0.0 10.9.10.1 10.9.10.135 20
10.9.10.0 255.255.255.0 10.9.10.135 10.9.10.135 20
10.9.10.135 255.255.255.255 127.0.0.1 127.0.0.1 20
10.255.255.255 255.255.255.255 10.9.10.135 10.9.10.135 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
224.0.0.0 240.0.0.0 10.9.10.135 10.9.10.135 20
255.255.255.255 255.255.255.255 10.9.10.135 4 1
255.255.255.255 255.255.255.255 10.9.10.135 3 1
255.255.255.255 255.255.255.255 10.9.10.135 10.9.10.135 1
255.255.255.255 255.255.255.255 10.9.10.135 5 1
Alap‚rtelmezett tj r˘: 10.9.10.1
===========================================================================
µlland˘ Łtvonalak:
Nincs
Csatlakozás után:
===========================================================================
Kapcsolatlista:
0x1 ........................... MS TCP Loopback interface
0x2 ...00 03 0d 27 ce a7 ...... Realtek RTL8139 családú PCI gyors Ethernet NIC - Packet Scheduler Miniport
0x3 ...00 0e 35 f4 b6 93 ...... Intel(R) PRO/Wireless 2200BG Network Connection - Packet Scheduler Miniport
0x4 ...00 ff b1 a1 dd 9a ...... TAP-Win32 Adapter V9 - Packet Scheduler Miniport
0x5 ...00 ff 25 b8 4a 6b ...... TeamViewer VPN Adapter - Packet Scheduler Miniport
===========================================================================
===========================================================================
Aktˇv Łtvonalak:
H l˘zati c‚l H l˘zati maszk µtj r˘ Kapcsolat Metrika
0.0.0.0 0.0.0.0 10.9.10.1 10.9.10.135 20
10.9.9.1 255.255.255.255 10.9.9.29 10.9.9.30 1
10.9.9.28 255.255.255.252 10.9.9.30 10.9.9.30 30
10.9.9.30 255.255.255.255 127.0.0.1 127.0.0.1 30
10.9.10.0 255.255.255.0 10.9.10.135 10.9.10.135 20
10.9.10.0 255.255.255.0 10.9.9.29 10.9.9.30 1
10.9.10.135 255.255.255.255 127.0.0.1 127.0.0.1 20
10.255.255.255 255.255.255.255 10.9.9.30 10.9.9.30 30
10.255.255.255 255.255.255.255 10.9.10.135 10.9.10.135 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
224.0.0.0 240.0.0.0 10.9.9.30 10.9.9.30 30
224.0.0.0 240.0.0.0 10.9.10.135 10.9.10.135 20
255.255.255.255 255.255.255.255 10.9.9.30 10.9.9.30 1
255.255.255.255 255.255.255.255 10.9.9.30 3 1
255.255.255.255 255.255.255.255 10.9.9.30 5 1
255.255.255.255 255.255.255.255 10.9.10.135 10.9.10.135 1
Alap‚rtelmezett tj r˘: 10.9.10.1
===========================================================================
µlland˘ Łtvonalak:
Nincs
A kliens log-ja:
Mon Jul 09 12:07:26 2012 OpenVPN 2.2.2 Win32-MSVC++ [SSL] [LZO2] [PKCS11] built on Dec 15 2011
Mon Jul 09 12:07:26 2012 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Mon Jul 09 12:07:26 2012 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Mon Jul 09 12:07:26 2012 LZO compression initialized
Mon Jul 09 12:07:26 2012 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
Mon Jul 09 12:07:26 2012 Socket Buffers: R=[8192->8192] S=[8192->8192]
Mon Jul 09 12:07:26 2012 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Jul 09 12:07:26 2012 Local Options hash (VER=V4): '69109d17'
Mon Jul 09 12:07:26 2012 Expected Remote Options hash (VER=V4): 'c0103fa8'
Mon Jul 09 12:07:26 2012 Attempting to establish TCP connection with 89.133.49.210:1194
Mon Jul 09 12:07:26 2012 TCP connection established with 89.133.49.210:1194
Mon Jul 09 12:07:26 2012 TCPv4_CLIENT link local: [undef]
Mon Jul 09 12:07:26 2012 TCPv4_CLIENT link remote: 89.133.49.210:1194
Mon Jul 09 12:07:26 2012 TLS: Initial packet from 89.133.49.210:1194, sid=e62e78bf 4d05b31f
Mon Jul 09 12:07:27 2012 VERIFY OK: depth=1, /C=HU/ST=HU/L=Budapest/O=Basewalk_Kft_VPN/OU=DEV/CN=Basewalk_Kft_VPN_CA/name=Basewalk/emailAddress=basewalk@basewalk.com
Mon Jul 09 12:07:27 2012 VERIFY OK: depth=0, /C=HU/ST=HU/L=Budapest/O=Basewalk_Kft_VPN/OU=VPN/CN=server/emailAddress=basewalk@basewalk.com
Mon Jul 09 12:07:27 2012 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Jul 09 12:07:27 2012 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Jul 09 12:07:27 2012 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Jul 09 12:07:27 2012 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Jul 09 12:07:27 2012 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Jul 09 12:07:27 2012 [server] Peer Connection Initiated with 89.133.49.210:1194
Mon Jul 09 12:07:29 2012 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Mon Jul 09 12:07:29 2012 PUSH: Received control message: 'PUSH_REPLY,route 10.9.10.0 255.255.255.0,route 10.9.9.1,topology net30,ping 10,ping-restart 120,ifconfig 10.9.9.30 10.9.9.29'
Mon Jul 09 12:07:29 2012 OPTIONS IMPORT: timers and/or timeouts modified
Mon Jul 09 12:07:29 2012 OPTIONS IMPORT: --ifconfig/up options modified
Mon Jul 09 12:07:29 2012 OPTIONS IMPORT: route options modified
Mon Jul 09 12:07:29 2012 ROUTE default_gateway=10.9.10.1
Mon Jul 09 12:07:29 2012 TAP-WIN32 device [Helyi kapcsolat 2] opened: \\.\Global\{B1A1DD9A-68E0-4AFE-8FEF-F78C2B8733FA}.tap
Mon Jul 09 12:07:29 2012 TAP-Win32 Driver Version 9.9
Mon Jul 09 12:07:29 2012 TAP-Win32 MTU=1500
Mon Jul 09 12:07:29 2012 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.9.9.30/255.255.255.252 on interface {B1A1DD9A-68E0-4AFE-8FEF-F78C2B8733FA} [DHCP-serv: 10.9.9.29, lease-time: 31536000]
Mon Jul 09 12:07:29 2012 Successful ARP Flush on interface [4] {B1A1DD9A-68E0-4AFE-8FEF-F78C2B8733FA}
Mon Jul 09 12:07:35 2012 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Mon Jul 09 12:07:35 2012 WARNING: potential route subnet conflict between local LAN [10.9.10.0/255.255.255.0] and remote VPN [10.9.10.0/255.255.255.0]
Mon Jul 09 12:07:35 2012 C:\WINDOWS\system32\route.exe ADD 10.9.10.0 MASK 255.255.255.0 10.9.9.29
Mon Jul 09 12:07:35 2012 Route addition via IPAPI succeeded [adaptive]
Mon Jul 09 12:07:35 2012 C:\WINDOWS\system32\route.exe ADD 10.9.9.1 MASK 255.255.255.255 10.9.9.29
Mon Jul 09 12:07:35 2012 Route addition via IPAPI succeeded [adaptive]
Mon Jul 09 12:07:35 2012 Initialization Sequence Completed
Ha megnéznéd, köszönöm.
- A hozzászóláshoz be kell jelentkezni
Ez jonak tunik.
En is azt hiszem hogy dev tap lesz a megoldas, ahogy a kollega emlitette, mert brigelni kell a local halo belso felet. Itt van hogy mi kell hozza: http://openvpn.net/index.php/open-source/documentation/miscellaneous/76…
- A hozzászóláshoz be kell jelentkezni
ahogy az előző bejegyzésben írtam, jó a tun, nem kell neki tap (hacsak nem eth bridge a cél)
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Felteszek néhány kérdést, mert a kliens logja teljesen rendben van, nem a klienssel és nem is szerver vpn configgal van a baj.
Kérdések:
Az a szerver aki a vpn-t csinálja az a default gw a hálón? Ha nem ő, akkor van route bejegyzés a belső hálóban lévő szervereken a vpn-ben használt IP poolra?
Ennek a kimenete 1? cat /proc/sys/net/ipv4/ip_forward
Nagy hirtelen ennyi, ezek szoktak lenni a tipikus bukó pontok. Ha eszembe jut még valami akkor írok :)
- A hozzászóláshoz be kell jelentkezni
Szia!
Igazad van, nem ő a default gw. A jelenség is arra utal, hogy a szerveren nem forwardol megfelelően. Nem ad hibajelzést a ping-re, hanem csak nem kap választ.
- A hozzászóláshoz be kell jelentkezni
A default gw a helyi hálón egy TP-LINK TL-WR741N wlan router. Lehet, hogy ott akad el a dolog?
- A hozzászóláshoz be kell jelentkezni
Beállítottam az openvpn szerveren az ip forwardot (igazad volt, nem volt beállítva), és a dhcp klienseknek az openvpn szervert adtam meg default gw-nek. Így a vpn kapcsolat időnként szétszakad, és a belső háló felé menő pingek hol válaszolnak, hol nem.
- A hozzászóláshoz be kell jelentkezni
Na szóval, először is állítsd vissza a default gw-ket mindenhol.
Három dolgot tehetsz:
a: kiadod a VPN gw-n a köv parancsot: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
b: a belső gépeken kiadod ezt: route add 10.9.9.0 mask 255.255.255.0
c: kiszórod DHCP classless route-tal a klienseknek a fenti route-ot
Még valami: ugye nem az irodában ülsz és onnan próbálsz meg bevpn-zni a belső hálóba? Mert a log alapján pont ezt csinálod!
Mon Jul 09 12:07:35 2012 WARNING: potential route subnet conflict between local LAN [10.9.10.0/255.255.255.0] and remote VPN [10.9.10.0/255.255.255.0]
- A hozzászóláshoz be kell jelentkezni
Azért ebből a logból én kitakartam volna a cégspecifikus információkat.
Érdemes lenne egy tcpdumpolást végezni az útvonalba eső összes interfészen, mi történik amikor elindítasz egy forgalmat. Forgalmat pedig telnettel, nc-vel, stb tudsz generálni.
Lehet még a linux szerveren kiadni ip route get parancsokat, mtr-t, windowson traceroute-t, stb.
- A hozzászóláshoz be kell jelentkezni
Bocs, igazad van, a céginfo-t ki kellett volna törölnöm a log-ból. Egy kicsit elkapkodtam. Tegnap óta nem voltam gépnél, most próbálom a bridge-et.
- A hozzászóláshoz be kell jelentkezni
hm, első blikkre dev tap kell neked, mivel ha emlékezetem nem csal, csak tap módban látható a többi gép a tartományban.
--
"'The time has come,' the Walrus said"
- A hozzászóláshoz be kell jelentkezni
Kösz, kipróbálom.
U.i.:
Sajnos dolgoznak a gépen, csak később tudom kipróbálni. Majd beszámolok az eredményről.
- A hozzászóláshoz be kell jelentkezni
Nem, routolt háló van, a dev tun az jó. (tap esetén ethernet bridge-t csinál, amit gondolom nem akar)
- A hozzászóláshoz be kell jelentkezni
igen az bridzselt háló lesz akkor, ez igaz
--
"'The time has come,' the Walrus said"
- A hozzászóláshoz be kell jelentkezni
Mindenkinek köszönöm a segítségét. Végül bridzselt háló lett (tap device, ahogy az OpenVPN HowTo-ban le van írva...)
Nagy Péter
- A hozzászóláshoz be kell jelentkezni
Ehh, the easy way. :)
- A hozzászóláshoz be kell jelentkezni