Wireguard met meerdere webservers

[LED-Maniak]

Onderstaande setup heb ik gemaakt met een VPS en een raspberry pi.

Doel is dat als er een request binnen komt naar 195.xxx.xxx.131:80 dat de server met IP 192.168.4.3 hier op reageert en zo verder.

Met één server lukt dit prima, maar met meerdere servers niet(de request komt wel goed binnen van 195.xxx.xxx.131 maar uitgaande berichten gaan via 195.xxx.xxx.130). Er gaat iets mis in de routing.

Het lijkt er op dat wireguard het originele IP adres 192.168.4.2 vervangt voor 192.168.6.3. Hierdoor kan ik dit pakketje niet doorsturen naar het juiste WAN IP-adres. Masquerading op de client staat uit.


Is het mogelijk dat wireguard het originele IP adres niet aanpast zodat ik bij de server hier op kan filteren en doorsturen naar de juiste IP?



Client:

code:

[Interface]
## This Desktop/client's private key ##
PrivateKey = xxxxxx

## Client ip address ##
Address = 192.168.6.3/24

MTU=1280

PreUp = sysctl -w net.ipv4.ip_forward=1

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT

[Peer]
PublicKey = xxxxxxx

AllowedIPs = 0.0.0.0/0

Endpoint = 195.xxx.xxx.xxx:41194

PersistentKeepalive = 25

Server:

code:

[Interface]
Address = 192.168.6.1/24

ListenPort = 41194

PrivateKey = xxxx

# packet forwarding
PreUp = sysctl -w net.ipv4.ip_forward=1
PostUp = iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1280
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT;
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostUp = iptables -A FORWARD -i eth0 -o wg0 -p tcp --syn --dport 80 -m conntrack --ctstate NEW -j ACCEPT
PostUp = iptables -A FORWARD -i eth0 -o wg0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
PostUp = iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.168.4.2

PostDown = iptables -D FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1280
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT;
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i eth0 -o wg0 -p tcp --syn --dport 80 -m conntrack --ctstate NEW -j ACCEPT
PostDown = iptables -D FORWARD -i eth0 -o wg0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
PostDown = iptables -t nat -D PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.168.4.2

[Peer]
## Desktop/client VPN public key ##
PublicKey = YZuLyDLUcxN9fUp84Dq+dFVWR4nW/wv+RnD1ADNZvlc=

## client VPN IP address (note  the /32 subnet) ##
AllowedIPs = 192.168.4.0/24, 192.168.6.0/24

[ Voor 52% gewijzigd door LED-Maniak op 30-10-2021 12:07 ]

[thijsjek]

Ik heb zelf meerdere peers in mijn server config. Met elk een toegestaan op adres (dus 1 connectie per client/IP)
Server:

code:

[Interface]
Address = 192.168.1.1/32
PrivateKey = 
ListenPort = 51820

[Peer]
#P30 pro
PublicKey = 
PreSharedKey = 
AllowedIPs = 192.168.1.2/32

[Peer]
#MSI-laptop
PublicKey = 
PreSharedKey = 
AllowedIPs = 192.168.1.3/32

Clients:

code:

Interface]
Address = 192.168.1.2/32
DNS = 192.168.2.240, 192.168.2.241
PrivateKey = 

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = x.x.x.x:51820
PreSharedKey = 
PublicKey =

Hiermee weet je dus 100% zeker dat een connectie een bepaald ip heeft. Je moet dan wel 3 aparte VPN verbindingen maken.

Waarom heb je bijvoorbeeld niet een reverse proxy server draaien waardoor dit niet van toepassing is? Ik heb wel 20 webservers op verschillende poorten, eventueel bereikbaar vanaf t internet met een sub/domein. Een eigen wan voor 1 applicatie is wat extreem (als je die dan weer naar een pi doorlust)

[ Voor 17% gewijzigd door thijsjek op 31-10-2021 02:36 ]

[DiedX]

Eerste oplossing: ha-proxy.

Is er een route gezet op de tweede webserver? Ik weet net te weinig af van wire guard, maar kan mij voorstellen dat de webserver een ander net mask heeft.

[thijsjek]

Maar misschien is meer informatie handiger wat je probeert te bereiken.
Het lijkt mij dat jij jezelf het moeilijk maakt. Er is waarschijnlijk al software die 90% doet wat je wil.

[jadjong]

LED-Maniak schreef op zaterdag 30 oktober 2021 @ 11:59:
Met één server lukt dit prima, maar met meerdere servers niet(de request komt wel goed binnen van 195.xxx.xxx.131 maar uitgaande berichten gaan via 195.xxx.xxx.130). Er gaat iets mis in de routing.

Dat klopt. 1.2.3.4 doet een request op 195.x.x.131. Die stuurt het intern door naar 192.168.4.3.
192.168.4.3 reageert daar op door een pakketje naar 1.2.3.4 te sturen. Echter is 1.2.3.4 niet in het interne netwerk maar het wereld wijde web. De default gateway naar het wereld wijde web is 192.168.6.1.(via 192.168.4.1&192.168.6.3) Maar wat is de default gateway vanaf 192.168.6.1? Waarschijnlijk eth0, oftewel 195.x.x.130.
Je moet dus even vertellen dat pakketjes vanaf 192.168.4.3 altijd via 195.x.x.131 naar buiten vliegen.

_{Nginx, HA-proxy.}

[LED-Maniak]

Na een hoop zwoegen heb ik het probleem deels kunnen oplossen:

Raspberry pi vervangen voor een router met OpenWRT.
In de router stuur ik lokaal verkeer van elke webserver door naar een eigen client binnen wg0(zoals @thijsjek al suggereerde). Dus de WG server ziet nu 3 verschillende wireguard IP's en daardoor kan ik eenvoudig de data door routen naar het juiste WAN IP.

Elke webserver ziet nu het correcte externe adres, dus dat is al een grote stap vooruit!
Alleen de poort krijg ik nog niet juist open. Denk dat OpenWRT in dit geval een blokkade opwerpt.


Forward van de pakketjes heb ik nu zo opgelost, elk WAN IP dus een eigen forward naar een client/connectie:

code:

PostUp = iptables -t nat -A PREROUTING -i eth0 -d 195.xxx.xxx.130 -j DNAT --to-destination 192.168.6.4
PostUp = iptables -t nat -A POSTROUTING -o eth0 -s 192.168.6.4 -j SNAT --to-source 195.xxx.xxx.130

Er van uitgaande dat hierdoor ALLE data wordt doorgestuurd inclusief alle poorten?
in UFW heb ik port 80 open gezet. Ik neem aan dat dit geldig is voor alle eth0 aliassen/WAN IP's.

Alleen portchecker.co geeft nog steeds aan dat de poort dicht is helaas(als netcat uit staat en de route weer hersteld is).

[edit]
Als ik de forward niet doe en ik gebruik netcat om te luisteren op de server dan staat de juiste poort open.
Dus het gaat nu ergens fout in OpenWRT.

[ Voor 43% gewijzigd door LED-Maniak op 31-10-2021 10:51 ]

[Faifz]

Bevat de router de publieke adressen (195.x) nu of niet?

[LED-Maniak]

Nee, maar het lijkt nu opgelost door ook in de router op de juiste manieren de poorten te forwarden!