Forum Debian Users Gang

morfik · 2016-11-29 11:37:04

Chciałem sobie skonfigurować serwer VPN [url=https://openvpn.net/index.php/open-source/documentation/howto.html]podpierając się tym howto[/url] i przy okazji opisać sobie cały proces stawiania, konfigurowania i zabezpieczenia połączenia VPN. Coś jakoś mi to nie do końca wyszło, bo może ruch idzie do servera VPN (na VPS OVH) ale tylko jego część jest wysyłana w świat, a druga część z nieznanych mi powodów nie może się przebić.

Poniżej jest wstępna konfiguracja serwera:

Kod:

# egrep -v "^#|^;|^$" /etc/openvpn/server-vpn.conf
local 151.80.57.162
port 11941
proto tcp
dev tun
ca /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/server-vpn.crt
key /etc/openvpn/certs/server-vpn.key
dh /etc/openvpn/certs/dh4096.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
keepalive 10 120
cipher AES-256-CBC
auth SHA512
keysize 256
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 4

No i odpowiadająca mu konfiguracja klienta:

Kod:

# egrep -v "^#|^;|^$" /etc/openvpn/client-vpn.conf
client
dev tun
proto tcp
remote 151.80.57.162 11941
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/client-vpn-morfik.crt
key /etc/openvpn/certs/client-vpn-morfik.key
remote-cert-tls server
cipher AES-256-CBC
auth SHA512
keysize 256
comp-lzo
verb 4
auth-nocache
script-security 2
up /etc/openvpn/update-resolv-conf.sh
down /etc/openvpn/update-resolv-conf.sh

Na serwerze oczywiście jest włączony forwarding i NAT:

Kod:

# iptables -S -t nat
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to-source 151.80.57.162

# iptables -S FORWARD
-P FORWARD ACCEPT

# sysctl -a | grep -i net.ipv4.ip_forward
net.ipv4.ip_forward = 1

No i oczywiście port TCP 11941 w INPUT jest otwarty.

Tak wyglądają interfejsy eth0 i tun0 na serwerze:

Kod:

# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether fa:16:3e:dd:db:03 brd ff:ff:ff:ff:ff:ff
    inet 151.80.57.162/32 brd 151.80.57.162 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fedd:db03/64 scope link
       valid_lft forever preferred_lft forever
# ip addr show tun0
23: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none
    inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0
       valid_lft forever preferred_lft forever

A tak na kliencie:

Kod:

# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP group default qlen 1000
    link/ether 3c:4a:92:00:4c:5b brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.150/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fd42:156b:900b:0:3e4a:92ff:fe00:4c5b/64 scope global mngtmpaddr dynamic
       valid_lft forever preferred_lft forever
    inet6 fe80::3e4a:92ff:fe00:4c5b/64 scope link
       valid_lft forever preferred_lft forever

# ip addr show tun0
36: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none
    inet 10.8.0.6 peer 10.8.0.5/32 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::3bdd:4eb4:25aa:b2a5/64 scope link flags 800
       valid_lft forever preferred_lft forever

Połączenie klienta z serwerem następuje bez błędów, patrząc po logu. Zarówno z klienta mogę pingąć serwer jak i z serwera pingnąć klienta posługując się adresami z 10.8.0.* , czyli chyba wszystko zostało do tej pory skonfigurowane poprawnie.

Po podłączeniu do serwera, na kliencie mam takie tasy:

Kod:

$ ip route show
0.0.0.0/1 via 10.8.0.5 dev tun0
default via 192.168.1.1 dev eth0
10.8.0.1 via 10.8.0.5 dev tun0
10.8.0.5 dev tun0 proto kernel scope link src 10.8.0.6
128.0.0.0/1 via 10.8.0.5 dev tun0
151.80.57.162 via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.150
192.168.10.0/24 dev br-lxc proto kernel scope link src 192.168.10.100

Na serwerze zaś są:

Kod:

# ip route show
default via 151.80.57.1 dev eth0
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0  proto kernel  scope link  src 10.8.0.1
151.80.57.1 dev eth0  scope link

Jestem w stanie pingnąć 8.8.8.8 z klienta, jak i dowolnie inny adres. Działa również rozwiązywanie nazw DNS, testowane przez pingowanie różnych domen, by uniknąć ewentualnego buforowania zapytań. Teoretycznie zatem połączenie działa jak należy, nawet jabber bez problemu idzie przez ten VPN ale już strony www czy poczta nie może się przedostać przez ten VPN i pytanie jest dlaczego?

Na wireshark jak patrzę co się dzieje po wejściu na przykładową stronę w przeglądarce (na interfejsie tun0), to mam pełno retransmisji pakietów, z tym, że nie wszystkie połączenia retransmitują pakiety:

[img]http://i.imgur.com/J2AiYu4.png[/img]

Na tym interfejsie tun0, to jaka klasa adresów powinna być? Mają być te 192.168.1, czy tylko 10.8.0?

Z kolei w logu serwera VPN mam całą masę komunikatów typu:

Kod:

Tue Nov 29 11:10:12 2016 us=335071 client-vpn-morfik/94.254.226.118:8762 MULTI: bad source address from client [192.168.1.150], packet dropped

Ten adres 94.254.226.118 to jest publiczny IP mojego ISP.

Nie mam pojęcia gdzie jest problem ale raczej nie na kliencie, bo mam np. ten VPN riseup i on działa bez większego problemu, a konfiguracja tego klienta jest mniej więcej taka sama. Zatem problem musi być gdzieś po stronie serwera i pytanie gdzie? xD

Ostatnio edytowany przez morfik (2016-12-05 19:00:17)

Jacekalex · 2016-11-29 18:40:29

Jak masz default na eth0 to się nie dziw, że ruch idzie na eth0.

Zrób 2 tabele routingu, na domyślnej dajesz routing na VPN, na drugiej na eth0, openvpn puszczasz przez drugą tabelę.

Na konkretne tabele ustawisz pakiety przez cel MARK iptablesa.
https://lukasz.bromirski.net/docs/translations/lartc-pl.html#LARTC.RPDB

Ostatnio edytowany przez Jacekalex (2016-11-30 17:41:53)

morfik · 2016-11-30 13:29:48

Jeśli pijesz do default eth0 na kliencie, to chyba nie bardzo, bo tak jak pisałem, riseup VPN łączy mnie bez problemu, a poza tym, zgodnie z tym ci pisze w manualu openvpn, to wpis default nie ma znaczenia jeśli są również te dwa poniższe:

Kod:

0.0.0.0/1 via 172.27.100.1 dev tun0
128.0.0.0/1 via 172.27.100.1 dev tun0

Bo to one odpowiadają za przekierowanie wszystkich pakietów bezpośrednio do VPN.

Ostatnio edytowany przez morfik (2016-11-30 16:19:41)

morfik · 2016-12-05 18:59:04

Problem solved! xD

Przyczyna? SYNproxy. W regułce w tablicy raw w iptables zabrakło -i eth0 i ruch na tun0 również poszedł na synproxy dla portów 80 i 443:

Kod:

Dec 05 18:49:35 morfitronik.pl kernel: IN=tun0 OUT= MAC= SRC=10.8.0.10 DST=46.105.189.254 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=23425 DF PROTO=TCP SPT=61546 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=

A to z kolei oznaczyło pakiety jako INVALID i zostały zrzucone w łańcuchu INPUT, bo pewnie MSS się nie zgadzał i dlatego tylko część ruchu szła przez VPN, bo jabber ma inne porty. xD

Time (s)	Query
0.00014	SET CHARSET latin2
0.00006	SET NAMES latin2
0.00126	SELECT u., g., o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='18.117.158.124' WHERE u.id=1
0.00073	REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '18.117.158.124', 1732732669)
0.00046	SELECT * FROM punbb_online WHERE logged<1732732369
0.00233	DELETE FROM punbb_online WHERE ident='3.15.239.145'
0.00059	DELETE FROM punbb_online WHERE ident='85.208.96.204'
0.00055	SELECT topic_id FROM punbb_posts WHERE id=307388
0.00079	SELECT id FROM punbb_posts WHERE topic_id=29185 ORDER BY posted
0.00061	SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=29185 AND t.moved_to IS NULL
0.00006	SELECT search_for, replace_with FROM punbb_censoring
0.00085	SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=29185 ORDER BY p.id LIMIT 0,25
0.00078	UPDATE punbb_topics SET num_views=num_views+1 WHERE id=29185
Total query time: 0.00921 s

Forum Debian Users Gang

Ogłoszenie

#1 2016-11-29 11:37:04

morfik - Cenzor wirtualnego świata

[SOLVED] Część ruchu idzie przez VPN, a część nie idzie

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

#2 2016-11-29 18:40:29

Jacekalex - Podobno człowiek...;)

Re: [SOLVED] Część ruchu idzie przez VPN, a część nie idzie

#3 2016-11-30 13:29:48

morfik - Cenzor wirtualnego świata

Re: [SOLVED] Część ruchu idzie przez VPN, a część nie idzie

Kod:

#4 2016-12-05 18:59:04

morfik - Cenzor wirtualnego świata

Re: [SOLVED] Część ruchu idzie przez VPN, a część nie idzie

Kod:

Stopka forum

Informacje debugowania