VPN verkeer alleen gebruiken in virtuele python omgeving

[Erpenator2]

Ik probeer via een bash script een venv omgeving te starten om daar een python script met eigen dependencies te laten runnen. Dat werkt prima.

Nu is het voor een specifiek python script nodig om connecties te leggen met externe servers over een VPN verbinding. Het probleem is dat zodra het script gestart is en er een VPN verbinding is voor dit python proces ik extern geen toegang meer kan krijgen tot de (debian) server waar dit script draait. Wanneer ik de server vanuit een ander lokaal ip probeer te benaderen kan ik wel gewoon toegang krijgen. Het doel is om al het verkeer dat nodig is voor dit python proces over de vpn verbinding te laten lopen en het "normale" netwerkverkeer naar binnen of buiten toe onaangeraakt te laten.

Middels AI heb ik tal van opties uitgezocht, waaronder het aanmaken van een virtuele adapter, maar dit lijkt niet te werken. Dat kan mogelijk zijn omdat ik het verkeerd inricht. Maar in alle uitgeprobeerde gevallen blijft al het verkeer over de VPN verbinding gaan.

Een van de opties die naar voren kwam was Split Tunneling, maar de VPN client lijkt dit niet te ondersteunen. De VPN client is gebaseerd op OpenVPN dus mogelijk dat via die weg dit toch nog mogelijk zou zijn.

Iemand een idee hoe dit het beste aan te pakken?

[CyBeRSPiN]

Kun je het in een docker container draaien misschien? Of anders in een VM (virtual box).

[Erpenator2]

Ik sta open voor alle opties.

Dat zou denk ik wel kunnen al ben ik (nog) niet goed bekend met docker container.

Ben wel bekend met VM, maar dit draait nog niet op deze server. Ik heb de optie van ProxMox bekeken en op een testomgeving draaien, maar kon zo snel niet vinden of dat dit dan het probleem zou oplossen. Ook zag ik dat je voor ProxMox eigenlijk het beste een clean install kon doen en dan de rest installeren? Het lijkt mij ook de meest robuuste oplossing op meerdere fronten, maar weet niet of je met VM ook ProxMox bedoelde?

[fopjurist]

Het makkelijkste is om een network namespace te gebruiken. Je Pythonscript gebruikt dan zijn eigen netwerkstack.

Er zijn scriptjes waarmee je eenvoudig OpenVPN in zo'n namespace draait, zoals https://github.com/slingamn/namespaced-openvpn

[i-chat]

wat ik in deze casus een beetje mis is de gebruikte config,
als ik in linux een VPN-config aanmaak kan ik daarin gewoon een een bepaald netwerk subnet in advertisen, mijn default rout is dan nog gewoon 192.168.router.ip voor voor één enkel netwerk segment gebruik je dan een andere virtuele-adapter. en de 'routing' op het hoofd-os laten, wil je dat nou niet, dan zou ik niet naar named-networking kijken maar direct helemaal naar lagen-scheiding neigen en dus op iets van docker of k3s uitkomen. in dat geval moet je de config natuurlijk wel verplaatsen naar binnen je container.

[oohh]

Geen idee welke distro je gebruikt maar met systemd kun je proxy variabelen doorgeven. Als je een lokale proxy opzet kun je de python env laten praten met extern verkeer zonder dat je pc onbereikbaar wordt

Dit is een random linkje, maar je kunt deze variabelen ook in een systemd service zetten:

https://www.golinuxcloud....oxy-environment-variable/

[Erpenator2]

i-chat schreef op zaterdag 30 november 2024 @ 21:46:
wat ik in deze casus een beetje mis is de gebruikte config,
als ik in linux een VPN-config aanmaak kan ik daarin gewoon een een bepaald netwerk subnet in advertisen, mijn default rout is dan nog gewoon 192.168.router.ip voor voor één enkel netwerk segment gebruik je dan een andere virtuele-adapter. en de 'routing' op het hoofd-os laten, wil je dat nou niet, dan zou ik niet naar named-networking kijken maar direct helemaal naar lagen-scheiding neigen en dus op iets van docker of k3s uitkomen. in dat geval moet je de config natuurlijk wel verplaatsen naar binnen je container.

In het begin heb ik gebruik gemaakt van een door AI gegenereerd bash script dat voor ik mijn venv start een tijdelijke routing voor het VPN verkeer aanmaakt. Maar deze werkt niet. Omdat ik onvoldoende thuis ben in de details van dit specifieke deel heb ik geen oplossing kunnen vinden, maar een deel van de config/code welke gebruikt heb is:

De VPN provider genereerd de openvpn config files op basis van mijn VPN profiel, de exacte config heb ik niet bekeken, maar ga ik nog eens doen. Met onderstaande config kon de VPN tunnel i.i.g niet opgezet worden, omdat het de route niet kon vinden naar de VPN server om mee te connecten, met als error Cannot resolve host address. Omdat ik mijn huidige netwerk instellingen niet helemaal overhoop wilde gooien ben ik toen van dit pad afgehaakt.

code:

sudo ip netns add vpn-ns
sudo ip link add veth0 type veth peer name veth1
sudo ip link set veth1 netns vpn-ns
sudo ip addr add 192.168.1.1/24 dev veth0
sudo ip link set veth0 up
sudo ip netns exec vpn-ns ip addr add 192.168.1.2/24 dev veth1
sudo ip netns exec vpn-ns ip link set veth1 up
sudo ip netns exec vpn-ns ip link set lo up
sudo ip netns exec vpn-ns ip route add default via 192.168.1.1

sudo ip netns exec vpn-ns openvpn --config /path/to/client.ovpn

python3 -m venv myenv
source myenv/bin/activate
sudo ip netns exec vpn-ns python myscript.py

Ik ben begonnen met experimenteren om een van de eerste suggesties uit te proberen en alles over te zetten naar een docker container. Nu ben ik aangekomen bij het VPN gedeelte en verwacht/hoop dat het vpn routing binnen de docker container "vanzelf" wordt afgehandeld. Hoewel deze methode mogelijk werkt zie ik dat de docker images relatief groot zijn voor het script dat ik probeer te draaien. Het doel om het gemakkelijk op andere plekken te draaien is dan wel weer gunstig. Hoop hier later meer over terug te kunnen koppelen.

oohh schreef op zaterdag 30 november 2024 @ 21:56:
Geen idee welke distro je gebruikt maar met systemd kun je proxy variabelen doorgeven. Als je een lokale proxy opzet kun je de python env laten praten met extern verkeer zonder dat je pc onbereikbaar wordt

Dit is een random linkje, maar je kunt deze variabelen ook in een systemd service zetten:

https://www.golinuxcloud....oxy-environment-variable/

Ik gebruik debian. Dank voor de link want een proxy opzetten zou ook nog zeker tot de mogelijkheden kunnen behoren. Als ik je goed begrijp een systeem met VPN en proxy mogelijkheden en via de "hoofd" server daarmee verbinden tijdens requests?

[oohh]

Erpenator2 schreef op zondag 1 december 2024 @ 09:10:
[...]

Ik gebruik debian. Dank voor de link want een proxy opzetten zou ook nog zeker tot de mogelijkheden kunnen behoren. Als ik je goed begrijp een systeem met VPN en proxy mogelijkheden en via de "hoofd" server daarmee verbinden tijdens requests?

Ja, dat klopt.

Je zou ook zoiets als docker icm met gluetun kunnen gebruiken: https://github.com/qdm12/gluetun. Je hebt hiermee ook de mogelijkheid om direct een proxy op te zetten. Kan op verschillende manieren.

[Erpenator2]

Ik wil jullie heel erg bedanken! Mede met jullie hulp is het uiteindelijk gelukt om het voor elkaar te krijgen. Het was nog wel een hele puzzel. Voor anderen die hetzelfde probleem proberen op te lossen:

Ik heb de scripts entrypoint.sh en expressvpnActivate.sh gebruikt in aangepaste vorm in een Dockerfile van deze repo: https://github.com/lucloner/expressvpn-docker

Daarmee lukt het om expressvpn te installeren en ook werkend te krijgen met de commando's die in deze scripts staan.

Daarmee lukt het de VPN nog niet om met de VPN server te connecten vanuit de docker container. Daarvoor moet de docker container met het volgende commando worden gestart:
docker run --privileged --cap-add=NET_ADMIN --device /dev/net/tun --sysctl net.ipv4.conf.all.rp_filter=0 naam_van_docker

Ik maakte ook eerste gebruik van FROM python:3.9-slim, maar moest voor de VPN overstappen naar: FROM debian:bullseye-slim

Hoewel ik het echt bizar vind dat ik nu een docker-image heb van bijna 3.6GB om een script van in totaal 27 MB te runnen negeer ik dan maar even. Misschien dat het optimaliseren van de image later nog een taak gaat worden.

Gluetun heb ik geprobeerd, maar wilde om een of andere reden niet echt werken. Helaas ook geen idee waarom niet.

Het proxy idee staat mij eigenlijk nog het meeste aan, dus mogelijk ga ik die weg ook nog verkennen.

[oohh]

Erpenator2 schreef op dinsdag 3 december 2024 @ 15:45:
Ik wil jullie heel erg bedanken! Mede met jullie hulp is het uiteindelijk gelukt om het voor elkaar te krijgen. Het was nog wel een hele puzzel. Voor anderen die hetzelfde probleem proberen op te lossen:

Ik heb de scripts entrypoint.sh en expressvpnActivate.sh gebruikt in aangepaste vorm in een Dockerfile van deze repo: https://github.com/lucloner/expressvpn-docker

Daarmee lukt het om expressvpn te installeren en ook werkend te krijgen met de commando's die in deze scripts staan.

Daarmee lukt het de VPN nog niet om met de VPN server te connecten vanuit de docker container. Daarvoor moet de docker container met het volgende commando worden gestart:
docker run --privileged --cap-add=NET_ADMIN --device /dev/net/tun --sysctl net.ipv4.conf.all.rp_filter=0 naam_van_docker

Ik maakte ook eerste gebruik van FROM python:3.9-slim, maar moest voor de VPN overstappen naar: FROM debian:bullseye-slim

Hoewel ik het echt bizar vind dat ik nu een docker-image heb van bijna 3.6GB om een script van in totaal 27 MB te runnen negeer ik dan maar even. Misschien dat het optimaliseren van de image later nog een taak gaat worden.

Gluetun heb ik geprobeerd, maar wilde om een of andere reden niet echt werken. Helaas ook geen idee waarom niet.

Het proxy idee staat mij eigenlijk nog het meeste aan, dus mogelijk ga ik die weg ook nog verkennen.

Je kunt ook een alpine Linux base image gebruiken. Dan moet de container vele malen kleiner zijn. Hooguit een paar honderd MB.

[fopjurist]

oohh schreef op dinsdag 3 december 2024 @ 16:01:
[...]

Je kunt ook een alpine Linux base image gebruiken. Dan moet de container vele malen kleiner zijn. Hooguit een paar honderd MB.

Je blijft met een extra Pythoninstallatie zitten, en met dat je de container regelmatig moet updaten. Het scriptje dat ik eerder deelde heeft die nadelen niet. Het is mij niet duidelijk waarom TS die niet heeft geprobeerd, maar wel heeft zitten rommelen met een script dat door een AI is gegenereerd.

[Erpenator2]

Ik ben wat mij betreft nog niet klaar 😉, maar heb e.e.a nu in ieder geval werkend. Hopelijk kan ik e.e.a verder toelichten.

Ik ben voor docker gegaan omdat er binnen het project meerdere "problemen" opgelost moeten worden die hoogstwaarschijnlijk alleen via de docker route op te lossen zijn. Als een alpine based image kan werken is dat zeker interessant. Dank voor de tip.

Ik heb nog niet eerder met docker gewerkt, waardoor het een mooie gelegenheid was om me er verder in te verdiepen zonder het huidige netwerk om zeep te helpen. Neemt niet weg dat ik de andere opties niet meer ga proberen.

Ook zou het mooi zijn als ik vanuit het python script kan wisselen van locatie wat nu i.i.g gemakkelijk kan.

De proxy optie spreekt mij ook enorm aan. Dit ga ik dus ook nog verder verkennen. Net als jouw script.

Kun je aangeven waar je op doelde met "ai gegenereerd script"? Op een aantal vlakken ben ik aan het bijleren en vind AI dan zeker een gemakkelijke tool. Dat lijkt me niet verkeerd?

[akimosan]

AI genereert iets, geeft een voorbeeld en dan hoop je dat het werkt.
Bestaande scripts zijn "proof of concept" of "proof of work" en hopelijk ook goed gedocumenteerd.
Beiden hebben hun nut

[Erpenator2]

Mee eens. Wanneer je (nog) geen kennis van bepaalde zaken hebt moet je ergens beginnen.