Domein via extern niet bereikbaar door OpenVPN Client

[fvs]

Beste Tweakers,

Ik heb achter mijn router een Ubuntu server draaien, welke ik als webserver wil gaan gebruiken. De apache vhost is geconfigureerd, ufw poort 80 staat open en in de router staat een port forward op poort 80 naar de webserver.

Tevens heb ik een domein die naar mijn IP verwijsd. Als ik naar <mijndomein>.nl ga vanuit mijn interne netwerk, dan werkt alles goed. Echter als ik <mijndomein>.nl vanuit een externe netwerk bezoek, dan krijg ik een server timeout.

Nu heb ik het probleem gevonden en die ligt bij de OpenVPN client die op de server draait. De server staat 24/7 verbonden met een OpenVPN verbinding. Als ik deze disable, is <mijndomein>.nl wel bereikbaar vanaf een extern IP adres.

Het probleem zal te maken hebben met het gebruik van verschillende interfaces (eth0 vs tun), verschil publiek IP en VPN IP, of wellicht moet ik iets aanvullends in mijn apache vhost configureren. Helaas kom ik er niet meer uit. Weten jullie een manier hoe ik zowel de OpenVPN verbinding kan latern draaien, als de webserver kan laten werken? De webserver mag van mij onder mijn publiek IP draaien.

[_Hades_]

Krijgt de server een default gateway gepushed via de openvpn? Dan zal dat de reden zijn waarom het niet werkt (return pakketje gaan de tunnel in). Zo ja dan of zorgen dat je server de tunnel niet gebruikt als default gw, of het webverkeer sourcenatten op je router zodat lijkt alsof de requests van je interne lan komen.

[Room42]

Waarschijnlijk wordt al het verkeer door de tunnel geleidt als de VPN-verbinding open staat. Doe maar eens een wget van https://api.ipify.org/ -qO-:

wget https://api.ipify.org/ -qO-

Je zult zien dat je het IP-adres van de andere kant van de VPN-tunnel krijgt. Verbreek je de verbinding en je doet weer een wget, krijg je je eigen publieke IP-adres te zien.

[nielsl]

Room42 schreef op maandag 1 mei 2017 @ 20:40:
Waarschijnlijk wordt al het verkeer door de tunnel geleidt als de VPN-verbinding open staat. Doe maar eens een wget van https://api.ipify.org/ -qO-:

wget https://api.ipify.org/ -qO-

Je zult zien dat je het IP-adres van de andere kant van de VPN-tunnel krijgt. Verbreek je de verbinding en je doet weer een wget, krijg je je eigen publieke IP-adres te zien.

Als dat het geval is, moet je ook de interne DNS gebruiken. Op die manier krijg je, als je via VPN verbonden bent, ook het interne antwoord terug. Op die manier blijft deze verkeersstroom in zijn geheel binnen. Zie voor de precieze configuratie parameter https://openvpn.net/index...mentation/howto.html#dhcp

[fvs]

Bedankt voor de reacties! Het verkeer wordt inderdaad via de tunnel geleidt en dat is ook de bedoeling, graag zou ik alleen voor de webserver een uitzondering maken. Sourcenatten lijkt me een goede optie, alleen ik ben hier nog niet mee bekend. Moet dit via iptables?

Ik vond het volgende via Google:
IPTABLES -t nat -A POSTROUTING -o eth0.0 -p tcp -d xxx.xx.xx.8 -j SNAT --to-source xxx.xx.xx.238

- eth0 is de adapter
- Het eerste TCP adres is de public ip, het --to-source adres is de LAN ip.

Heb ik het dan goed begrepen? Kan ik nog instellen dat het alleen om poort 80 gaat?

[ Voor 4% gewijzigd door fvs op 02-05-2017 11:26 ]

[nielsl]

Waarom zou je dit voor de webserver anders willen routeren? Maargoed, als je het al wilt moet je kijken of je bij het pushen van 0.0.0.0/0 een uitzondering kan maken voor het specifieke externe IP adres van je webserver, zodat die via de default GW van je fysieke verbindingsmedium verloopt. Je wilt dit dus op de cliënt regelen, en niet op de server. Zoeken of je met routeren voor dat adres/32 een uitzondering kunt maken en die kunt pushen

[fvs]

De reden dat ik het wil is dat het verkeer op de server via de VPN voor zover mogelijk anoniem wil laten verlopen, echter voor het bereik van <mijndomein.nl> is dit blijkbaar niet mogelijk? Of kan ik alles via de VPN laten lopen?

[ Voor 9% gewijzigd door fvs op 02-05-2017 13:31 ]

[_Hades_]

dat sourcenatten moet gebeuren op de voorliggende router, zodat je webserver denkt dat deze communiceert met een apparaat in het interne LAN.

[MasterL]

Als ik het goed begrijp heb je 1 Ubuntu server waar de OpenVPN cliënt op draait.
Indien de VPN connectie actief is heb je 2 default/0.0.0.0 gateways:

- default gateway op eth0 interface
- default gateway op tun interface

Degene met de laagste metric (commando route) is de actieve default gateway.
Wat er denk ik gebeurt is het volgende, een cliënt (1.2.3.4) probeert jouw website te bezoeken (komt een pakket binnen op eth0). Jouw server probeert een pakket terug te sturen naar 1.2.3.4 en gebruikt hiervoor de default gateway aangezien 1.2.3.4 niet in hetzelfde subnet zit als de (Ubuntu) server.
De default gateway op de tun interface heeft de laagste metric dus jouw server stuurt een pakket terug via de OpenVPN gateway. Resultaat: het werkt niet aangezien het pakket terug gestuurd had moeten worden naar de gateway via eth0.

Hetzelfde scenario kan gebeuren met een dual WAN setup (2 interfaces, 2 verschillende gateways).
Ik zou dit zelf oplossen door het verkeer te markeren (mark), hierbij markeer je het verkeer wat binnenkomt op bijvoorbeeld eth0 (connectie op poort 80), vervolgens route je dit gemarkeerde verkeer terug via de "goede" gateway. Dit kan je ook doen voor OpenVPN (tun) als hier inkomende connecties op binnen komen.

Ik neem aan dat de Ubuntu server zelf geen router/gateway is voor andere devices?
Zo niet kom je hier waarschijnlijk gewoon mee weg zonder überhaupt NAT te gebruiken, je kunt hiervoor ip2route gebruiken:

https://www.adampalmer.me...ultiple-default-gateways/

[nielsl]

MasterL schreef op woensdag 3 mei 2017 @ 10:22:
Als ik het goed begrijp heb je 1 Ubuntu server waar de OpenVPN cliënt op draait.
Indien de VPN connectie actief is heb je 2 default/0.0.0.0 gateways:

- default gateway op eth0 interface
- default gateway op tun interface

Degene met de laagste metric (commando route) is de actieve default gateway.
Wat er denk ik gebeurt is het volgende, een cliënt (1.2.3.4) probeert jouw website te bezoeken (komt een pakket binnen op eth0). Jouw server probeert een pakket terug te sturen naar 1.2.3.4 en gebruikt hiervoor de default gateway aangezien 1.2.3.4 niet in hetzelfde subnet zit als de (Ubuntu) server.
De default gateway op de tun interface heeft de laagste metric dus jouw server stuurt een pakket terug via de OpenVPN gateway. Resultaat: het werkt niet aangezien het pakket terug gestuurd had moeten worden naar de gateway via eth0.

Hetzelfde scenario kan gebeuren met een dual WAN setup (2 interfaces, 2 verschillende gateways).
Ik zou dit zelf oplossen door het verkeer te markeren (mark), hierbij markeer je het verkeer wat binnenkomt op bijvoorbeeld eth0 (connectie op poort 80), vervolgens route je dit gemarkeerde verkeer terug via de "goede" gateway. Dit kan je ook doen voor OpenVPN (tun) als hier inkomende connecties op binnen komen.

Ik neem aan dat de Ubuntu server zelf geen router/gateway is voor andere devices?
Zo niet kom je hier waarschijnlijk gewoon mee weg zonder überhaupt NAT te gebruiken, je kunt hiervoor ip2route gebruiken:

https://www.adampalmer.me...ultiple-default-gateways/

Ik denk niet dat dat gebeurt, want de tun0 interface zal waarschijnlijk in hetzelfde subnet zitten als de VPN clients, en dus wordt die route regel voor dat specifieke /24 subnet gebruikt om terug te routeren. Zoals TS aangeeft krijgt hij ook netjes het IP adres van zijn VPN server als hij buiten is en sites als whatismyip.com bezoekt. De default gateway van VPN client -> VPN server -> internet Lijkt dus te werken.

Wat ik denk dat gebeurt is het volgende. als je VPN verbinding hebt en je bent buiten de deur en je wilt naar www.jouwdomein.nl gaan, krijg je het externe IP adres terug. Als je hier naartoe gaat, stuur je het verzoek om naar 1.2.3.4 te gaan (het externe IP adres van je modem). Verkeer gaat vanaf je laptop over je VPN tunnel, naar je server, die dat vrolijk naar de default gateway stuurt (je modem). Eenmaal daar aangekomen zegt je modem "mooi, je bent er, want je komt van LAN". Je wordt dus niet teruggeNAT naar je webserver, want dat is alleen van toepassing als je vanaf het WAN komt.

Snelste oplossing: split brain DNS. Als je binnen het netwerk bent (VPN of thuis) en je bezoekt je website krijg je het lokale adres van je webserver terug, van de DNS server die je ook lokaal hebt draaien Ben je buiten de deur en heb je geen VPN verbinding krijg je het publieke IP adres terug van de DNS server waar je je query op afvuurt.

[ Voor 4% gewijzigd door nielsl op 03-05-2017 12:26 ]

[Orion84]

@nielsl hij heeft het over een VPN client op zijn webserver, niet een VPN server. Dus jouw verhaal gaat volgens mij niet op.

@fvs heb je bij de VPN tunnel die je webserver gebruikt niet ook een adres aan het eind van de tunnel wat je kan gebruiken om te koppelen aan je domein? Zodat het inkomende verkeer ook via de tunnel loopt?

[MasterL]

nielsl schreef op woensdag 3 mei 2017 @ 12:25:
[...]


Ik denk niet dat dat gebeurt, want de tun0 interface zal waarschijnlijk in hetzelfde subnet zitten als de VPN clients, en dus wordt die route regel voor dat specifieke /24 subnet gebruikt om terug te routeren. Zoals TS aangeeft krijgt hij ook netjes het IP adres van zijn VPN server als hij buiten is en sites als whatismyip.com bezoekt. De default gateway van VPN client -> VPN server -> internet Lijkt dus te werken.

Wat ik denk dat gebeurt is het volgende. als je VPN verbinding hebt en je bent buiten de deur en je wilt naar www.jouwdomein.nl gaan, krijg je het externe IP adres terug. Als je hier naartoe gaat, stuur je het verzoek om naar 1.2.3.4 te gaan (het externe IP adres van je modem). Verkeer gaat vanaf je laptop over je VPN tunnel, naar je server, die dat vrolijk naar de default gateway stuurt (je modem). Eenmaal daar aangekomen zegt je modem "mooi, je bent er, want je komt van LAN". Je wordt dus niet teruggeNAT naar je webserver, want dat is alleen van toepassing als je vanaf het WAN komt.

Snelste oplossing: split brain DNS. Als je binnen het netwerk bent (VPN of thuis) en je bezoekt je website krijg je het lokale adres van je webserver terug, van de DNS server die je ook lokaal hebt draaien Ben je buiten de deur en heb je geen VPN verbinding krijg je het publieke IP adres terug van de DNS server waar je je query op afvuurt.

Dat is waar als de Ubuntu server een OpenVPN server is, TS geeft aan dat deze een OpenVPN Client draait.

fvs schreef op maandag 1 mei 2017 @ 20:35:
Nu heb ik het probleem gevonden en die ligt bij de OpenVPN client die op de server draait. De server staat 24/7 verbonden met een OpenVPN verbinding. Als ik deze disable, is <mijndomein>.nl wel bereikbaar vanaf een extern IP adres.

fvs schreef op dinsdag 2 mei 2017 @ 12:56:
De reden dat ik het wil is dat het verkeer op de server via de VPN voor zover mogelijk anoniem wil laten verlopen, echter voor het bereik van <mijndomein.nl> is dit blijkbaar niet mogelijk? Of kan ik alles via de VPN laten lopen?

Het lijkt erop alsof TS op zijn server een OpenVPN client heeft draaien (van een VPN provider o.i.d.) en dat wanneer de VPN actief is zijn website (extern) niet te bereiken is.

Misschien kan TS de casus nogmaals duidelijk omschrijven?

Orion84 schreef op woensdag 3 mei 2017 @ 12:33:
@nielsl hij heeft het over een VPN client op zijn webserver, niet een VPN server. Dus jouw verhaal gaat volgens mij niet op.

@fvs heb je bij de VPN tunnel die je webserver gebruikt niet ook een adres aan het eind van de tunnel wat je kan gebruiken om te koppelen aan je domein? Zodat het inkomende verkeer ook via de tunnel loopt?

Volgens mij zijn dit in het geval van een VPN provider doorgaans RFC1918 adressen die door de VPN provider zelf "ergens" geNAT worden. Inkomende connecties lijken mij daardoor niet mogelijk.

[ Voor 11% gewijzigd door MasterL op 03-05-2017 12:38 ]

[nielsl]

Orion84 schreef op woensdag 3 mei 2017 @ 12:33:
@nielsl hij heeft het over een VPN client op zijn webserver, niet een VPN server. Dus jouw verhaal gaat volgens mij niet op.

@fvs heb je bij de VPN tunnel die je webserver gebruikt niet ook een adres aan het eind van de tunnel wat je kan gebruiken om te koppelen aan je domein? Zodat het inkomende verkeer ook via de tunnel loopt?

Check, tl;dr. Dan sluit ik me aan bij het eth0/tun0 verhaal!

[fvs]

Bedankt voor de reacties! Het is denk ik zoals @MasterL omschrijft.

Mijn Ubuntu Server draait een VPN Client van een externe VPN provider. Inderdaad, als de VPN actief is kan ik vanaf het interne netwerk mijn website wel bereiken. Niet vanaf een extern netwerk (bijvoorbeeld via mobiel internet). Als ik de VPN uitzet is de website wel te bereiken vanaf het extern netwerk.

Ik denk dat onderstaand verhaal van @MasterL precies mijn situatie weergeeft:

MasterL schreef op woensdag 3 mei 2017 @ 10:22:

Degene met de laagste metric (commando route) is de actieve default gateway.
Wat er denk ik gebeurt is het volgende, een cliënt (1.2.3.4) probeert jouw website te bezoeken (komt een pakket binnen op eth0). Jouw server probeert een pakket terug te sturen naar 1.2.3.4 en gebruikt hiervoor de default gateway aangezien 1.2.3.4 niet in hetzelfde subnet zit als de (Ubuntu) server.
De default gateway op de tun interface heeft de laagste metric dus jouw server stuurt een pakket terug via de OpenVPN gateway. Resultaat: het werkt niet aangezien het pakket terug gestuurd had moeten worden naar de gateway via eth0.

De server is inderdaad geen standaard router/gateway voor andere apparaten. Ik ga me verdiepen in ip2route!

Dit krijg ik overigens in mijn terminal te zien:

code:

user@server:~$ ifconfig
enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.2.138  netmask 255.255.255.0  broadcast 192.168.2.255
        inet6 fe80::5d9d:64db:a62b:a17b  prefixlen 64  scopeid 0x20<link>
        ether 4c:cc:6a:ba:34:05  txqueuelen 1000  (Ethernet)
        RX packets 12283  bytes 10283930 (10.2 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6845  bytes 1141272 (1.1 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1331  bytes 198780 (198.7 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1331  bytes 198780 (198.7 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.7.7.71  netmask 255.255.255.0  destination 10.7.7.71
        inet6 fe80::8444:3fde:8bdd:aac6  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 732  bytes 190302 (190.3 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 999  bytes 106715 (106.7 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

code:

user@server:~$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.7.7.1        128.0.0.0       UG        0 0          0 tun0
0.0.0.0         192.168.2.1     0.0.0.0         UG        0 0          0 enp2s0
10.7.7.0        0.0.0.0         255.255.255.0   U         0 0          0 tun0
109.202.102.86  192.168.2.1     255.255.255.255 UGH       0 0          0 enp2s0
128.0.0.0       10.7.7.1        128.0.0.0       UG        0 0          0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 enp2s0
192.168.2.0     0.0.0.0         255.255.255.0   U         0 0          0 enp2s0

code:

user@server:~$ ip route list
0.0.0.0/1 via 10.7.7.1 dev tun0
default via 192.168.2.1 dev enp2s0 proto static metric 100
10.7.7.0/24 dev tun0 proto kernel scope link src 10.7.7.71
109.202.102.86 via 192.168.2.1 dev enp2s0
128.0.0.0/1 via 10.7.7.1 dev tun0
169.254.0.0/16 dev enp2s0 scope link metric 1000
192.168.2.0/24 dev enp2s0 proto kernel scope link src 192.168.2.138 metric 100

code:

user@server:~$ ip rule show
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

[ Voor 87% gewijzigd door fvs op 05-05-2017 16:23 ]

[terror538]

als je wilt source-natten dan moet je dat doen op de router, waar het portforwarden gebeurt /niet/ op de webserver. Nadeel is wel dus dat je in je logs alle verkeer van het IP van je router ziet komen.

Een derde optie is een transparante reverse proxy ervoor zetten (die eventueel cached) dan kan je namelijk nog een http header meegeven die aangeeft dat het verkeer geforward is voor IP X (X-Forwarded-For) dat kan je dan weer parsen in je logs zodat deze het IP goed weergeven. Eigenlijk dus alleen interessant als je de logging belangrijk vind Dat moet natuurlijk wél op een andere bak plaatsvinden (of op je router, als je iets als openwrt draait)

-edit- het kan blijkbaar ook door namespaces te gebruiken op je server, wellicht de meest KISS oplossing:
https://superuser.com/que...ce-for-a-process-in-linux

[ Voor 13% gewijzigd door terror538 op 04-05-2017 21:02 ]

[fvs]

Opgelost! Door wat zoektermen die ik in dit topic heb opgedaan kwam ik uit bij

https://serverfault.com/questions/794887/how-to-make-apache-output-packets-through-a-certain-network-interface-when-conne

Ik heb het volgende gedaan.

Een nieuwe default route aangemaakt

echo "1 apache" >> /etc/iproute2/rt_tables

Script aangemaakt in /etc/network/if-up.d/enp2s0-post-up met als content:

#!/bin/sh
# filename: enp2s0-post-up

if [ "$IFACE" = enp2s0 ]; then
        ip addr add 192.168.2.139/24 dev enp2s0
        ip route add default via 192.168.2.1 dev enp2s0 table apache
        ip rule add from 192.168.2.139 table apache
fi

Hierbij is enp2s0 mijn interface. Ik begrijp het zelf nog niet helemaal, maar deze regels zorgen ervoor dat een tweede IP adres wordt aangemaakt op deze interface en dat al het verkeer wat binnekomt via dit IP adres ook weer via dit IP adres naar buiten gaat. Vervolgens heb ik in mijn router de port forwarding van poort 80 gewijzigd naar dit IP adres.

Zorgen dat het script ook uitgevoerd kan worden

sudo chmod +x /etc/network/if-up.d/enp2s0-post-up

Vervolgens in /etc/network/interfaces de volgende regels toevoegd:

auto enp2s0
iface enp2s0 inet dhcp
post-up /etc/network/if-up.d/enp2s0-post-up

Dit zorgt ervoor dat het script wordt uitgevoerd als de interface aan gaat. de IP commando's in de terminal vergaan na een reboot, vandaar dat het via deze weg moet.

Vervolgens de networking en apache service restarten en dan ben je klaar!

[Orion84]

En je VPN tunnel werkt dan ook nog zoals zou moeten? Dus al het niet-apache verkeer gaat via de originele interface en dus via de tunnel naar buiten?

[fvs]

Als ik een traceroute naar Google doe krijg ik het volgende:

traceroute to google.nl (216.58.212.227), 30 hops max, 60 byte packets
 1  10.7.7.1 (10.7.7.1)  10.694 ms  22.843 ms  76.231 ms
 2  hosted-by.global-layer.com (109.202.102.65)  76.257 ms  76.205 ms  76.192 ms
 3  ae5-218.RT.TC2.AMS.NL.retn.net (87.245.246.40)  76.149 ms  76.102 ms  76.029 ms
 4  GW-Google.retn.net (87.245.246.22)  76.063 ms  75.986 ms  75.973 ms
 5  108.170.241.193 (108.170.241.193)  75.890 ms  75.931 ms  75.862 ms
 6  216.239.42.3 (216.239.42.3)  75.825 ms 216.239.42.175 (216.239.42.175)  13.716 ms 216.239.42.3 (216.239.42.3)  14.676 ms
 7  ams16s22-in-f227.1e100.net (216.58.212.227)  83.632 ms  28.997 ms  83.585 ms

Via route -n zie ik het volgende:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.7.7.1        128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 enp2s0
10.7.7.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
109.202.102.86  192.168.2.1     255.255.255.255 UGH   0      0        0 enp2s0
128.0.0.0       10.7.7.1        128.0.0.0       UG    0      0        0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 enp2s0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 enp2s0

IP 10.7.7.1 die terugkomt via de traceroute is de gateway van de tun0 interface. Dus dat gaat goed lijkt me?

Heb net ook nog bij Deluge gekeken en daar verschijnt ook de IP van de OpenVPN provider. Dus lijkt goed te gaan

@Orion84 Kan ik nog meer doen om dit goed te testen?

[ Voor 4% gewijzigd door fvs op 09-05-2017 15:40 ]