Strona 1 z 1

Dostęp do sieci za NAT-em przez tunel ssh

: 18 sierpnia 2011, 20:13
autor: poldas
Witam.

Mam kilka komputerów, do których muszę mieć dostęp, niestety sieć jest za NAT-em. Postanowiłem do tego celu wykorzystać tunel ssh przy użyciu autossh i logowanie bez hasła.

Dla ułatwienia będę nazywał komputery literkami
[INDENT]A - komputer za NAT-em (Debian)
B - komputer z publicznym adresem IP[/INDENT]

Za NAT-em jest sieć, w której znajduje się komputer A, ów komputer łączy się przez autossh do komputera z publicznym adresem IP - B.

Kod: Zaznacz cały

 autossh -R 192.168.0.10:10002:localhost:22 tunnel@xxx.pl
Dzięki czemu łącząc się przez ssh do komputera B na port 10002 zostaje przekierowany na port 22 komputera A. Niby jest już dobrze, ale nie do końca, przecież potrzebuję dostępu do całej sieci, a nie jedynie do jednego komputera. Wpadłem na pomysł, że zamiast wystawiać port 22 przekażę przez tunel ssh port 17003 (tcp), na którym to nasłuchuje OpenVPN, na komputerze A.

Kod: Zaznacz cały

autossh -R 192.168.0.10:10002:localhost:17003 tunnel@xxx.pl
I tutaj zaczyna się problem, kiedy próbuję wdzwonić się do sieci klientem OpenVPN na konsoli komputera B, na której jest zestawiony tunel wyskakuje następujący komunikat:

Kod: Zaznacz cały

[B]connect_to localhost port 17003: failed[/B].
a log z klienta OpenVPN wygląda następująco:

Kod: Zaznacz cały

Thu Aug 18 20:09:19 2011 OpenVPN 2.2.1 Win32-MSVC++ [SSL] [LZO2] built on Jul  1 2011
Thu Aug 18 20:09:19 2011 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Thu Aug 18 20:09:19 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Thu Aug 18 20:09:24 2011 LZO compression initialized
Thu Aug 18 20:09:24 2011 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
Thu Aug 18 20:09:24 2011 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Aug 18 20:09:24 2011 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Aug 18 20:09:24 2011 Local Options hash (VER=V4): '69109d17'
Thu Aug 18 20:09:24 2011 Expected Remote Options hash (VER=V4): 'c0103fa8'
Thu Aug 18 20:09:24 2011 Attempting to establish TCP connection with x.x.x.x:10002
Thu Aug 18 20:09:24 2011 TCP connection established with x.x.x.x4:10002
Thu Aug 18 20:09:24 2011 TCPv4_CLIENT link local: [undef]
Thu Aug 18 20:09:24 2011 TCPv4_CLIENT link remote: x.x.x.x:10002
Thu Aug 18 20:09:24 2011 Connection reset, restarting [-1]
Thu Aug 18 20:09:24 2011 TCP/UDP: Closing socket
Thu Aug 18 20:09:24 2011 SIGUSR1[soft,connection-reset] received, process restarting
Thu Aug 18 20:09:24 2011 Restart pause, 5 second(s)
Thu Aug 18 20:09:29 2011 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Thu Aug 18 20:09:29 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Thu Aug 18 20:09:31 2011 ERROR: could not not read Private Key password from stdin
Thu Aug 18 20:09:31 2011 Exiting

Oczywiście, lokalnie połączenie VPN jest zestawiane bez problemów.

Próbowałem przekazywać porty 22, 80 i wszystko działa, niestety zestawienie VPN kończy się komunikatem:

Kod: Zaznacz cały

[B]connect_to localhost port 17003: failed[/B].
Będę wdzięczny za sugestie.

: 18 sierpnia 2011, 21:54
autor: piroaa
Ja bym to widział tak żeby komputer B łączył się do serwera A tylko za pomocą openVPN ssh bym sobie darował w tym przypadku.
OpenVPN działa w trybie [bmostu[/b], przykładowy działający konfig:

Kod: Zaznacz cały

mode server
proto tcp
port 1194 
dev tap0 
server-bridge 10.21.0.1 255.0.0.0 10.21.0.11 10.21.0.20
 # Gateway (VPN Server)   Subnetmask   Start-IP   End-IP 
keepalive 10 120 
daemon 
#verb 2
client-to-client 

dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem

# Only use crl-verify if you are using the revoke list - otherwise leave it commented out
# crl-verify /tmp/openvpn/ca.crl

duplicate-cn
Klient :

Kod: Zaznacz cały

remote x.x.x.x 1194

client 
dev tap0 
proto tcp
resolv-retry infinite 
nobind 
persist-key 
persist-tun 
float 

ca ca.crt 
cert client1.crt
key client1.key 
ns-cert-type server
I to powinno załatwić dostęp do całej sieci.
Jeśli nie chcesz na każdym komputerze w sieci instalować klienta openvpn, to według mnie, można będzie zainstalować klienta OpenVPN na ruterze lub pokombinować jakoś mostem tap0 i fizyczny interfejs na komputerze z klientem. Ale czegoś takiego nie testowałem i nie wiem czy to zadziała.

Coś podobnego robiłem ale po stronie serwera i wtedy działa na pewno:

Kod: Zaznacz cały

brctl addif br0 tap0 
ifconfig tap0 0.0.0.0 promisc up
Pozdrawiam.

: 18 sierpnia 2011, 22:15
autor: poldas
piroaa pisze:Ja bym to widział tak żeby komputer B łączył się do serwera A...
Tak się nie da, ponieważ komputer A jest za NAT'em. Zapomniałem też dodać, że chcę się łączyć z 3 komputera - C, który również jest za NAT'em, tak więc komputer B jako jedyny posiada zewnętrzny adres IP i jest pośrednikiem pomiędzy A a C.

: 18 sierpnia 2011, 22:54
autor: piroaa
Dobrze, źle to rozpisałem. Serwer OpenVPN instalujesz na komputerze B, a komputer A łączy się do niego bez problemu mimo, że jest za NAT-em. Teraz gdy Ty jesteś za NAT-em na komputerze C też łączysz się do serwera B i masz pełen dostęp do komputera A.

: 19 sierpnia 2011, 14:44
autor: poldas
Na komputerze B (pośredniczącym) używam OpenVPN, ale w trybie rutera, czy mogę jakoś zestawić komputer C z A (i uzyskać dostęp do sieci) bez uruchamiania OpenVPN w trybie mostu?

Poniżej plik konfiguracyjny serwera OpenVPN

Kod: Zaznacz cały

cat /etc/openvpn/openvpn.conf
dev tun
local 192.168.0.10
proto udp
port 17003
user openvpn
group openvpn
ca certs/cacert.pem
cert certs/servercert.pem
key keys/serverkey_bez_hasla.pem
dh dh1024.pem
server 10.0.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir ccd
keepalive 10 120
comp-lzo
push "route 192.168.0.0 255.255.255.0"

: 20 sierpnia 2011, 11:03
autor: piroaa
Z tego co udało mi się wywnioskować sieć wygląda tak jak na poniższym schemacie. W związku z powyższym jeśli chcesz to uruchomić w trybie routingu i mieć dostęp do wszystkiego co jest w podsieci A to musisz na każdym urządzeniu w tej podsieci dodać dodatkową bramę do podsieci 192.168.0.0/24 z bramą wskazującą na komputer A lub na ruterze podsieci A dodać trasę do podsieci 192.168.0.0/24 i wskazać bramę na komputer A, oczywiście jeśli ten ruter udostępnia taką funkcjonalność.
Załącznik siec.jpeg nie jest już dostępny
Według mojej wiedzy innej możliwości nie ma.
Pozdrawiam.

: 20 sierpnia 2011, 20:23
autor: poldas
Router w lokalizacji A ma możliwość określenia statycznej trasy.

Zastanawiam się czy będzie działać takie rozwiązanie, że klient A przekaże do serwera B trasę do sieci lokalnej, w której jest zlokalizowany - 192.68.10.0/24, a następnie klient C, który również wdzwoni się do serwera C uzyska dostęp również do sieci 192.68.10.0/24
Załącznik Diagram2.jpg nie jest już dostępny