Forum Debian Users Gang

Intefejsy TAP zrób sobie poleceniem tunctl z paczki uml-utilities, tak, jak masz w tym tutku:

https://dug.net.pl/tekst/148/tunel_vpn__przez_ssh/

Wtedy na pewno zestawisz tunel.

Potem, jeśli chcesz np korzystać z tego tunelu do używania netu, to tak, jak w każdym VPNie, routing do hosta VPN musi iść przez interfejs zewnętrzny, ale trasa domyślna (ruting default) musi kierować pakiety przez interfejs TAP vpn na drugą końcówkę tunelu.

Przykład pobrania trasy domyślnej do hosta, np:

 ip route get $(dig +short dug.net.pl)
46.105.189.254 via 192.168.0.1 dev eth0  src 192.168.0.10 
    cache

Przykład dodania trasy statycznej w tablicy routingu:

ip route add 46.105.189.254 via 192.168.0.1 dev eth0  src 192.168.0.10

Potem trzeba podmienić domyślną trasę routingu na tą z VPNa:
Pobieramy:

ip route show | grep default
default via 192.168.0.1 dev eth0  metric 4

Trzeba ją usunąć i wstawić własną, wg potrzeb po tym, jak już będzie ustawiona trasa interfejsu  do drugiego końca tunelu (co powinno odbyć się automatycznie przy nadawaniu adresu interfejsowi TAP) i tunel będzie uruchomiony.

Krótko pisząc, żadna magia, przy OpeVPN robi się to zazwyczaj automatycznie, przy SSH jest z tym chwilka zabawy.

To jest najprostsza konfiguracja, jest też kilka innych możliwości, jak np druga tablica routingu, sposób nawet wygodniejszy w użyciu, ale trudniejszy we wstępnej konfiguracji.

W ogóle do używania internetu przez VPN lepszy będzie OpenVPN, tunel SSH raczej sprawdzi się przy bezpiecznym dostępie do różnych usług na zdalnym serwerze, bez wystawiania ich do internetu, jak np Mysql, PostgreSQL, Firebird, Webmin, FTP, itp.

Pozdro

Ostatnio edytowany przez Jacekalex (2017-07-15 14:28:19)

morfik napisał(-a):

Ja u siebie to robiłem w taki sposób.

1.Celowo użyłeś TUN zamiast TAP, czy to po prostu było z jakiegoś powodu wygodniejsze?

2. Może starczy użyć dwóch tras routingu default z różnymi metrykami?
https://morfikov.github.io/post/metryki-tras-interf … aptop-metric/

O iIle się nie mylę, TUN jest konieczny w Andku bez roota, albo jak nie ma driverów TAP  (w Andku czy Windows 10).

W przypadku Linuxa moim zdaniem TAP wymiata o tyle, że jest pełnowartościową kartą sieciową, podczas gdy TUN ma jakieś ograniczenia.

Ostatnio edytowany przez Jacekalex (2017-07-15 15:33:54)

Chyba właśnie TUN wymaga roota i logowania na roota na serwerze.


@Jacekalex, @morfik: pokażcie jak u was wygląda wynik polecenia

ip r

przy działającym tunelu.




Dodam, że ping na 10.0.0.2 (drugi koniec tunelu postawiony na serwerze) odpowiada

ping 10.10.0.2 -c 4
PING 10.10.0.2 (10.10.0.2) 56(84) bytes of data.
64 bytes from 10.10.0.2: icmp_seq=1 ttl=64 time=61.5 ms
64 bytes from 10.10.0.2: icmp_seq=2 ttl=64 time=62.2 ms
64 bytes from 10.10.0.2: icmp_seq=3 ttl=64 time=62.1 ms
64 bytes from 10.10.0.2: icmp_seq=4 ttl=64 time=61.7 ms

--- 10.10.0.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 61.517/61.914/62.213/0.299 ms

Ostatnio edytowany przez jacekz (2017-07-15 19:44:43)

ależ już to sprawdziłem - nie współpracuje:
po:

# ip route add ip_servera via 192.168.2.1 dev eth1 proto static
# ip route change default via 10.10.0.2 dev tap9 proto static

mam:

ip r
default via 10.10.0.2 dev tap9 proto static 
10.10.0.0/24 dev tap9 proto kernel scope link src 10.10.0.9 
ip_serwera via 192.168.2.1 dev eth1 proto static 
192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.102

Nie działa.

Nie otwierają sie strony. Ping dochodzi tylko do Ip_serwera i 10.10.0.2.

Ostatnio edytowany przez jacekz (2017-07-15 20:48:43)

# lft -VV google.pl
/usr/bin/lft: Option '-V' is not implemented in this wrapper
/usr/bin/lft: Option '-V' is not implemented in this wrapper
google.pl: Odwzorowanie nazwy jest chwilowo niemożliwe
Cannot handle "host" cmdline arg `google.pl' on position 1 (argc 10)

# lft google.pl

google.pl: Odwzorowanie nazwy jest chwilowo niemożliwe
Cannot handle "host" cmdline arg `google.pl' on position 1 (argc 10)

Ostatnio edytowany przez jacekz (2017-07-15 21:06:35)

Jacekalex napisał(-a):

Spróbuj tak:

Kod:

lft 8.8.8.8

w odpowiedzi 30 razy * *
zresztą przy działającym necie też.

Ostatnio edytowany przez jacekz (2017-07-15 21:11:30)

To vps w Czechach

ping -c3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2034ms

przy działającym necie (gdy wróce do starej trasy ip route replace default via 192.168.2.1to:

ing -c3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=51.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=46 time=51.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=46 time=51.6 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 51.491/51.617/51.712/0.207 ms

Ostatnio edytowany przez jacekz (2017-07-15 21:31:35)

Przez standardowy.

Aruba, mają tam jedno z datacenter.

jak pinguję ip_serwera, to mam odpowiedź zarówno przez eth1 jak i przez tap9 - wygląda na to że tunel jest ale nie działa :/


Powalczę z tym proxy.

Ostatnio edytowany przez jacekz (2017-07-15 21:41:52)

Jacekalex napisał(-a):

Pewnie będzie trzeba adres Ip

Po prostu nie wiem jakiego IP i portu ma to słuchać.

Powiem szczerze że nie wiem jak wykorzystać obecność proxy na serwerze (ani czy ustawiłem poprawnie: listen-address  10.10.0.2:8118)

Szczerze... jak ktoś ma jakieś pomysły to zapraszam do podzielenia się nimi.

.
.
.
.
szukając w sieci pomysłów na ruszenie tego "vpn over ssh"
.
natrafiłem tu: http://xmodulo.com/how-to-set-up-vpn-over-ssh-in-linux.html
na transparentne proxy sshuttle, po zainstalowaniu proste:

# sshuttle -vr user@remote_host 0.0.0.0/0 --dns

zestawia nam połączenie - proste i działa - tylko nie wiem co o tym myśleć.