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

[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
A - komputer za NAT'em (Debian)
B - komputer z publicznym adresem IP

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

 autossh -R 192.168.0.10:10002:localhost:22 [email protected]

dzięki czemu łącząc się 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.

 autossh -R 192.168.0.10:10002:localhost:17003 [email protected]

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:

connect_to localhost port 17003: failed.

a log z klienta OpenVPN wygląda następująco:

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

connect_to localhost port 17003: failed.

Będę wdzięczny za sugestie.

[TQM]

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

Sadze ze chodzi o ten element...
Nie odpalalem nigdy openvpn po ssh bo to nie ma sensu moim zdaniem ale skoro masz taka potrzebe to trzeba pomyslec. Fakt tunelowania przez SSH nie powinien za bardzo wplywac na to co sie dzieje, bo OpenVPN najpierw zestawia sesje TCP, pozniej przypina ja do tun/tap i na tym konfiguruje swoje IP i routing wiec raczej powinno chodzic.

Po pierwsze nie rozumiem dlaczego forwardujesz zdalny port? W ten sposob otwierasz listener na bramce SSH zamiast u siebie. Jakbys dal -L zamiast -R to openvpn laczylby sie na localhost:<port> czyli:

# autossh
autossh -L 11194:<moj server>:1194 [email protected]

# openvpn-client.conf
proto tcp
server localhost
port 11194

Pamietaj ze w tunelowaniu SSH musisz uzywac TCP, wiec OpenVPN musi miec 'proto tcp' na obu koncach polaczenia.

Gdyby to nie zadzialalo, to masz jeszcze dwa wyjscia:
- tunel ssh i PPTP zamiast OpenVPN - w koncu autoryzacje masz przez SSH a pozniej dodatkowo przez PPTP wiec szanse ze ktos niepowolany wbije sa zadne...
- Jesli masz jakikolwiek port przekierowany do tej swojej maszyny, to openvpn ma opcje 'port-share <ip> <port>' ktora zalatwi problem

Przyklad - mam serwer www z SSL sluchajacy na 443/tcp ale chce dodac tam openvpn. Apache idzie na inny port - 3443 powiedzmy, openvpn wchodzi na HTTPS (443/tcp). W konfiguracji OpenVPN dodaje 'port-share localhost 3443' i restartuje openvpn. Teraz jak ktos laczy sie jako vpn to podnosci sie sesja i routing i cala reszta... jak ktos przychodzi przegladarka to openvpn robi proxy do apacza i laduje sie strona razem z SSL itd i wszystko dziala, zero alertow, zero problemow. Wiem ze dziala bo sam uzywam :-)

A na koniec najlepsze rozwiazanie...
Jesli masz jakikolwiek serwerek, publiczny - poza ta siecia z NAT'em, postaw tam serwer OpenVPN i niech ta maszyna zza NATu sie wdzwania do tego glownego serwera. Tylko pamietaj aby dobrze firewalle ustawic bo mozesz sie szybko zdziwic co klienci z VPNa moga wycisnac :P

[poldas]

Dzięki za zainteresowanie tematem.

Na początku małe sprostowanie, z komputerem A chcę się łączyć z komputera C który mam w domu za pośrednictwem komputera B, który jako jedyny posiada zew. IP. Autossh traktuję jako sposób uzyskania dostępu do portu na którym nasłuchuje OpenVPN w zdalnej lokalizacji, stąd tunel w tunelu



Zgodnie z sugestią zmieniłem składnie auto ssh i efekt jest następujący przy próbie połączenia...

Sun Aug 21 22:54:41 2011 OpenVPN 2.2.1 Win32-MSVC++ [SSL] [LZO2] built on Jul  1 2011
Sun Aug 21 22:54:41 2011 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Sun Aug 21 22:54:41 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Sun Aug 21 22:54:44 2011 LZO compression initialized
Sun Aug 21 22:54:44 2011 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
Sun Aug 21 22:54:44 2011 Socket Buffers: R=[8192->8192] S=[8192->8192]
Sun Aug 21 22:54:44 2011 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
Sun Aug 21 22:54:44 2011 Local Options hash (VER=V4): '69109d17'
Sun Aug 21 22:54:44 2011 Expected Remote Options hash (VER=V4): 'c0103fa8'
Sun Aug 21 22:54:44 2011 Attempting to establish TCP connection with 79.189.157.34:10003
Sun Aug 21 22:54:44 2011 TCP connection established with 79.189.157.34:10003
Sun Aug 21 22:54:44 2011 TCPv4_CLIENT link local: [undef]
Sun Aug 21 22:54:44 2011 TCPv4_CLIENT link remote: 79.189.157.34:10003
Sun Aug 21 22:54:44 2011 WARNING: Bad encapsulated packet length from peer (21331), which must be > 0 and <= 1544 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Sun Aug 21 22:54:44 2011 Connection reset, restarting [0]
Sun Aug 21 22:54:44 2011 TCP/UDP: Closing socket
Sun Aug 21 22:54:44 2011 SIGUSR1[soft,connection-reset] received, process restarting
Sun Aug 21 22:54:44 2011 Restart pause, 5 second(s)
Sun Aug 21 22:54:49 2011 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Sun Aug 21 22:54:49 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Sun Aug 21 22:55:49 2011 ERROR: could not not read Private Key password from stdin
Sun Aug 21 22:55:49 2011 Exiting

[TQM]

Na tym z publicznym IP instalujesz serwer OpenVPN, na pozostalych klienta... wlaczasz opcje client-client i juz moga ze soba gadac po prywatnych adresach i caly ruch idzie przez VPN z A do B, z B do C... zalatwione.

Pamietaj tylko aby na FORWARD dac ACCEPT

[poldas]

Na komputerze B mam już zainstalowany serwer OpenVPN, który służy mi jako bramka dostępowa do sieci, w której jest komputer B. Serwer działa w trybie router.

 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"

Czy mogę wykorzystać serwer, który działa w trybie routera?

[TQM]

mozesz tylko ustaw aby klienci mogli do siebie gadac i po sprawie - to jedna opcja w konfigu serwera, zobacz do dokumentacji

[poldas]

Czyli w moim przypadku w konfiguracji serwera dopisuję

push "route 10.0.0.0 255.255.255.0"

wtedy możliwa staje się komunikacja pomiędzy klientami OpenVPN, ale jak skonfigurować routing żeby z komputera C - jednego z klientów OpenVPN była możliwa komunikacja z siecią zdalną, w której znajduje się komputer A (192.168.10.0/24)?

[TQM]

Nie...
to 'push route' jest zbedne bo to jest siec domyslna (klienci dostaja IP z tej sieci) i ten push sie odbedzie niezaleznie czy go wpiszesz czy nie - dlatego mozesz ta linie wywalic a i tak zadziala

Jestes leniwy... mowilem zobacz do dokumentacji - jak klienci maja ze soba gadac to dodaj na serwerze linie

client-to-client

[poldas]

Oj tam od razu leniwy

Miałem na myśli, to że komputer z którego będę się łączył musi wiedzieć gdzie "pchać" ruch do sieci 192.168.10.0/24 (sieć lokalna z komputerem A) dlatego pomyślałem, że klient powinien otrzymać wpis statyczny do tablicy routinug

push "route 192.168.10.0 255.255.255.0"

(w poprzednim poście wpisałem nieprawidłową trasę)

Z tego co w dokumentacji wyczytałem opcja client-to-client pozwoli na komunikację pomiędzy klientami OpenVPN. Czy aby zapewnić dostęp do sieci lokalnej z komputerem A będzie konieczne uruchomienie routingu na komputerze B?

[TQM]

routing musisz ustawic, tak samo jak firewal...

chyba ze client-to-client i na kazdym kompie do ktorego chcesz miec dostep instalujesz sobie osobnego klietna i kazdy ma swoje VPN

To nic skomplikowanego, odpal i sprawdz