PioDer - moje pierwsze podejrzenie jest takie, że występuje konflikt adresacji sieci. Zmieńcie swoje sieci na coś bezpieczniejszego, np.
192.168.53.0/255.255.255.0 i 192.168.54.0/255.255.255.0, albo w ogóle z innych grup adresowych.
Oczywiście musisz odpowiednio poprawić konfiguracje, włączyć ten wyłączony push (tylko dla zmienionej sieci) i sprawdzić jeszcze raz co się stanie.
Po drugie - rozumiem, że serwery między sobą się bez problemu pingają po tunelu. Sprawdzając pingi do podsieci na razie nie zaczynaj z wnętrza sieci lokalnej tylko z serwera. Czyli np. chcąc pingnąć komputer wewnątrz sieci 192.168.53.0 uruchamiaj najpierw ping na serwerze sieci 192.168.54.0. Dopiero kiedy to zadziała, testuj z wnętrza sieci.
To takie małe uwagi na początek.
Upewnij się jeszcze, czy prawidłowo masz poustawiane adresy, bo z konfiguracji, które wrzuciłeś rozjeżdżają Ci się tunelowe adresy serwerów.
Jak to zrobisz daj znać o wynikach i pomyślimy.
Zestawienie tunelu mi
obecna konfiguracja serwera OpenVPN (raczej tak, jak powinno być):
Co masz na myśli, mówiąc o "rozjeżdżaniu" się adresów serwerów tunelu?
Kod: Zaznacz cały
#local 192.168.0.1
port 1212
proto udp
dev tun0
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key # This file should be kept secret
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
server 10.0.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.0.0 255.255.255.0"
client-config-dir ccd
route 192.168.1.0 255.255.255.0
client-to-client
keepalive 10 120
comp-lzo
#user nobody
#group nobody
persist-key
persist-tun
status openvpn-status.log
log openvpn.log
verb 4
mute 10
Chodzi mi o to, że podajesz różne adresy IP serwerów. Dla jednego z serwerów podawałeś lokalny 10.0.0.1 i odległy 10.0.0.2, dla drugiego 10.0.0.6 i 10.0.0.5. Wydaje mi się, że to były różne sesje i w efekcie tunel miał różne adresacje. Ale jeśli tak, to wygodniej chyba byłoby wymusić stałą adresację.
Ponowię sugestię - zmień całkowicie adresacje sieci lokalnych. Wydaje mi się (powinieneś móc to sprawdzić traceroutem), że gdzieś po drodze (u kolegi) pojawia się sieć 192.168.0.0 i to ona zaburza komunikację.
Ponowię sugestię - zmień całkowicie adresacje sieci lokalnych. Wydaje mi się (powinieneś móc to sprawdzić traceroutem), że gdzieś po drodze (u kolegi) pojawia się sieć 192.168.0.0 i to ona zaburza komunikację.
Ale jak inaczej uzasadnić to, że po uruchomieniu push przestaje działać internet? Zresztą próba chyba wiele nie kosztuje.
Co do stałych adresów. Cóż, nie wnikam w szczegóły, ale wydaje mi się, że http://vpn.cba.pl/vpn/OpenVPN/Konfiguracja_OpenVPN.doc powinno pomóc.
Co do stałych adresów. Cóż, nie wnikam w szczegóły, ale wydaje mi się, że http://vpn.cba.pl/vpn/OpenVPN/Konfiguracja_OpenVPN.doc powinno pomóc.
Ister, przez długi okres czasu Cię nie było. Ten problem został już rozwiązany, bo był źle push wysłany, tzn. nie ta podsieć (było push "route 192.168.1.0 255.255.255.0", a miało być push "route 192.168.0.0 255.255.255.0") bo kolega ma 192.168.1.0/24
Edycja:
dopisałem do serwer.conf:
oraz do klient.conf:
a mimo wszystko klient ma dalej 10.0.0.6
Edycja:
dopisałem do serwer.conf:
Kod: Zaznacz cały
ifconfig 10.0.0.1 255.255.255.0Kod: Zaznacz cały
ifconfig 10.0.0.2 255.255.255.0Ister, openvpn działa w taki sposób, że u każdego z klientów zestawia tunel w logicznej topologii punkt-punkt. Każdy klient dostaje średnio co 4 skoki 2 adresy: adres swój i adres bramy. Te bramy są jakby wirtualne, czyli serwer ma 10.0.0.1 i adres interfejsu, przez który śle pakiety do sieci vpn 10.0.0.2. Następny klient ma adres 10.0.0.6, a adres bramy 10.0.0.5. Tych adresów bram nie da się pingować bo są one tylko logiczne by odwzorować ppp. Nie ma mowy o żadnym rozjeżdżaniu.
PioDer, te adresacje dlatego tak wyglądają bo zależność jest taka jak opisałem przed chwilą.
Nie dopisuj już żadnych rzeczy bo w tej chwili mieszasz adresacje. Wcześniej miałem opcję serwera dla wielu klientów. Dopisując te linijki co teraz:
Zaczynasz robić bajzel i konfiguracja w ogóle się może rozsypać.
Z tymi ,,push'' jest tak, że kolega tracił internet bo podczas gdy łączył się tunelem vpn do jego tablicy routingu była dodawana trasa do jego własnej podsieci ale przez tunel vpn. Następował swojego rodzaju konflikt.
Co rozumiesz przez stałą adresację? Pytałeś mnie, czy w pliku ipp.txt powinno coś być?
Tak powinno, nazwa z certyfikatu ,,common name'' oraz adres, który został przypisany, czyli powinno tam być: nazwa twojego kolegi i adres 10.0.0.4 gdyż i tak openvpn przypisze adres kolegi aby serwer mógł go rozwiązać i nie martw się, że ten adres jest inny niż kolega ma. Tak działa OpenVpn ze względu na bibliotekę jakąś.
Jeśli chcesz wymusić te adresy stałe to musisz wziąć pod uwagę ten dziwny tryb adresowania OpenVPN oraz poczytać o katalogu ccd. Można tez wpisać na siłę do pliku ipp.txt ale nie wiem czy to zda egzamin. Na pewno to nie stanowi problemu, który staramy się rozwiązać
Prosiłem Cię też, abyś usunął tą linijkę:
Czemu nie reagujesz od kilku postów?
Powiedz też, co mówią logi z pliku openvpn.log.
PioDer, te adresacje dlatego tak wyglądają bo zależność jest taka jak opisałem przed chwilą.
Nie dopisuj już żadnych rzeczy bo w tej chwili mieszasz adresacje. Wcześniej miałem opcję serwera dla wielu klientów. Dopisując te linijki co teraz:
Kod: Zaznacz cały
ifconfig 10.0.0.1 255.255.255.0Z tymi ,,push'' jest tak, że kolega tracił internet bo podczas gdy łączył się tunelem vpn do jego tablicy routingu była dodawana trasa do jego własnej podsieci ale przez tunel vpn. Następował swojego rodzaju konflikt.
Co rozumiesz przez stałą adresację? Pytałeś mnie, czy w pliku ipp.txt powinno coś być?
Tak powinno, nazwa z certyfikatu ,,common name'' oraz adres, który został przypisany, czyli powinno tam być: nazwa twojego kolegi i adres 10.0.0.4 gdyż i tak openvpn przypisze adres kolegi aby serwer mógł go rozwiązać i nie martw się, że ten adres jest inny niż kolega ma. Tak działa OpenVpn ze względu na bibliotekę jakąś.
Jeśli chcesz wymusić te adresy stałe to musisz wziąć pod uwagę ten dziwny tryb adresowania OpenVPN oraz poczytać o katalogu ccd. Można tez wpisać na siłę do pliku ipp.txt ale nie wiem czy to zda egzamin. Na pewno to nie stanowi problemu, który staramy się rozwiązać
Prosiłem Cię też, abyś usunął tą linijkę:
Kod: Zaznacz cały
route 192.168.1.0 255.255.255.0Powiedz też, co mówią logi z pliku openvpn.log.
Nie usuwałem linijki, zahaszowałem.
Obecnie konfiguracja wygląda tak:
Tych stałych adresów nie musi być... naprawdę. Kwestia tylko żeby routing działał.
PS. Wczoraj w nocy bawiłem się jeszcze trasami na moim serwerze. Usunąłem podstawową
I próbowałem z różnymi bramami:
Oczywiście dodając każde routowanie usuwałem poprzednie. O dziwo, na gw 10.0.0.5 oraz 10.0.0.6 trasa 192.168.1.0 była przypisana do interfejsu ppp0 (czyli mojego od WAN'u - Neostrada).
Niestety, w tej chwili nie mogę nic zrobić, ponieważ nie ma kolegi, a on musiałby uruchomić drugą stronę tunelu.
Obecnie konfiguracja wygląda tak:
Kod: Zaznacz cały
#local 192.168.0.1
port 1212
proto udp
dev tun0
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key # This file should be kept secret
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
server 10.0.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.0.0 255.255.255.0"
client-config-dir ccd
#route 192.168.1.0 255.255.255.0
client-to-client
keepalive 10 120
comp-lzo
#user nobody
#group nobody
persist-key
persist-tun
status openvpn-status.log
log openvpn.log
verb 4
mute 10
PS. Wczoraj w nocy bawiłem się jeszcze trasami na moim serwerze. Usunąłem podstawową
Kod: Zaznacz cały
route del -net 192.168.1.0/24Kod: Zaznacz cały
route add -net 192.168.1.0/24 gw 10.0.0.1
route add -net 192.168.1.0/24 gw 10.0.0.2
route add -net 192.168.1.0/24 gw 10.0.0.5
route add -net 192.168.1.0/24 gw 10.0.0.6
Niestety, w tej chwili nie mogę nic zrobić, ponieważ nie ma kolegi, a on musiałby uruchomić drugą stronę tunelu.