WG peeri in OpenVPN odjemalci se ne vidijo med seboj @ Slo-Tech

Forum » Omrežja in internet »
WG peeri in OpenVPN odjemalci se ne vidijo med seboj

WG peeri in OpenVPN odjemalci se ne vidijo med seboj

poweroff :: 25. jul 2022, 16:18

Na Debian server sem postavil Wireguard peer ter OpenVPN server. Mašina ima javni IP in se torej nanjo lahko povezujejo Wireguard peeri in OpenVPN odjemalci.

Za Wireguard uporabljam subnet: 10.10.6.0/24. Za OpenVPN uporabljam subnet: 10.10.8.0/24.

Wireguard peeri se lahko vidijo (pingajo) med seboj. OpenVPN odjemalci se tudi lahko vidijo (pingajo) med seboj.

Problem pa je, da se Wireguard peeri in OpenVPN odjemalci ne vidijo (in obratno).

Ko na serverju aktiviram Wireguard, se požene tale skripta:

#!/bin/bash
IPT="/sbin/iptables"

IN_FACE="ens3"                   # NIC connected to the internet
WG_FACE="wg0"                    # WG NIC
SUB_NET="10.10.6.0/24"           # WG IPv4 sub/net aka CIDR
WG_PORT="51194"                  # WG udp port
SUB_NET_6="fd42:42:42:42::/112"  # WG IPv6 sub/net

## IPv4 ##
$IPT -t nat -I POSTROUTING 1 -s $SUB_NET -o $IN_FACE -j MASQUERADE
$IPT -I INPUT 1 -i $WG_FACE -j ACCEPT
$IPT -I FORWARD 1 -i $IN_FACE -o $WG_FACE -j ACCEPT
$IPT -I FORWARD 1 -i $WG_FACE -o $IN_FACE -j ACCEPT
$IPT -I INPUT 1 -i $IN_FACE -p udp --dport $WG_PORT -j ACCEPT

# Peers can see each other
$IPT -I FORWARD -i $WG_FACE -o $WG_FACE -j ACCEPT

V /etc/ufw/before.rules pa imam (pred *filter sekcijo) tole:

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.10.8.0/24 -o ens3 -j MASQUERADE
COMMIT

Poskusil sem tudi s temle ukazom, pa seveda ne deluje:

$IPT -I FORWARD -i wg0 -o tun0 -j ACCEPT
$IPT -I FORWARD -i tun0 -o wg0 -j ACCEPT

Kakšna ideja?

sudo poweroff

poweroff :: 26. jul 2022, 08:59

Še tole...
V WG peerih imam nastavljeno:

AllowedIPs = 0.0.0.0/0

Dodal sem celo tole (čeprav po moje nepotrebno):

AllowedIPs = 10.10.8.0/24

Na OpenVPN serverju pa:

push "route 10.10.6.0 255.255.255.0"

V /etc/default/ufw pa imam DEFAULT_FORWARD_POLICY="ACCEPT".

In ne, zadeva še vedno ne deluje.

sudo poweroff

AmokRun :: 26. jul 2022, 10:40

Na serverju pa lahko pingaš oba subneta?

poweroff :: 26. jul 2022, 10:42

Da. Iz WG peerov in OVPN clientov lahko pingam tudi oba IPja na serverju (10.10.8.1 in 10.10.6.1).

sudo poweroff

Bakunin :: 27. jul 2022, 08:48

morda

sysctl -w net.ipv4.ip_forward = 1

?

poweroff :: 27. jul 2022, 08:52

Ja, to imam.

sudo poweroff

NoName :: 27. jul 2022, 17:15

če imaš kak tcpdump na škatli, pa dva pinganja 'voljna' klienta - enega wg in enega ovpn, bi lahko snifal promet na vpn serverju na wg in ovpn interfaceih, da vidiš če gre skozi. pa če lahko snifaš še na drugi strani (na clientih), toliko bolje...

I can see dumb people...They're all around us... Look, they're even on this forum!

poweroff :: 27. jul 2022, 17:47

Hmm, na OVPN clientu dam ping na WG peera (10.10.6.150)

Server pa vidi takole:

tcpdump -i wg0 icmp -v

tcpdump: listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
17:45:17.094051 IP (tos 0x0, ttl 63, id 64300, offset 0, flags [DF], proto ICMP (1), length 84)
    10.10.8.9 > 10.10.6.150: ICMP echo request, id 18, seq 1, length 64
17:45:18.148764 IP (tos 0x0, ttl 63, id 64534, offset 0, flags [DF], proto ICMP (1), length 84)
    10.10.8.9 > 10.10.6.150: ICMP echo request, id 18, seq 2, length 64

Pa še obratno:

tcpdump -i tun0 icmp -vvv

tcpdump: listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
17:49:09.209674 IP (tos 0x0, ttl 64, id 42726, offset 0, flags [DF], proto ICMP (1), length 84)
    10.10.8.9 > 10.10.6.150: ICMP echo request, id 21, seq 1, length 64
17:49:10.210760 IP (tos 0x0, ttl 64, id 42829, offset 0, flags [DF], proto ICMP (1), length 84)
    10.10.8.9 > 10.10.6.150: ICMP echo request, id 21, seq 2, length 64

Se pravi pride do serverja, a se ne zrouta pravilno.

sudo poweroff

Zgodovina sprememb…

spremenilo: poweroff (27. jul 2022 ob 17:51)

poweroff :: 27. jul 2022, 18:06

Oziroma, hmm, se zrouta. Pride do končnega klienta.

Tole poženem iz WG peera:

ping 10.10.8.151
PING 10.10.8.151 (10.10.8.151) 56(84) bytes of data.
^C
--- 10.10.8.151 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2037ms

Na OpenVPN clientu (10.10.8.151) pa tcpdump pravi tole:

sudo tcpdump -i tun0 icmp -vvv

Code: Select all

tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
17:55:57.016135 IP (tos 0x0, ttl 63, id 42350, offset 0, flags [DF], proto ICMP (1), length 84)
    10.10.6.9 > 10.10.8.151: ICMP echo request, id 24, seq 1, length 64
17:55:58.099301 IP (tos 0x0, ttl 63, id 42416, offset 0, flags [DF], proto ICMP (1), length 84)
    10.10.6.9 > 10.10.8.151: ICMP echo request, id 24, seq 2, length 64

Enako dela tudi v drugi smeri (OVPN na WG). Očitno client/peer ne zna odgovoriti v drugo omrežje...

sudo poweroff

murrieta :: 27. jul 2022, 18:42

Matthai, a lahko postas routing tabelo po tem, ko si povezan (`netstat -rn`) in konfigracijo interfacov (`ifconfig -a`)?

Sicer, ce ti pomaga, na clientu AllowedIPs = 0.0.0.0/0 pomeni, da gre ves promet skozi wireguard in ne bo sel nikamor drugam.

Zgodovina sprememb…

spremenilo: murrieta (27. jul 2022 ob 18:44)

poweroff :: 27. jul 2022, 19:50

Tole je na WG peeru.

sudo netstat -rn

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.200.1   0.0.0.0         UG        0 0          0 wlp61s0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 virbr0
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 docker0
192.168.122.0   0.0.0.0         255.255.255.0   U         0 0          0 virbr0
192.168.200.0   0.0.0.0         255.255.255.0   U         0 0          0 wlp61s0

Ampak to po moje ne pokaže vsega:

ip -4 route show table all

default dev wg0 table 51820 scope link 
default via 192.168.200.1 dev wlp61s0 proto dhcp metric 600 
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown 
192.168.200.0/24 dev wlp61s0 proto kernel scope link src 192.168.200.254 metric 600 
local 10.10.6.9 dev wg0 table local proto kernel scope host src 10.10.6.9 
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1 
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
broadcast 172.17.0.0 dev docker0 table local proto kernel scope link src 172.17.0.1 linkdown 
local 172.17.0.1 dev docker0 table local proto kernel scope host src 172.17.0.1 
broadcast 172.17.255.255 dev docker0 table local proto kernel scope link src 172.17.0.1 linkdown 
broadcast 192.168.122.0 dev virbr0 table local proto kernel scope link src 192.168.122.1 linkdown 
local 192.168.122.1 dev virbr0 table local proto kernel scope host src 192.168.122.1 
broadcast 192.168.122.255 dev virbr0 table local proto kernel scope link src 192.168.122.1 linkdown 
broadcast 192.168.200.0 dev wlp61s0 table local proto kernel scope link src 192.168.200.254 
local 192.168.200.254 dev wlp61s0 table local proto kernel scope host src 192.168.200.254 
broadcast 192.168.200.255 dev wlp61s0 table local proto kernel scope link src 192.168.200.254

ip a pa pravi:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
3: wlp61s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000
6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
10: vboxnet0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
55: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.10.6.9/32 scope global wg01: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever

murrieta je 27. jul 2022 ob 18:42 izjavil:

Sicer, ce ti pomaga, na clientu AllowedIPs = 0.0.0.0/0 pomeni, da gre ves promet skozi wireguard in ne bo sel nikamor drugam.

Ja, ampak potem na peeru, ki je debian server, bi pa moral iti v OVPN omrežje, ne?

sudo poweroff

Zgodovina sprememb…

spremenilo: poweroff (27. jul 2022 ob 19:50)

murrieta :: 27. jul 2022, 20:23

poweroff je 27. jul 2022 ob 19:50 izjavil:

Kernel IP routing table
 Destination Gateway Genmask Flags MSS Window irtt Iface
 0.0.0.0 192.168.200.1 0.0.0.0 UG 0 0 0 wlp61s0

Ok, ce pogledava samo tole, pomeni, da bo sel ves promet skozi 192.168.200.1. Maske si predstavljaj kot sito, ce bo prvo pregosto, do drugega ne bo prislo nic, se pravi ti prvi route pobere ves promet, ki do drugih interfacov sploh ne pride.

Skratka, ves promet ti gre skozi wg0.

Fuckup je, da wg nima moznosti izlocati dolocenih rangov (ne me vprasat zakaj, ko sem to videl, sem samo facepalm naredil), tako, da bos moral na izracunati maske, ki bi jih pa rad spustil skozi - oz. se bolje, LUKNJE. K sreci je ze kdo drug tudi dobil zivcni zlom in so naredili kalkulator: https://www.procustodibus.com/blog/2021...

Skratka, ce bi rad, da promet spustil do tvoje virtualke 169.254.0.0/16, bo tvoja AllowedIPs lista taka:

AllowedIPs = 0.0.0.0/1, 128.0.0.0/3, 160.0.0.0/5, 168.0.0.0/8, 169.0.0.0/9, 169.128.0.0/10, 169.192.0.0/11, 169.224.0.0/12, 169.240.0.0/13, 169.248.0.0/14, 169.252.0.0/15, 169.255.0.0/16, 170.0.0.0/7, 172.0.0.0/6, 176.0.0.0/4, 192.0.0.0/2

Ja vem, kretensko. Samo DisallowedIPs konfiguracijsko direktivo bi morali dodati, pa bi bilo precej bolje, ampak opinionated bastards radi zajebavajo uporabnike.

Zgodovina sprememb…

spremenilo: murrieta (27. jul 2022 ob 20:32)

murrieta :: 27. jul 2022, 20:36

Na serverju AllowedIPs pomeni samo, paketke iz katerega omrezja wg spusti skozi, tako, da ce imas zavarovano omrezje, lahko das tudi 0.0.0.0/0

Aja, pa se eno zadevo pazi, webguard laufa preko UDPja, se pravi, se NAT ne more uporabljati sequence numberjev v TCPju (da bi prepoznal, kaj so replyi nazaj do tvojega clienta za NATom) - ker jih v UDP paketkih ni. Obvezno preveri po koliko casa, ti NAT na routerju se smatra udp paketke kot del enega sessiona, sicer ti bo gladko odjebal promet, ima wg neko direktivo, da poslje sem in tja "keep alive" paketek, ki se je pa ne spomnim vec, malo pobrskaj.

Upam, da je kaj pomagalo.

poweroff je 27. jul 2022 ob 19:50 izjavil:

Ja, ampak potem na peeru, ki je debian server, bi pa moral iti v OVPN omrežje, ne?

Spet odvisno kaksne route ti je injectal, ampak 99% problemov z wireguardom izvira iz napacno nastavljenih routov, pa ne bi se cudil, ce imajo se kaksen bug kje. Nisem sel specificno studirati tvojega primera.

Zgodovina sprememb…

spremenilo: murrieta (27. jul 2022 ob 20:43)

murrieta :: 27. jul 2022, 20:41

Zgodovina sprememb…

spremenilo: murrieta (27. jul 2022 ob 20:42)

poweroff :: 28. jul 2022, 08:58

Na peerih že imam tole:

[Interface]
Address = 10.10.6.9/32
...
[Peer]
...
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 5

Na WG "serverju" (Debian serverju)

[Interface]
Address = 10.10.6.1/24
...
[Peer]
...
AllowedIPs = 10.10.6.9/32

Se pravi dejansko dovolim vse (na peerih), kar se tudi vidi s tcpdumpom. Vprašanje je samo zakaj nazaj ne pride...

sudo poweroff

murrieta :: 28. jul 2022, 09:38

A lahko se Debianov `ip -4 route show table all` in `ip a` pripnes?

poweroff :: 28. jul 2022, 12:18

ip -4 route show table all

default via xxx.xxx.xxx.161 dev ens3 onlink 
10.10.6.0/24 dev wg0 proto kernel scope link src 10.10.6.1 
10.10.8.0/24 dev tun0 proto kernel scope link src 10.10.8.1 
xxx.xxx.xxx.160/28 dev ens3 proto kernel scope link src xxx.xxx.xxx.171 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
172.21.0.0/16 dev br-1e352f66a0ad proto kernel scope link src 172.21.0.1 
broadcast 10.10.6.0 dev wg0 table local proto kernel scope link src 10.10.6.1 
local 10.10.6.1 dev wg0 table local proto kernel scope host src 10.10.6.1 
broadcast 10.10.6.255 dev wg0 table local proto kernel scope link src 10.10.6.1 
broadcast 10.10.8.0 dev tun0 table local proto kernel scope link src 10.10.8.1 
local 10.10.8.1 dev tun0 table local proto kernel scope host src 10.10.8.1 
broadcast 10.10.8.255 dev tun0 table local proto kernel scope link src 10.10.8.1 
broadcast xxx.xxx.xxx.160 dev ens3 table local proto kernel scope link src xxx.xxx.xxx.171 
local xxx.xxx.xxx.171 dev ens3 table local proto kernel scope host src xxx.xxx.xxx.171 
broadcast xxx.xxx.xxx.175 dev ens3 table local proto kernel scope link src xxx.xxx.xxx.171 
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1 
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
broadcast 172.17.0.0 dev docker0 table local proto kernel scope link src 172.17.0.1 linkdown 
local 172.17.0.1 dev docker0 table local proto kernel scope host src 172.17.0.1 
broadcast 172.17.255.255 dev docker0 table local proto kernel scope link src 172.17.0.1 linkdown 
broadcast 172.21.0.0 dev br-1e352f66a0ad table local proto kernel scope link src 172.21.0.1 
local 172.21.0.1 dev br-1e352f66a0ad table local proto kernel scope host src 172.21.0.1 
broadcast 172.21.255.255 dev br-1e352f66a0ad table local proto kernel scope link src 172.21.0.1

ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet xxx.xxx.xxx.171/28 brd xxx.xxx.xxx.175 scope global ens3
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
11: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    inet 10.10.8.1/24 scope global tun0
20: br-1e352f66a0ad: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    inet 172.21.0.1/16 brd 172.21.255.255 scope global br-1e352f66a0ad
22: vethd3f8cf3@if21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-1e352f66a0ad state UP group default 
23: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 10.10.6.1/24 scope global wg0

Gor laufa še PiHole docker, zato so tisti docker vmesniki.

sudo poweroff

murrieta :: 28. jul 2022, 14:48

Ok, kolikor jaz razumem tvoj NAT:
- imas en network 10.10.6.0/24, ki je WG, ki je NATan
- imas drugi network 10.10.8.0/24, ki je OV, ki ni NATan

Paket gre iz recimo 10.10.6.6 preko NAT ven iz omrezja 10.10.6.0/24, na recimo omrezje 192.168.0.0/24. Za destination pa ima naveden 10.10.8.8.

Po mojem je najbolje, da das openvpn in wg na skupni subnet (/16), pa potem poskrbi, da wg jemlje samo del tega subneta, ovpn pa drugi del, tega pa potem NATaj ven.

Zgodovina sprememb…

spremenilo: murrieta (28. jul 2022 ob 14:49)

Vredno ogleda ...

	Tema	Sporočila	Ogledi	Zadnje sporočilo
	Tema	Sporočila	Ogledi	Zadnje sporočilo
»	Wireguard routing problem poweroff Oddelek: Omrežja in internet	13	819 (447)	poweroff 15. apr 2022 21:23:35
»	dnsmasq problem poweroff Oddelek: Omrežja in internet	12	1849 (1589)	poweroff 18. avg 2017 10:10:14
»	OpenWRT in OpenVPN (strani: 1 2 ) harmony Oddelek: Omrežja in internet	79	10281 (8141)	BivšiUser2 19. nov 2016 10:24:26
»	[PHP+ArchLinux]zajem podatkov o mreznih vmesnikih KernelPanic Oddelek: Programiranje	6	1758 (1542)	KernelPanic 20. dec 2014 08:44:36
»	Kako v linuxu naštimat dva IP naslova na eni mrežni karticikartici? pro549 Oddelek: Operacijski sistemi	7	1266 (1175)	Bakunin 15. apr 2006 14:27:13

Več podobnih tem

Zadnje novice

Zadnji članki

Išči:

Forum » Omrežja in internet »
WG peeri in OpenVPN odjemalci se ne vidijo med seboj

WG peeri in OpenVPN odjemalci se ne vidijo med seboj