Ubuntu server homelab, uitdaging m.b.t. VPN en routering

[Nicko444]

Hopelijk kan iemand hier me een beetje op weg helpen m.b.t. het issue waar ik tegenaan loop.

Ik draai thuis een homelab met ubuntu server. Deze server dient een aantal doeleinden:

• Hij fungeert als VPN gateway voor een aantal LAN devices. Het betreft hier lan devices waar ik geen VPN op kan installeren en dus moet terugvallen op een constructie als deze.

Om dit voor elkaar te krijgen heb ik openvpn geinstalleerd en geconfigureerd. Hij verbindt succesvol met een vpn dienst. Vervolgens heb ik de iptables aangepast om ervoor te zorgen dat het verkeer van de LAN clients door de vpn tunnel heen stuurt. Het enige wat ik dan nog hoef te doen is in de IP settings van deze devices de gateway aan te passen naar het LAN ip adres van de ubuntu server. Ik heb daar de volgende iptable aanpassingen voor gebruikt:

bash -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT

Dit werkt, op de betreffende devices zie ik netjes het VPN public ip adress terug.

Nu wil ik ook graag een aantal ports forwarden naar mijn ubuntu server. Ik wil bijvoorbeeld een web server kunnen draaien of en aantal andere zaken remote toegankelijk maken. In de praktijk merk ik dat dit onmogelijk is zolang ik de vpn connectie aan heb staan.

Mijn vraag is dan ook:
Is het technisch gezien mogelijk om dit te realiseren? Zo ja, kan dit met ip rules en iptable aanpassingen? Of ontkom ik niet aan een tweede NIC?

Graag jullie advies

[grasmanek94]

Het is zeker mogelijk (en raar dat het niet werkt, want IP benadering is geen routing/forward request), maar qua beheer zou ik persoonlijk hiervoor je fysiek ethernet opsplitsen met een bridge naar twee virtuele interfaces. Op eentje doe je je als router gedragen voor de VPN, op de andere interface (met ander IP) host je de web server.

Wil je dat niet dan;
Het is ook mogelijk om alles op een NIC te doen, alleen dan moet je je webserver traffic accepteren en zorgen dat er verder geen andere rules worden geprocessed, ofwel een INSERT statement op -d tcp 80,443 (of evt andere web poorten), en als je HTTP/3 gebruikt ook op -d udp 80,443 (en andere poorten):

Ik ben een beetje roestig maar misschien zoiets:

code:

iptables -t nat -d 192.168.0.1 -p tcp --match multiport --dports 80,8080,443 -j ACCEPT
iptables -t nat -d 192.168.0.1 -p udp --match multiport --dports 80,8080,443 -j ACCEPT

iptables -I FORWARD -d 192.168.0.1 -p tcp --match multiport --dports 80,8080,443 -j ACCEPT
iptables -I FORWARD -d 192.168.0.1 -p udp --match multiport --dports 80,8080,443 -j ACCEPT

?

Lang geen iptables gedaan.

Verder, toch raar, wanneer clients je ip willen benaderen, zeg 192.168.0.1, dan ook al gaat het door het NAT / masquerade.. het moet toch bij je server komen? En dus te werken? Dus misschien speelt er een ander probleem en is het niet iets met je VPN setup? Een device dat je ubuntu server als gateway ziet zal toch expliciet als destination een publiek ip hebben in het packet / ethernet frame, bijvoorbeeld 11.22.33.44. Voor gateways/routing worden de ethernet frames met MAC adressen gebruikt, IPv4/6 is dus nog niet van belang. Misschien kan je dan een algemene regel maken dat als de destination in je subnet valt dat je dan ACCEPT doet en geen regels verder uitvoert. e.g.

code:

iptables -I FORWARD -d 192.168.0.0/24 -p tcp -j ACCEPT
iptables -t nat -I -d 192.168.0.0/24 -p tcp -j ACCEPT

[ Voor 25% gewijzigd door grasmanek94 op 13-06-2023 16:17 ]

[fopjurist]

grasmanek94 schreef op dinsdag 13 juni 2023 @ 16:01:
Het is zeker mogelijk (en raar dat het niet werkt, want IP benadering is geen routing/forward request

Het werkt niet omdat de verbinding naar de server wordt opgezet via de gewone internetverbinding, maar de server antwoord geeft over de VPN. Om je server via de gewone internetverbinding te laten antwoorden kun je een routing policy database gebruiken. Je kunt dat op twee manieren aanpakken:
- Standaard gaat verkeer over de vpn. Verkeer afkomstig van poort 80/443 van je server gebruikt een andere routetabel waarin de router als default gw staat. Het selecteren op poort kan met een fwmark.
- Standaard gaat verkeer niet over de VPN. Verkeer afkomstig van een aantal LAN devices gebruikt een andere routetabel die verkeer over de VPN stuurt.

[grasmanek94]

fopjurist schreef op dinsdag 13 juni 2023 @ 16:16:
[...]

Het werkt niet omdat de verbinding naar de server wordt opgezet via de gewone internetverbinding, maar de server antwoord geeft over de VPN.

Ik nam aan dat TS hier de machines op hetzelfde netwerk heeft. De internetverbinding is dus de gateway/ubuntu server. De ubuntu server heeft dan weer een internet verbinding en daarover VPN met NAT.

Ik denk dat ik dit ook ooit meegemaakt had ja, PC kreeg idd pakketjes binnen maar vanuit een andere source en die wist er niks mee te doen. Ofwel langs elkaar schreeuwen, daarin heb je gelijk - of iig dat dit een mogelijkheid is.

Maar toch apart, de server zou toch een statische route moeten kiezen als er een pakket van het LAN binnen komt?
Mochten de apparaten inderdaad de server benaderen via het tunnel ip, en dan antwoord krijgen via het LAN omdat statische routes.. dan is er een probleem ja.

Mogelijk kan dit ook een duik betekenen in de statische routering tabellen, er kan daar altijd een probleem zijn (niet de 1e keer in mijn leven dat die niet altijd goed staan).

Maar om terug te komen op de essenie; TS - je wilt dus extern je ubuntu server als web server benaderen? Dan krijg je denk ik inderdaad hetp robleme dat de VPN als standaard output verbinding gebruikt zoals @fopjurist zegt. Die computers (routers) die de webserver benaderen krijgen dan een antwoord vanaf een ander adres en weten niet wat ze ermee moeten doen.

Lokaal werkt webserver dus wel op je LAN? Want ik dacht dat het juist op LAN niet werkte
Meer koffie nodig.

[ Voor 60% gewijzigd door grasmanek94 op 13-06-2023 16:26 ]

[Nicko444]

grasmanek94 schreef op dinsdag 13 juni 2023 @ 16:19:
[...]


Ik nam aan dat TS hier de machines op hetzelfde netwerk heeft. De internetverbinding is dus de gateway/ubuntu server. De ubuntu server heeft dan weer een internet verbinding en daarover VPN met NAT.

Ik denk dat ik dit ook ooit meegemaakt had ja, PC kreeg idd pakketjes binnen maar vanuit een andere source en die wist er niks mee te doen. Ofwel langs elkaar schreeuwen, daarin heb je gelijk - of iig dat dit een mogelijkheid is.

Maar toch apart, de server zou toch een statische route moeten kiezen als er een pakket van het LAN binnen komt?
Mochten de apparaten inderdaad de server benaderen via het tunnel ip, en dan antwoord krijgen via het LAN omdat statische routes.. dan is er een probleem ja.

Mogelijk kan dit ook een duik betekenen in de statische routering tabellen, er kan daar altijd een probleem zijn (niet de 1e keer in mijn leven dat die niet altijd goed staan).

Maar om terug te komen op de essenie; TS - je wilt dus extern je ubuntu server als web server benaderen? Dan krijg je denk ik inderdaad hetp robleme dat de VPN als standaard output verbinding gebruikt zoals @fopjurist zegt. Die computers (routers) die de webserver benaderen krijgen dan een antwoord vanaf een ander adres en weten niet wat ze ermee moeten doen.

Lokaal werkt webserver dus wel op je LAN? Want ik dacht dat het juist op LAN niet werkte
Meer koffie nodig.

Klopt, ik wil mijn ubuntu server extern kunnen benaderen. Bijvoorbeeld een webserver of iets dergelijks. Lokaal gaat dit prima, als ik een docker container start met een nginx image b.v. kan ik deze probleemloos benaderen vanaf mijn desktop.

[jadjong]

Nicko444 schreef op dinsdag 13 juni 2023 @ 14:54:
Mijn vraag is dan ook:
Is het technisch gezien mogelijk om dit te realiseren? Zo ja, kan dit met ip rules en iptable aanpassingen? Of ontkom ik niet aan een tweede NIC?

Graag jullie advies

Ik ga er even van uit dat Ubuntu een VPN client is. Maak die split-tunnel. Dan wordt niet al het verkeer over de VPN geforceerd en kan je met een extra regel het verkeer uit LAN naar de VPN sturen.

[Frogmen]

Als je maar een fysieke netwerk aansluiting hebt moet je met VLANs gaan sleutelen denk ik. Snap niet zo goed de hang naar VPN gebruik zeker in deze setting zou zelf toch liever met VM's gaan werken in dit geval want het wordt super complex. Je moet echt wel een een expert op Ubuntu en netwerken zijn wil je dit op een machine werkend krijgen. Los van risico's van veiligheid en stabiliteit.

[grasmanek94]

Nicko444 schreef op dinsdag 13 juni 2023 @ 16:39:
[...]


Klopt, ik wil mijn ubuntu server extern kunnen benaderen. Bijvoorbeeld een webserver of iets dergelijks. Lokaal gaat dit prima, als ik een docker container start met een nginx image b.v. kan ik deze probleemloos benaderen vanaf mijn desktop.

Gebruik dan eventueel ook een container voor VPN/router

https://hub.docker.com/r/ekristen/openvpn-router/
+
https://github.com/ekristen/docker-openvpn-client

Zal heel wat gezeik schelen toch?

[ Voor 3% gewijzigd door grasmanek94 op 13-06-2023 21:33 ]

[Nicko444]

Bedankt voor het meedenken tot zover. Ik begrijp dat het misschien geen ideale situatie is en sta uiteraard open voor eenvoudigere oplossingen of ideeën. En openvpn router in een docker container klinkt interessant! Ben erg benieuwd of dit makkelijk te configureren is.

Ondertussen heb ik eea werkend gekregen door gebruik te maken van split tunneling. Dat in combinatie met ip route/rules en een aparte route tabel. Best complex en na een herstart van de server was ik alles weer kwijt😅

[PeeCee]

Nicko444 schreef op woensdag 14 juni 2023 @ 16:22:
Ondertussen heb ik eea werkend gekregen door gebruik te maken van split tunneling. Dat in combinatie met ip route/rules en een aparte route tabel. Best complex en na een herstart van de server was ik alles weer kwijt😅

Wat ben je precies kwijt?

Iptables
Voor IPtables rules moet je die als post-up inladen bij het starten van de netwerk interface(s).
De configuratie van de netwerk interfaces kan je vinden in /etc/network/interfaces
Hier kan je dan de iptables inladen bij opstarten van de betreffende interface (bijv. eth0) door de onderstaande regel toe te voegen:

post-up iptables-restore < /etc/iptables.up.rules

Mijn de aanname dat je iptables rules in bestand /etc/iptables.up.rules staan.
Dan krijg je iets als:

allow-hotplug eth0
iface eth0 inet static
address 192.168.0.1/24
gateway 192.168.0.254
dns-nameservers 192.168.0.254
post-up iptables-restore < /etc/iptables.up.rules

IP rule / Route
Hiervoor geld eigenlijk het zelfde. Als je een ip rule of ip route mee op wil laten starten, kan je die hier opnemen, bijv.:

post-up ip rule add fwmark 0x1 lookup 100
post-up ip route add local 0.0.0.0/0 dev lo table 100

Dan krijg je iets als:

allow-hotplug eth0
iface eth0 inet static
address 192.168.0.1/24
gateway 192.168.0.254
dns-nameservers 192.168.0.254
post-up iptables-restore < /etc/iptables.up.rules
post-up ip rule add fwmark 0x1 lookup 100
post-up ip route add local 0.0.0.0/0 dev lo table 100

Meer info: https://manpages.ubuntu.c...ty/man5/interfaces.5.html

[Nicko444]

Bedankt allemaal. alles lijkt te werken zoals ik had bedacht.
Op 1 punt na: DNS.
Zodra ik op een lan client de gateway en DNS server zo instel dat ze naar de ubuntu server verwijzen en dus via de VPN naar buiten gaan gaat DNS stuk. Clients hebben wel internet (pingen naar externe ip adressen werkt prima), alleen websites bezoeken lukt niet. In de eerste instantie wilde ik de dns requests rechtstreeks vanaf de lan clients naar 8.8.8.8 laten wijzen. Echter viel het me op dat de clients die verbonden zijn via de ubuntu server met een VPN tegen een geoblokkade aanlopen op bijvoorbeeld videoland. Best wel bijzonder omdat ik gebruik maak van een nederlandse VPN.

Ik heb in /etc/systemd/resolved.conf het volgende staan:

code:

DNS=8.8.8.8
FallbackDNS=8.8.4.4
DNSStubListener=eno1,tun0

Toch blijkt dit niet te werken, iemand ideeen?

[PeeCee]

Wat is nu precies de opzet die je hebt gemaakt? Hoe zit je spinnenweb in elkaar :-p

En is door je vpn provider niets geblokkeerd? Kan mij zo voorstellen dat dns van google een tracking ding zijn. Heeft je vpn provider geen dns beschikbaar?