Strona 2 z 2

: 21 listopada 2011, 13:51
autor: Zico
Unit pisze:Opcja
ma być wpisana do konfiguracji serwera, a nie klienta. Klient tą konfiguracje dostaje przy połączeniu.
Jest już wpisana ale dalej coś nie przesyła.. :( nie wiem co jeszcze powinienem tutaj umieścić jakie logi, czy co żeby dokładniej przekazać działanie OpenVPN. Już trochę czasu nad tym spędziłem i dalej nie mogę dojść co może nie grać.. Dzięki za pomoc i liczę że może ktoś podsunie jeszcze jakiś pomysł. Pozdrawiam.

: 21 listopada 2011, 13:58
autor: Unit
Czyli aktualnie jak wyglądają Twoje pliki konfiguracyjne: server.conf i client.conf ?

: 21 listopada 2011, 14:06
autor: Zico
Serwer:

Kod: Zaznacz cały

dev tun                                #rodzaj interfejsu
local 192.168.2.XXX                #adres IP serwera
proto udp                              #protokol transportowy tunelu
port 17003 
user openvpn
group openvpn
ca cacert.pem                                  #certyfikat CA
cert servercert.pem                           #certyfikat serwera
key serverkey.pem_bezhasla               #klucz prywatny serwera
dh dh1024.pem                                 #plik z parametrami protokolu D-H
server 10.8.0.0 255.255.255.0             #klasa adresowa, przydzielamy IP klientom
ifconfig-pool-persist ipp.txt                 #zawiera info o przydzielonych adresach $
client-config-dir ccd                          #katalog z plikami specyficznych usu uzyt
keepalive 10 120
comp-lzo                                         #algorytm kompresji
push "route 10.11.0.0 255.255.255.0"    #trasa do sieci 'firmowej'
Klient:

Kod: Zaznacz cały

dev tun
client remote XXX.XXX.XXX.XXX
proto udp
port 170XX
nobind
ca cacert.pem
cert user.crt
key user.key
comp-lzo
route-method exe
route-delay 2
push "route 10.8.0.0 255.255.255.0"
verb 3
push jest na serwerze tak jak wspomniałeś, tylko, czy to wystarczy?
Restart serwera nie wiele się zdał. Jakieś polecenie może by było przydatne żeby sprawdzić co się dzieje? Mogę umieścić jeszcze raz logi z tcpdump na serwerze lub wiresharka na kliencie. Może być tak, że jak wchodzimy tunelem na jedną kartę sieciową i jesteśmy na serwerze to do drugiej karty na tym serwerze nie będziemy mieli dostępu? Czy na Debianie routing domyślnie jest włączony (istnieje taka usługa)?

: 21 listopada 2011, 21:54
autor: Unit
Po kolei musisz sobie posprawdzać:
1. czy działa ping z klienta na serwer
2. czy na kliencie dodany jest po podłączeniu poprawny routing (sieć 10.11.0.0 na tun)
3. czy działa ping na interfejs wewnętrzny po stronie serwera (10.11.0.1 ?)
4. żeby mieć pewność, że to nie firewall blokuje połączenia, przygotuj sobie konfiguracje firewalla, która przepuszcza cały ruch w obie strony (ruch śledzisz tcpdumpem)
5. osobiście nie używam konfiguracji dev tun tylko dev tap (ale jak kto woli)

: 22 listopada 2011, 14:07
autor: Zico
Dziękuję, wszystkim za pomoc. Okazało się, że wystarczyło dodać na kliencie (wpisać) ręcznie w CMD

Kod: Zaznacz cały

route add -p 10.8.0.0 255.255.255.0
i polecenia ping zaczęły nagle działać, jest dostęp do sieci wewnętrznej na serwerze.
Był to czysty strzał, bo nie sądziłem, że to coś da. Prawdopodobnie sam sobie dobrał automatycznie maskę, ale mogę się mylić.
Unit pisze: 5. osobiście nie używam konfiguracji dev tun tylko dev tap (ale jak kto woli)
Słyszałem, że konfiguracja TAP jest znacznie trudniejsza od TUN. Czy taki plik konfiguracyjny mógłby być gdybym zamiast tun dał tap?
Gdyby były jeszcze jakieś problemy postaram się nie zakładać nowego tematu tylko tutaj przedstawić.
Dziękuję jeszcze raz za czas i pomoc. Pozdrawiam.

: 01 grudnia 2011, 14:56
autor: Zico
Wszytko działało dość dobrze przez 3 dni aż tu nagle komunikat:

Kod: Zaznacz cały

Thu Dec 01 10:38:47 2011 OpenVPN 2.2.0 Win32-MSVC++ [SSL] [LZO2] built on Apr 26 2011
Thu Dec 01 10:38:47 2011 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Thu Dec 01 10:38:47 2011 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Thu Dec 01 10:38:47 2011 NOTE: --script-security method='system' is deprecated due to the fact that passed parameters will be subject to shell expansion
Thu Dec 01 10:38:53 2011 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Dec 01 10:38:53 2011 LZO compression initialized
Thu Dec 01 10:38:53 2011 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Dec 01 10:38:53 2011 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Dec 01 10:38:53 2011 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Dec 01 10:38:53 2011 Local Options hash (VER=V4): '41690919'
Thu Dec 01 10:38:53 2011 Expected Remote Options hash (VER=V4): '530fdded'
Thu Dec 01 10:38:53 2011 UDPv4 link local: [undef]
Thu Dec 01 10:38:53 2011 UDPv4 link remote: 83.11.XX.XXX:170XX
Thu Dec 01 10:39:53 2011 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Dec 01 10:39:53 2011 TLS Error: TLS handshake failed
Thu Dec 01 10:39:53 2011 TCP/UDP: Closing socket
Thu Dec 01 10:39:53 2011 SIGUSR1[soft,tls-error] received, process restarting
Thu Dec 01 10:39:53 2011 Restart pause, 2 second(s)
Thu Dec 01 10:39:55 2011 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Thu Dec 01 10:39:55 2011 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Thu Dec 01 10:39:55 2011 NOTE: --script-security method='system' is deprecated due to the fact that passed parameters will be subject to shell expansion
Thu Dec 01 10:39:55 2011 LZO compression initialized
Thu Dec 01 10:39:55 2011 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Dec 01 10:39:55 2011 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Dec 01 10:39:55 2011 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Dec 01 10:39:55 2011 Local Options hash (VER=V4): '41690919'
Thu Dec 01 10:39:55 2011 Expected Remote Options hash (VER=V4): '530fdded'
Thu Dec 01 10:39:55 2011 UDPv4 link local: [undef]
Thu Dec 01 10:39:55 2011 UDPv4 link remote: 83.11.XX.XXX:170XX
i gui od Openvpn pali się na żółto non stop bo nie mogę w ogóle się połączyć.
Na innym komputerze to samo.
Firewall na kliencie (Windows7) jest wyłączony.
Tcpdump na serwerze w ogóle nie dostaje żadnych pakietów na interfejs tun0.
Ma ktoś pojęcie dlaczego tls zgłasza błąd?

Dodane:
Problem rozwiązany, okazało się, że musiałem usunąć Esset Noda (antywirus i firewall) i wyłączyć firewall windowsowy.
Mam pytanie do ludzi, którzy znają się na zabezpieczeniach. Nie mam w firewallu na serwerze (konfig wyżej) utrzymywania łącza. Powinienem użyć czegoś podobnego do programu Esstablished, ale podążając według poradników dostępnych w sieci nie widzę działania mojego polecenia.
Pozdrawiam.

: 01 grudnia 2011, 15:35
autor: Cyphermen
No to zerknij established na iptables masę jest przykładów