Client OpenVPN et trafic entrant

Alors pourquoi tes règles iptables filtrent-elles sur le GID et non l’UID ?

Quid des autres connexions sortantes (requêtes DNS, mises à jour du système…) ?

C’est bien filtré sur le gid en effet, au temps pour moi.

Par où doivent-elles passer ? C’est ça la question ?
Peu importe à vrai dire, au plus simple :slight_smile:

Il “suffit” (je le mets entre " " parce que c’est du chinois pour moi) donc de marquer les paquets provenant du GID 116 et de les forcer à sortir via la passerelle du VPN et de mettre la passerelle LAN en tant que passerelle par défaut ?

Alors en fait, @PascalHambourg a indiqué la démarche globale, et on a les éléments pour faire ce qu’il recommande:

Là, les paquets à router de manière exceptionnelle sont ceux de ton service de stream (qualifiés par --uid-owner 116, j’imagine), mais seulement quand ils initient une connexion, ou que c’est une continuation de connection établie (là j’ai un doute si c’est nécessaire), donc a priori un truc genre ce que j’ai dit -m state --state ESTABLISHED,RELATED
Bon, là on a à peu prés les conditions pour les ,paquets nécessitant un routage avancé, on est en position de “définir à quels paquets il faut appliquer quelle table de routage”, il ne reste plus qu’à savoir comment on fait du -j MARK ou du CONNMARK (ça se met en “mangle” ?) et comment on exploite ce marquage ensuite dans le routage avec ip route, ip rule comme le suggère pascal.
Par contre, moi, il me faudrait un peu de temps pour bien comprendre tout ça, et le mettre en place, donc je laisse la main pour ce qui est de la suite, pascal a les compétence pour faire ça en 2s.

Les paquets appartenant au gid 116 doivent être routés vers le VPN.
Les autres doivent l’être vers le LAN.

Non.
Seulement ceux qui concernent l’approvisionnement de ton id 116 en flux à relayer.
Mais pas ses clients qui viennent eux juste demander le relais des flux sur au même uid 116.
D’où ma suggestion de ne marquer pour router par ton vpn que ce qui concerne des demandes initiées par ton serveur, ou en relation avec ces dernières.
Tu vois mieux, là ?
Après, je ne vois pas comment ça se fait techniquement, ni comment on exploite le marquage pour router, mais c’est le principe.

Je me demande si je ne vais pas installer tvheadend + client VPN sur une autre machine …

Car je ne sais pas si ça peut etre lié mais je rencontre pas mal de problème en ce moment avec LogitechMediaServer qui est installé sur la meme machine: il ne voit plus mon enceinte wifi …

[edit]
Je confirme que le client VPN me fout le bordel avec LogitechMediaServer: le pugin UPNP/DLNA ne détecte pas mon enceinte wifi si le client VPN est lancé …

Ca règlera le probléme pour tout le reste, mais pas pour tvheadend:
tu devras faire le même routage entre ce que ton tvheadend va chercher comme flux par le vpn, et ce qu’il sert à ses clients par la liaison normale.

Ben non seulement pour ton upnp, mais pour tout:
quand il se léve actuellement, tous les paquets sont redirigés vers lui (route par défaut), donc tout ce qui n’arrive pas par le VPN déconne.

Je n’ai aucun problèmes en local avec tvheadend :thinking:

Ah ?
Alors ça veut dire quoi la description de ton probléme ?

D’accord, on va prendre ça comme hypothèse de départ.

Si je ne m’abuse, les paquets émis vers les clients TVHeadend du LAN n’ont pas le GID 116, sinon ils seraient bloqués par iptables. Ou alors le GID 116 (UID au lieu de GID ?) n’est pas le bon critère et la règle est inefficace. Il faudrait que @dokho clarifie définitivement ce point.

Non, la route vers le sous-réseau du LAN reste prioritaire sur la route par défaut du VPN, donc le trafic destiné au LAN reste routé correctement. Du coup, les communications sur le LAN ne devraient pas être affectées par le VPN.

Pour que la situation soit un peu plus concrète, @dokho pourrait poster les tables de routage affichées par ip route et les contenus du fichier /etc/resolv.conf avec et sans le VPN.

D’un autre côté, lorsque le VPN est monté la machine a deux interfaces réseau, cela peut impacter les applications qui font du broadcast/multicast local par exemple pour l’UPnP selon l’interface choisie pour émettre.

Je vais essayer de résumer la situation afin de clarifier.

Sur cette machine j’ai 3 services:
*subsonic: pour streamer de l’audio vers mon client android
*logitech média server: pour diffuser de l’audio vers des enceintes wifi
*tvheadend: pour diffuser de la vidéo vers mes clients kodi

Subsonic doit être accessible en local et en exterieur.

LogitechMediaServer ne fonctionne qu’en local (UPnP/dlna).

TvHeadEnd doit passer par le client VPN et doit être accessible en local. Il possède le GID 116.

Aujourd’hui ce qui ne fonctionne pas quand le client VPN est en marche:
*Accès à subsonic via l’extérieur.
*Stream de LogitechMediaServer vers mes enceintes wifi (UPnP/dlna en local)

Poste les tables de routages avec et sans le vpn ainsi que les regles iptables actuelles.

ip -4 route et ip -6 route

Ca, @fran.b la sortie d’iptables-save est plus haut dans le fil, mais c’est vrai qu’à tous hasards, ip6tables-save pourrait être utile en complément.

Cette page web en anglais réalise ce type de routage spécifique : jailing specific processes inside a vpn .

Cela n’exonère pas de lire et de bien comprendre les 3 premiers paragraphes de cette page : routing-rpdb

Et, ce qui peut manquer dans les documentations, on peut ajouter une règle de routage ou en supprimer une en spécifiant son numéro / sa priorité, comme ci-dessous :

ip -4 rule del prio 32767


AnonymousCoward

Bonjour,

**Client VPN non lancé:

root@multimedia:~# iptables-save 
Generated by iptables-save v1.6.0 on Mon Nov 25 18:02:56 2019
*filter
:INPUT ACCEPT [396690952:550191182871]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [129285795:11571315900]
-A OUTPUT -o lo -m owner --gid-owner 116 -j ACCEPT
-A OUTPUT ! -o tun0 -m owner --gid-owner 116 -j REJECT --reject-with icmp-port-unreachable
COMMIT
Completed on Mon Nov 25 18:02:56 2019

root@multimedia:~# ip6tables-save 
Generated by ip6tables-save v1.6.0 on Mon Nov 25 18:05:34 2019
*filter
:INPUT ACCEPT [7:504]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [135:7208]
COMMIT
Completed on Mon Nov 25 18:05:34 2019

root@multimedia:~# ip -4 route
default via 192.168.0.2 dev eth0 onlink 
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.246 

root@multimedia:~# ip -6 route
fe80::/64 dev eth0 proto kernel metric 256  pref medium

**Client VPN lancé:

root@multimedia:~# iptables-save 
Generated by iptables-save v1.6.0 on Mon Nov 25 18:09:16 2019
*filter
:INPUT ACCEPT [396692534:550191653803]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [129287168:11571477264]
-A OUTPUT -o lo -m owner --gid-owner 116 -j ACCEPT
-A OUTPUT ! -o tun0 -m owner --gid-owner 116 -j REJECT --reject-with icmp-port-unreachable
COMMIT
Completed on Mon Nov 25 18:09:16 2019

root@multimedia:~# ip6tables-save 
Generated by ip6tables-save v1.6.0 on Mon Nov 25 18:09:24 2019
*filter
:INPUT ACCEPT [7:504]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [138:7352]
COMMIT
Completed on Mon Nov 25 18:09:24 2019

root@multimedia:~# ip -4 route
0.0.0.0/1 via 10.8.1.1 dev tun0 
default via 192.168.0.2 dev eth0 onlink 
10.8.1.0/24 dev tun0 proto kernel scope link src 10.8.1.13 
37.120.158.19 via 192.168.0.2 dev eth0 
128.0.0.0/1 via 10.8.1.1 dev tun0 
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.246 

root@multimedia:~# ip -6 route
fe80::/64 dev eth0 proto kernel metric 256  pref medium
fe80::/64 dev tun0 proto kernel metric 256  pref medium

Ça n’a pas l’air d’inspirer grand monde :rofl:

Désolé, je croyais que @fran.b t’avait pris en charge sur ce SAV, mais il ne passe pas souvent. :smiley:
Alors pour me remettre dans le bain, je résume:

puis on a dit plein de trucs.

Mais finalement, en faisant ce résumé, je m’aperçois qu’effectivement, l’isolation du trafic de tes services n’est pas un probléme simple, mais heureusement il est traité de manière à peu prés compréhensible pour ce que j’en vois, sur le lien indiqué par @AnonymousCoward.

En résumé:

  • donner un petit nom à tes vpns pour que ce soit plus facile à désigner,
  • s’assurer que chaque service s’exécute sous un nom d’utilisateur propre,
  • brancher une table de routage particulière basée sur l’uid des processus au montage du vpn, et la déconnecter à la fermeture.

J’ai jeter un oeil: c’est en partie du chinois pour moi.

Dès que j’ai un peu de temps je fais un backup de la VM en question et je tente.

Pour l’instant j’ai fait le feignant: j’ai installé le service sur une autre VM…

Merci pour votre aide et pour les pistes :wink: