|
po podłączeniu się VPN nie widzę sieci wewnętrznej
redelek - 29-09-2009 14:22
Cześć.
Przeczytałem wszystkie tematy na forum, ale żaden nie rozwiązał mojego problemu, i nawet nie był zbliżony do niego. Dziś uruchomiłem VPN dla pracowników z kluczami szyfrującymi (czyli certyfikaty). Problem jest w tym, że po podłączeniu się VPN nie widzę sieci wewnętrznej. Nie mogę ping żadnego hosta, ani się podłączyć RDP. LAN MA zakres 10.0.1.80 do 10.0.1.190
OpenVPN chciałem tak skonfigurować, żeby przyznawał IP od 191 do 210. To narazie odpadło w przedbiegach bo i tak nie działa i tak.
Tak wygląda konfiguracja mojego serwera dev tun tun-mtu 1500 port 1194 user nobody group nogroup comp-lzo proto tcp-server #ping 20 #ping-restart 120 #ping-timer-rem persist-tun persist-key daemon verb 4 log-append /var/log/openvpn.log ca /etc/openvpn/certyfikat_rootca.pem cert /etc/openvpn/certyfikat_bramy.pem key /etc/openvpn/klucz_bramy.pem tls-server dh /etc/openvpn/dh1024.pem mode server # poniżej podany zakres sieci oznacza, że serwer na interfejsie tun0 będzie miał numer 10.0.2.1 # klienci dostaną numery od 2 wzwyż server 10.0.2.0 255.255.255.0 # przed uruchomieniem serwera ten plik należy stworzyć ifconfig-pool-persist /etc/openvpn/ipp.txt #ponizsze opcje można zmieniać w zależności od potrzeb, DOMAIN zależy od grupy roboczej w jakiej jest serwer, #można użyć domeny jeśli jest w niej sieć, serwer DNS należy wpisac taki jaki jest w danej sieci, #route z kolei musi zawierać zakres realnej sieci za serwerem VPN, #klasa ta nie może się pokrywać z siecią po stronie klientów #push "dhcp-option DOMAIN clickad" #push "dhcp-option DNS 10.0.1.3" push "route 10.0.1.1 255.255.255.0" #push "ping 20" #push "ping restart 120"
STACJI tls-client dev tun proto tcp-client comp-lzo persist-tun persist-key verb 4 ca C:certyfikat_rootca.pem cert C:certyfikat_predel.pem key C:klucz_predel.pem remote 195.205.XXX.XXX pull port 1194 ping 15
Dostaję ładnie IP ale nic z tego nie widzę żadnego komputera w lan. ipconfig /all na windows IP 10.0.2.6 MASKA: 255.255.255.252 ? nie wiem skąd on ją ciągnie DHCP: 10.0.2.5 ? nie wiem skąd go bierze GW: BRAK nic nie mam DNS: 10.0.1.3 // to serwer DHCP i DNS w lan
Macie może pomysł dlaczego to może nie działać? Porty mam otwarte więc co jest nie tak. Co mogę sprawdzić. Będę wdzięczny za pomoc
[Dodano: 2009-09-29, 15:12] Działa, dziękuję
[Dodano: 2009-10-02, 12:44] Proszę, jednak potrzebna pomoc. Zadziałał mi OPENVPN 3 dni i klops. ÂŁączyć się łączy, ale nie widzę sieci LAN.
Mam wpisy:
#echo "1" >/proc/sys/net/ipv4/ip_forward #iptables -t nat -A POSTROUTING -s 10.0.2.0/24 -o eth0 -j MASQUERADE
I pomimo tego nie mogę pingować żadnego hosta z sieci 10.0.1.13 lub 10.0.1.3.
Ma ktoś może pomysł, bo mi już ich brak?
Ister - 12-10-2009 09:53
Jaką maskę ma Twoja sieć lokalna?
Miałem taki problem, że sieci lokalna i po VPN-ie częściowo się zazębiały i wtedy wychodziły totalne bzdury. Tymczasem skoro Twój adres to 10.x.x.x to często przyznawane są maski dla dużych sieci, wtedy się krzaczy.
Podaj wynik ifconfig
po uruchomieniu tunelu.
[ Dodano: 2009-10-12, 10:00 ] Właśnie się przyjrzałem dokładniej, tzn. co dostajesz pod Windowsem. Jest tak jak piszę - dostajesz adres z puli adresowej 10.0.2.0/24. Dlatego Twój DHCP to 10.0.2.5 (musi być to skonfigurowane jako dodatkowa podsieć). Brama jest (powinna być) w tej samej podsieci. Powstaje konflikt z adresami z tunelu. Co gorsza może się zdarzyć, że dostaniesz adres z innej puli (np 10.0.1.0/24) i wtedy wszystko będzie działać prawidłowo. Dlatego czasem działa, a czasem nie.
Jeśli to Ty zarządzasz serwerem do którego łączysz się tunelem - zmień sobie tam sieć na inną pulę adresową (np 192.168.0.0/24). Jeśli ktoś inny to musisz poprosić obu administratorów, żeby się dogadali w temacie używanych zakresów. Zasadniczo jednak z kilku względów sądzę, że łatwiej będzie zmienić drugi koniec tunelu niż ISP.
franki3 - 12-10-2009 21:32
jeśli chesz połączyć się z RDP będziesz potrzebowałe regułek iptables -I FORWARD -i tun+ tcp -s 10.0.2.2 -d 192.168.1.2 -dport 3389 -j ACCEPT
iptables -I FORWARD -i tun+ tcp -s 10.0.2.2 -d 192.168.1.2 -dport 445 -j ACCEPT
gdzie 10.0.2.2 to aderss ip klienta konfigurowany przez ipp.txt a 192.168.1.2 to aderss servera rdp a 445 to port protokołu smb
zanotowane.pldoc.pisz.plpdf.pisz.plminister.pev.pl
|