W przypadku IPseca mamy implementację na poziomie jądra systemu operacyjnego i opcjonalnego demona do wymiany kluczy, np. racoon, isakmpd lub inny.
Konfiguracja IPseca jest zwykle dość zagmatwana i można spotkać problemy ze współpracą różnych implementacji ;) toteż administratorzy lubią SSL VPN-y, które "po prostu działają".
Implementacja SSL VPN działa w całości w przestrzeni użytkownika, posiłkując się sterownikiem jądra dostarczającym pseudointerfejsu tunelującego (np. tun). Jedną z najpopularniejszych implementacji SSL VPN-a jest OpenVPN.
W tym wpisie chciałbym jednak pokazać inny wariant SSL VPN-a, nieco mniej znany, ale za to oprogramowanie mamy już w systemie więc zwykle da się to odpalić "od ręki" - mowa o OpenSSH. Nie, nie chodzi o przekierowywanie portów. Od wersji 4.3 (2006 rok) mamy dostępną opcję -w, która umożliwia zestawienie VPN-a z użyciem pseudointerfejsu tun/tap.
Aby to działało, musimy włączyć w serwerze SSH następujące opcje: PermitTunnel i PermitRootLogin.
W celu zilustrowania uruchomię sobie 2 maszyny wirtualne: jedną z Linuksem (serwer) i jedną z OpenBSD (klient). Maszyny mają ze sobą bezpośrednią łączność po IP.
debian:~# grep -i permittunnel /etc/ssh/sshd_config
PermitTunnel yes
debian:~# /etc/init.d/ssh restart
Restarting OpenBSD Secure Shell server: sshd.
Następnie łączę się z OpenBSD do Linuksa:
open# ssh -NTf -w any:any 192.168.1.182
root@192.168.1.182's password:
W wyniku mamy po obu stronach pseudointerfejsy tun i możemy je zaadresować:
open# ifconfig tun
tun3: flags=51
priority: 0
groups: tun
debian:~# ip a sh dev tun0
5: tun0:
link/[65534]
debian:~# ip a add 172.16.1.2 dev tun0 peer 172.16.1.1
debian:~# ip link set tun0 up
open# ifconfig tun3 172.16.1.1/32 172.16.1.2
Testujemy... działa:
open# ping -c 2 172.16.1.2
PING 172.16.1.2 (172.16.1.2): 56 data bytes
64 bytes from 172.16.1.2: icmp_seq=0 ttl=64 time=1.785 ms
64 bytes from 172.16.1.2: icmp_seq=1 ttl=64 time=7.274 ms
--- 172.16.1.2 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 1.785/4.529/7.274/2.745 ms
Pozostaje ustawić ruting do sieci zdalnej (i opcjonalny NAT). Można także wymusić (klient, opcja Tunnel) użycie pseudointerfejsu tap, czyli emulację łącza Ethernet.
Obecne w OpenSSH wsparcie dla tworzenia szyfrowanych tuneli może być w niektórych sytuacjach znacznie lepszym rozwiązaniem niż przekierowywanie portów. Mamy możliwość transportowania innych protokołów niż TCP, a nawet ramek Ethernet (bridge poprzez VPN). Jeśli potrzebujemy uzyskać dostęp do wielu systemów w zdalnej sieci, może to być prostsze rozwiązanie niż przekierowywanie długiej listy portów. Przekierowanie portów może też utrudnić korzystanie z wirtualnych serwerów WWW (name-based) - tutaj nie mamy tego problemu. Jednak aby się tym pobawić, musimy mieć prawa roota zarówno po stronie serwera, jak i klienta.
Brak komentarzy:
Prześlij komentarz