Freesco, NND, CDN, EOS
http://forum.freesco.pl/

VPN -> Konfiguracja klienta Windows
http://forum.freesco.pl/viewtopic.php?f=24&t=17533		 Strona 1 z 2
Autor:  mes mariusz [ piątek, 6 marca 2009, 20:54 ]
Tytuł:  VPN -> Konfiguracja klienta Windows
Witam.

W artykule z adresu: http://www.nnd-linux.pl/modules.php?nam ... cle&sid=48 jest napisane:

Cytuj:
Musimy użyć programu openvpn dla Windows, zostało to opisane w następnej części artykułu o zastosowaniu certyfikatów w VPN.


Może warto byłoby podlinkować ten artykuł ?

PS. Mam problem ze zrozumieniem linii konfigu dla klienta na Windows:

Cytuj:
route 192.168.1.0 255.255.255.0 - bardzo ważna linia. Musisz dostosować ją do swojej sieci. Podajemy w niej podsieć i maskę dla sieci, której adresy mają być tunelowane przez VPN. Lini tych może być kilka, jeżeli mamy parę klas. Uwaga! Jeżeli łączymy ze sobą dwie sieci ich adresacja, nie może się pokrywać.

W takim razie jak powinna wyglądać ta linia jeśli chcę tunelować wszystkie dostępne ip w sieci, gdy sieć jest utworzona wg:

IP: 192.168.0.XXX, maska 255.255.255.0

O co chodzi z tym pokrywaniem się?


PS.2 Przy próbie uruchomienia openvpn dla konfigu na kliencie windows:

config.ovpn pisze:
dev tun
remote adres-ip-serwera 1194
ifconfig 10.8.0.2 10.8.0.1
secret c:\\static.key
proto tcp-client
route 192.168.0.1 255.255.255.0
comp-lzo


otrzymuję:

Warning: adress 192.168.0.1 is not a network address in relation to mask 255.255.255.0
ROUTE: route addition failed using CreateIpForwardEntry: Parametr jest niepoprawny


Co robię źle?
Autor:  JakubC [ piątek, 6 marca 2009, 23:56 ]
Tytuł: 
route 192.168.0.0 255.255.255.0

Do poduszki: http://pl.wikipedia.org/wiki/Maska_podsieci
Autor:  mes mariusz [ sobota, 7 marca 2009, 00:43 ]
Tytuł: 
No dobra, połączenie nawiązuje się.

Załóżmy teraz, że jedyny aktywny w tej chwili komputer w zdalnej sieci to 192.168.0.208 (działa pod WindowsXP)
(zdalne LAN adresacja 192.168.0.XXX)

Ja pracuję w tej chwili w sieci LAN z adresacją 192.168.1.XXX.


Konfig na serwerze w zdalnej LAN:

Cytuj:
dev tun
ifconfig 10.8.0.1 10.8.0.2
secret /etc/openvpn/static.key
proto tcp-server
daemon
verb 4
log-append /var/log/openvpn.log
comp-lzo


Konfig u mnie po stronie klienta:

Cytuj:
dev tun
remote zewnetrzny-adres-ip 1194
ifconfig 10.8.0.2 10.8.0.1
secret c:\\static.key
proto tcp-client
route 192.168.0.0 255.255.255.0
comp-lzo


Jak teraz dobrać się do jakiegokolwiek zasobu na 192.168.0.208 (Microsoft Windows Networking wyświetla tylko to, co mam w rzeczywistej sieci LAN).


Czy i w jaki sposób mogę pingować do hostów w zdalnej sieci?

Czy i w jaki sposób mogę odwoływać się za pomocą przeglądarki do usług działających lokalnie w zdalnej sieci na poszczególnych hostach?
Autor:  mes mariusz [ niedziela, 25 października 2009, 21:38 ]
Tytuł: 
Wracam do tematu (właściwie wrócę jak dojadę), bo jednak będę musiał się za to zabrać (będę wdzięczny za podpowiedzi).

W kliencie Windows widzę w połączeniach dwa interfejsy (fizyczny LAN i wirtualny VPN). Ponieważ chcę uzyskać IP ze zdalnej sieci po VPN, teoretycznie powinienem wyłączyć interfejs fizyczny LAN (Windowsy z reguły działają tak, że IP otrzymują z pierwszego interfejsu sieciowego z jakim się połączą, kolejne z jakimi nawiąże się połączenie są ignorowane - w sensie ruch sieciowy idzie zgodnie po IP uzyskanym z pierwszego połączenia).

Niestety nie mogę wyłączyć interfejsu fizycznego LAN, bo jak wiadomo, VAN jest wirtualne, i ruch tak na prawdę odbywa się poprzez ten właśnie fizyczny interfejs.

Jak zatem zmusić komputer, aby pobrał IP z VPN-a, i tym samym stał się jednym z hostów zdalnej sieci?
Autor:  czerwo [ niedziela, 25 października 2009, 22:36 ]
Tytuł: 
1. dobrze ustawiony firewall
2. \\192.168.0.5 i go widzisz czy tam inne ip
3. pamietaj ze ip na interfejsie lanowym musi byc inne nic na vpnowym
Autor:  mes mariusz [ niedziela, 25 października 2009, 23:51 ]
Tytuł: 
czerwo pisze:
2. \\192.168.0.5 i go widzisz czy tam inne ip
3. pamietaj ze ip na interfejsie lanowym musi byc inne nic na vpnowym


No więc dla przypomnienia.

W zdalnej sieci rzeczywiste adresy po stronie LAN są klasy 192.168.0.X, gdzie 192.168.0.1 to serwer-router, który jest zawsze włączony i do którego najpewniej jest pingować.

Po stronie klienta LAN to adresy klasy 192.168.1.1

Skonfigurowałem sobie klienta OpenVPN tym razem na Linuksie Ubuntu. W tym celu:
1. W /etc/openvpn umieściłem skopiowany z serwera static.key
2. Umieściłem tam konfig client.conf:
: [/] [] ()
dev tun
remote savioportal.pl 1194
ifconfig 10.8.0.2 10.8.0.1
secret /etc/openvpn/static.key
proto tcp-client
route 192.168.0.0 255.255.255.0
comp-lzo
GeSHi © Codebox Plus

3. Uruchomiłem openvpn na kliencie: openvpn /etc/openvpn/client.conf
Połączenie uzyskałem (Initialization Sequence Completed)

Wynikałoby z tego, że teraz na kliencie mam dwie podsieci:

1). 192.168.1.X - adresy na łączu fizycznym
2). 192.168.0.X - adresy na VPN odpowiadające adresom w LANie sieci zdalnej

Fakt 1.
Rozumiem, że teraz mogę już sobie zapingować do serwera-routera fizycznie znajdującego się w zdalnej sieci poprzez ping 192.168.0.1. Rzeczywiście pinguje się. Na serwerze-routerze w zdalnej sieci stoi serwer WWW, zatem logika wskazuje, że wstukanie w przeglądarkę na lokalnym kliencie VPN 192.168.0.1 powinno wyświetlić to samo co wskazanie domeny / zewnętrznego adresu zdalnej sieci. Niestety strona się nie wyświetla.

Fakt 2.
W zdalnej sieci pod adresem 192.168.0.11 stoi zawsze włączona bramka VoIP. Zresztą zalogowałem się po ssh na konsolę routera-serwera, z którego pinguję na 192.168.0.11 i otrzymuję odpowiedzi, więc mam pewność, że rzeczywiście jest włączona. Tym czasem, gdy pinguję lokalnie z konsoli klienta openvpn na adres 192.168.0.11 nie dostaję żadnej odpowiedzi.

Proszę o podpowiedzi.
Autor:  mes mariusz [ poniedziałek, 26 października 2009, 01:15 ]
Tytuł: 
mes mariusz pisze:
Fakt 1.
Rozumiem, że teraz mogę już sobie zapingować do serwera-routera fizycznie znajdującego się w zdalnej sieci poprzez ping 192.168.0.1. Rzeczywiście pinguje się. Na serwerze-routerze w zdalnej sieci stoi serwer WWW, zatem logika wskazuje, że wstukanie w przeglądarkę na lokalnym kliencie VPN 192.168.0.1 powinno wyświetlić to samo co wskazanie domeny / zewnętrznego adresu zdalnej sieci. Niestety strona się nie wyświetla.


Sprawdziłem tą sytuację łącząc się (klientem Ubuntu z zainstalowanym openvpn) z Internetem bezpośrednio (przez modem GPRS) i w tym przypadku 192.168.0.1 nie odpowiadało mi w ogóle. Ponieważ patrząc od strony klienta openvpn jestem za natem, a właściwie dwoma (ISP -> Admin sieci blokowej -> mój router -> Ubuntu jako klient openvpn) toteż prawdopowobnie ktoś przed moim routerem założył sobie podsieć 192.168.0.X, i to czyjeś 192.168.0.1 pewnie odpowiadało, a nie mój serwer po drugiej strony tunelu VPN.

Ale nawet na połączeniu GPRS nie otrzymuję odpowiedzi na pingi do 192.168.0.1 czyli nie docieram na drugą stronę tunelu VPN.


No i tak się zastanawiam jeszcze nad inną kwesitą... jako co moje Ubuntu powinno być widziane po stronie sieci zdalnej? I czy w ogóle jest jakoś widziane (przecież nie jestem kolejnym komputerem jakiemu serwer dhcp przydzieliłby kolejne IP). Czy na komputerach w zdalnej sieci będą widziane zasoby udostępniane na moim Ubuntu? A jeśli tak to pod jakim IP będą one widziane?
Autor:  czerwo [ poniedziałek, 26 października 2009, 18:11 ]
Tytuł: 
firewall!!
iptables -I FORWARD -i tun0 -o eth1 -j ACCEPT
iptables -I FORWARD -i eth1 -o tun0 -j ACCEPT

za eth1 wstaw wewnetrzny interfejs
oczywiscie na serwerze
Autor:  mes mariusz [ piątek, 6 listopada 2009, 20:47 ]
Tytuł: 
Ciężki orzech ten VPN...

No więc opowiadam.


1. Wbiłem na roota na serwer NND. Wykonałem:
$ iptables -I FORWARD -i tun0 -o eth1 -j ACCEPT
$ iptables -I FORWARD -i eth1 -o tun0 -j ACCEPT

eth1 na serwerze to interfejs LAN-owy.

2. Na serwerze NND odpalam VPN-a:
$ openvpn /etc/openvpn/server.conf

3. Na kliencie odpalam "klienta" VNC:
$ sudo openvpn /etc/openvpn/client.conf

Nawiązuje się połączenie:

: [/] [] ()
administrator@msi:~$ sudo openvpn /etc/openvpn/client.conf
Fri Nov  6 19:22:45 2009 OpenVPN 2.1_rc19 i486-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] built on Oct 13 2009
Fri Nov  6 19:22:45 2009 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Nov  6 19:22:45 2009 /usr/sbin/openvpn-vulnkey -q /etc/openvpn/static.key
Fri Nov  6 19:22:46 2009 WARNING: file '/etc/openvpn/static.key' is group or others accessible
Fri Nov  6 19:22:46 2009 LZO compression initialized
Fri Nov  6 19:22:46 2009 TUN/TAP device tun1 opened
Fri Nov  6 19:22:46 2009 /sbin/ifconfig tun1 10.8.0.2 pointopoint 10.8.0.1 mtu 1500
SIOCADDRT: File exists
Fri Nov  6 19:22:46 2009 ERROR: Linux route add command failed: external program exited with error status: 7
Fri Nov  6 19:22:46 2009 Attempting to establish TCP connection with 79.187.84.194:1194 [nonblock]
Fri Nov  6 19:22:47 2009 TCP connection established with 79.187.84.194:1194
Fri Nov  6 19:22:47 2009 TCPv4_CLIENT link local: [undef]
Fri Nov  6 19:22:47 2009 TCPv4_CLIENT link remote: 79.187.82.111:1194
Fri Nov  6 19:22:56 2009 Peer Connection Initiated with 79.187.82.111:1194
Fri Nov  6 19:22:56 2009 Initialization Sequence Completed
GeSHi © Codebox Plus


Teraz u siebie na kliencie mam:

: [/] [] ()
administrator@msi:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:13:d3:fd:44:ba 
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:22 Base address:0xe800

eth1      Link encap:Ethernet  HWaddr 00:13:ce:15:c6:72 
          inet addr:192.168.2.105  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::213:ceff:fe11:c675/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9726 errors:16 dropped:16 overruns:0 frame:0
          TX packets:8255 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:5913661 (5.9 MB)  TX bytes:1179941 (1.1 MB)
          Interrupt:17 Base address:0xe000 Memory:fbffc000-fbffcfff

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:841 errors:0 dropped:0 overruns:0 frame:0
          TX packets:841 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:92263 (92.2 KB)  TX bytes:92263 (92.2 KB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
          inet addr:10.8.0.2  P-t-P:10.8.0.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:321 (321.0 B)

tun1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
          inet addr:10.8.0.2  P-t-P:10.8.0.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
GeSHi © Codebox Plus


4. Sprawdzam, gdzie daje się pingować od strony klienta:

: [/] [] ()
administrator@msi:~$ ping 10.8.0.2
PING 10.8.0.2 (10.8.0.2) 56(84) bytes of data.
64 bytes from 10.8.0.2: icmp_seq=1 ttl=64 time=0.051 ms
64 bytes from 10.8.0.2: icmp_seq=2 ttl=64 time=0.044 ms

administrator@msi:~$ ping 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
^C
--- 10.8.0.1 ping statistics ---
56 packets transmitted, 0 received, 100% packet loss, time 55361ms
GeSHi © Codebox Plus


Czyli na 10.8.0.2 daje się pingować, na 10.8.0.1 nie.

Dla przypomnienia konfig klienta:

: [/] [] ()
dev tun
remote serwer-vpn.pl 1194
ifconfig 10.8.0.2 10.8.0.1
secret /etc/openvpn/static.key
proto tcp-client
route 192.168.0.0 255.255.255.0
comp-lzo
GeSHi © Codebox Plus


Zgodnie z opisem:

10.8.0.1 - koniec tunelu na serwerze - tu nie pinguje (pingowianie z konsoli klienta)
10.8.0.2 - koniec tunelu na kliencie - tu pinguje bez problemu (pingowianie z konsoli klienta)

Czyli nie mogę dostać się do końca tunelu po stronie serwera, lokalnie jest ok.


5. Przechodzę więc na konsolę serwera i próbuję to samo:

Do przewidzenia...

: [/] [] ()
[root@server-vpn vpn]# ping 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=0.190 ms
64 bytes from 10.8.0.1: icmp_seq=2 ttl=64 time=0.164 ms

[root@server-vpn vpn]# ping 10.8.0.2
PING 10.8.0.2 (10.8.0.2) 56(84) bytes of data.
--- 10.8.0.2 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4014ms
GeSHi © Codebox Plus


Czyli sytuacja podobna, lokalnie (a zate na odwrót):
10.8.0.1 - koniec tunelu na serwerze - tu pinguje prawidłowo (pingowianie z konsoli serwera)
10.8.0.2 - koniec tunelu na kliencie - tu nie pinguje (pingowianie z konsoli serwera)

Czyli nie mogę zapingować z jednego końca tunelu VPN na drugi, ani w jedną, ani w drugą stronę.

A to chyba nie jest sytuacja prawidłowa?
Autor:  czerwo [ piątek, 6 listopada 2009, 20:54 ]
Tytuł: 
Dlaczego na kliencie masz tun0 i tun1 z tym samym adresem ip??
Autor:  mes mariusz [ piątek, 6 listopada 2009, 21:24 ]
Tytuł: 
czerwo pisze:
Dlaczego na kliencie masz tun0 i tun1 z tym samym adresem ip??


Hmm. A to jest dobre pytanie.
Autor:  mes mariusz [ piątek, 6 listopada 2009, 21:53 ]
Tytuł: 
Łał! Nareszcie jakiś postęp :D

Na kliencie VPN zdaje się dopisał do autostartu, a ja go ponownie uruchamiałem.

Teraz jest po jednym interfejsie tun po obu stronach.

I pinguje się w obie strony po obu stronach :)

Po stronie klienta:

: [/] [] ()
administrator@msi:~$ ping 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=64.1 ms
64 bytes from 10.8.0.1: icmp_seq=2 ttl=64 time=73.4 ms

administrator@msi:~$ ping 10.8.0.2
PING 10.8.0.2 (10.8.0.2) 56(84) bytes of data.
64 bytes from 10.8.0.2: icmp_seq=1 ttl=64 time=0.042 ms
64 bytes from 10.8.0.2: icmp_seq=2 ttl=64 time=0.061 ms
GeSHi © Codebox Plus


Po stronie serwera:

: [/] [] ()
[root@server-vpn vpn]# ping 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=0.168 ms
64 bytes from 10.8.0.1: icmp_seq=2 ttl=64 time=0.140 ms

[root@server-vpn vpn]# ping 10.8.0.2
PING 10.8.0.2 (10.8.0.2) 56(84) bytes of data.
64 bytes from 10.8.0.2: icmp_seq=1 ttl=64 time=68.3 ms
64 bytes from 10.8.0.2: icmp_seq=2 ttl=64 time=66.9 ms
GeSHi © Codebox Plus


No i dobra. Teroetycznie wszystko powinno działać.

Wiemy że w LANie serwera znajduje się bramka VoIP o adresie 192.168.0.11.

Nie potrafię się dostać (zapingować) do jej panelu admina z konsoli po stronie klienta:

: [/] [] ()
administrator@msi:~$ ping 192.168.0.11
PING 192.168.0.11 (192.168.0.11) 56(84) bytes of data.
^C
--- 192.168.0.11 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5028ms
GeSHi © Codebox Plus


Od strony serwera oczywiście wszystko ok:

: [/] [] ()
[root@server-vpn vpn]# ping 192.168.0.11
PING 192.168.0.11 (192.168.0.11) 56(84) bytes of data.
64 bytes from 192.168.0.11: icmp_seq=1 ttl=250 time=0.868 ms
64 bytes from 192.168.0.11: icmp_seq=2 ttl=250 time=0.858 ms
GeSHi © Codebox Plus


Czyli coś jeszcze nie gra. Pytanie co...
Autor:  czerwo [ sobota, 7 listopada 2009, 00:22 ]
Tytuł: 
pokaz wyniki z route
Autor:  mes mariusz [ sobota, 7 listopada 2009, 23:08 ]
Tytuł: 
czerwo pisze:
pokaz wyniki z route

Właśnie przysiadłem i chciałem się do tego zabrać, ale najpierw pinguję sobie z klienta na VPN serwera, i co widzę ?

: [/] [] ()
administrator@msi:~$ ping 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
GeSHi © Codebox Plus


W sumie pierwszy raz takie coś widzę.

A ifconfig po obu stronach pokazują prawidłowe pojedyncze interfejsy tun.
Cóż to za ping: sendmsg: No buffer space available ?
Autor:  mes mariusz [ sobota, 7 listopada 2009, 23:33 ]
Tytuł: 
Nie wiem co to było, ale pomógł restart obu maszyn.

Po stronie serwera:

: [/] [] ()
[root@server-vpn vpn]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.2        *               255.255.255.255 UH    0      0        0 tun0
79.187.82.109   *               255.255.255.252 U     0      0        0 eth0
192.168.0.0     *               255.255.255.0   U     0      0        0 eth1
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
default         hdg109.internet 0.0.0.0         UG    0      0        0 eth0
[root@server-vpn vpn]#
GeSHi © Codebox Plus


Po stronie klienta:

: [/] [] ()
administrator@msi:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.1        *               255.255.255.255 UH    0      0        0 tun0
192.168.2.0     *               255.255.255.0   U     2      0        0 eth1
192.168.0.0     10.8.0.1        255.255.255.0   UG    0      0        0 tun0
link-local      *               255.255.0.0     U     1000   0        0 eth1
default         192.168.2.1     0.0.0.0         UG    0      0        0 eth1
administrator@msi:~$
GeSHi © Codebox Plus
Autor:  czerwo [ niedziela, 8 listopada 2009, 18:13 ]
Tytuł: 
co ty kombinujesz :P
http://www.nnd-linux.pl/modules.php?nam ... cle&sid=46

po 2.
traceroute 192.168.0.11

po 3. a to pewnie zniklo
1. Wbiłem na roota na serwer NND. Wykonałem:
$ iptables -I FORWARD -i tun0 -o eth1 -j ACCEPT
$ iptables -I FORWARD -i eth1 -o tun0 -j ACCEPT
Autor:  mes mariusz [ niedziela, 8 listopada 2009, 19:05 ]
Tytuł: 
czerwo pisze:
po 2.
traceroute 192.168.0.11


Oczywiście po stronie klienta:

Przed wykonaniem:

: [/] [] ()
$ iptables -I FORWARD -i tun0 -o eth1 -j ACCEPT
$ iptables -I FORWARD -i eth1 -o tun0 -j ACCEPT
GeSHi © Codebox Plus


: [/] [] ()
administrator@msi:~$ traceroute 192.168.0.11
traceroute to 192.168.0.11 (192.168.0.11), 30 hops max, 60 byte packets
 1  10.8.0.1 (10.8.0.1)  119.910 ms  211.460 ms  211.465 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
administrator@msi:~$
GeSHi © Codebox Plus


Po wykonaniu:
: [/] [] ()
$ iptables -I FORWARD -i tun0 -o eth1 -j ACCEPT
$ iptables -I FORWARD -i eth1 -o tun0 -j ACCEPT
GeSHi © Codebox Plus


: [/] [] ()
administrator@msi:~$ traceroute 192.168.0.11
traceroute to 192.168.0.11 (192.168.0.11), 30 hops max, 60 byte packets
 1  10.8.0.1 (10.8.0.1)  67.677 ms  205.568 ms  205.574 ms
 2  192.168.0.11 (192.168.0.11)  205.576 ms  205.590 ms  205.592 ms
administrator@msi:~$
GeSHi © Codebox Plus


SUKCES!!! :-) Nie mam pojęcia, dlaczego poprzednio nie chciało działać.

Teraz wbijając z klienta za pomocą przeglądarki 192.168.0.11 wbijam bez problemu na panel bramki VoIP :-)

Ale pojawiła się inna ciekawostka. Nie mogę wbić na www postawione na samym serwerze (192.168.0.1).

: [/] [] ()
administrator@msi:~$ traceroute 192.168.0.1
traceroute to 192.168.0.1 (192.168.0.1), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
administrator@msi:~$
GeSHi © Codebox Plus


Jakiś pomysł?

PS. Pozostaje mi teraz ustawić trwale wpis

: [/] [] ()
$ iptables -I FORWARD -i tun0 -o eth1 -j ACCEPT
$ iptables -I FORWARD -i eth1 -o tun0 -j ACCEPT
GeSHi © Codebox Plus


Mam w nnd firewalla ze strony http://listonosz.com.pl/ więc pewnie jakoś da się to zrobić przez nndconf. Mam nadzieję, że mi się uda ;-)
Autor:  mes mariusz [ niedziela, 8 listopada 2009, 22:08 ]
Tytuł: 
mes mariusz pisze:
PS. Pozostaje mi teraz ustawić trwale wpis

: [/] [] ()
$ iptables -I FORWARD -i tun0 -o eth1 -j ACCEPT
$ iptables -I FORWARD -i eth1 -o tun0 -j ACCEPT
GeSHi © Codebox Plus


Mam w nnd firewalla ze strony http://listonosz.com.pl/ więc pewnie jakoś da się to zrobić przez nndconf. Mam nadzieję, że mi się uda ;-)


Wrzuciłem do pliku /etc/rc.d/rc.local wpisy

: [/] [] ()
iptables -I FORWARD -i tun0 -o eth1 -j ACCEPT
iptables -I FORWARD -i eth1 -o tun0 -j ACCEPT
openvpn /etc/openvpn/server.conf
GeSHi © Codebox Plus


Powinno starczyć.

Zastanawia mnie tylko dlaczego nie mogę wbić na www na 192.168.0.1, mimo, że na 192.168.0.1 pinguje (trudno, żeby nie przecież to również serwer VPN). Przez adres WAN-owy oczywiście http działa prawidłowo.
Autor:  czerwo [ niedziela, 8 listopada 2009, 22:54 ]
Tytuł: 
firewall blokuje pewnie.
Sprawdz sobie nmap 192.168.0.1 czy jaki tam ma ip serwer
Autor:  mes mariusz [ niedziela, 8 listopada 2009, 23:23 ]
Tytuł: 
czerwo pisze:
firewall blokuje pewnie.
Sprawdz sobie nmap 192.168.0.1 czy jaki tam ma ip serwer

Mimo, że pinguje się prawidłowo, nmap zwraca:

: [/] [] ()
administrator@msi:~$ nmap 192.168.0.1

Starting Nmap 5.00 ( http://nmap.org ) at 2009-11-08 22:22 CET
Note: Host seems down. If it is really up, but blocking our ping probes, try -PN
Nmap done: 1 IP address (0 hosts up) scanned in 3.09 seconds
administrator@msi:~$
GeSHi © Codebox Plus
Strona 1 z 2 Strefa czasowa UTC+2godz.
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/