ďťż
 
 
   po podłączeniu się VPN nie widzę sieci wewnętrznej
 
 

Tematy

 
    
 

 

 

 

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.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • minister.pev.pl

  •  

     


     

     
    Copyright 2003. MĂłj serwis