Client OpenVPN et trafic entrant

Support Debian
#1

Bonjour,

J’ai une machine virtuelle (proxmox) sous debian sur laquelle tourne un serveur de streaming audio subsonic.

Il y a quelques jours, sur cette même machine j’ai configuré un client VPN et forcé, via iptables, le traffic sortant d’un user à passer par le VPN et uniquement par le VPN:

root@multimedia:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             owner GID match hts
REJECT     all  --  anywhere             anywhere             owner GID match hts reject-with icmp-port-unreachable

Depuis, je n’ai plus accès à mon serveur de streaming depuis l’exterieur de mon reseau local.
Si je stoppe le client VPN j’ai de nouveau accès.

Est-ce que quelqu’un aurait une idée du problème ?

Merci d’avance.

#2

Il manque tellement d’informations.

Pourrais tu donner plutôt le résultats d’iptables-save ?
Le iptables -L n’est pas forcément complet, il ne donne que la table filter.

Quelle machine ? Le serveur de streaming ou le proxmox ?
Quel vpn ? Quel port ?
Le réseau, les VMs sont bridgées ? routées ?

#3

Bonsoir @mattotop :slightly_smiling_face:

root@multimedia:~# iptables-save 
# Generated by iptables-save v1.6.0 on Fri Nov 22 21:40:21 2019
*filter
:INPUT ACCEPT [9276551:12836337199]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [3306821:266146490]
-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 Fri Nov 22 21:40:21 2019

C’est bien sur la meme VM (celle où tourne le serveur de streaming) que le client VPN est installé.

Les interfaces réseau des VMs sont bridgés.

J’ai un routeur sous OpenWRT, en DMZ, derrière ma box. Le ports vers le serveur de stream sont ouverts sur le routeur.

La config du VPN:>

root@multimedia:~# cat /etc/openvpn/client.conf 
client
dev tun
proto udp
remote ***.***.***.*** 1194
resolv-retry infinite
remote-random
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
ping 15
ping-restart 0
ping-timer-rem
reneg-sec 0
comp-lzo no

remote-cert-tls server

auth-user-pass ****.txt
verb 3
pull
fast-io
cipher AES-256-CBC
auth SHA512

<ca>
-----BEGIN CERTIFICATE-----
****
-----END CERTIFICATE-----
</ca>
key-direction 1
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
****
-----END OpenVPN Static key V1-----
</tls-auth>

Voilà, voilà :slight_smile:

#4

Non, tes règles iptables ne forcent rien du tout. Elles interdisent de passer par une autre interface que celle du VPN ou de loopback.

Ça ressemble à un problème classique de routage asymétrique. Quand les paquets entrants entrent par l’interface LAN et les paquets de réponse sortants sont routés par l’interface VPN à cause de la route par défaut injectée par le VPN, mais l’adresse source ne correspond pas à l’adresse de l’interface VPN et ces paquets se font jeter par la passerelle VPN. Il faut que ces paquets de réponse soient routés vers la passerelle normale du LAN.

#5

En effet les règles ne forcent rien mais empechent bien de passer par une autre interface, donc c’est un peu comme si elles forcaient à emprunter tun0 :wink:

Comment puis-je faire pour que les paquets de réponse passe par la passerelle normale ?

#6

iptables -I OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
peut être ?
(j’ai mis -I pour la mettre en premier, mais si tu les ajoutes bon ordre, un -A suffit)

#7

Non. C’est un problème de routage. iptables fait du filtrage, pas du routage. Il peut seulement faire du marquage pour guider le routage avancé.

#8

De ce que j’ai compris de ce qu’a dit Pascal, c’est que les paquets sortant ne passant pas par le «chemin» entrant, il se font jeter par la passerelle. J’imagine que le serveur de streaming tour sur l’id 116. Pour forcer le trafic de cet utilisateur sur le VPN, il faudrait plutôt interdire les connexions sur le serveur de streaming venant du LAN, ça me parait plus logique et éviterait le pbm

#9

Non, ça ne change rien.

Non ce n’est pas le serveur de streaming qui a l’id 116.
Et j’ai aussi besoin d’accéder au serveur de streaming en local :wink:

#10

J’en doute puisqu’il reste accessible depuis le LAN qui est interdit à cet utilisateur. Si je devais faire une supposition, je dirais que cet UID sert à faire tourner un client P2P pour des activités à la légalité discutable, comme souvent.

#11

Ça y est j’ai compris, le serveur de streaming doit être accessible de partout, et le P2P uniquement du VPN. Bon, ça ne change pas gd chose au souci, entrer sur LAN et sortir sur VPN ne peut marcher…

#12

Cet UID sert à faire tourner mon tvheadend.

#13

Ah. Wikipedia me dit que TVHeadend est un serveur de streaming, mais ce n’est pas ton serveur de streaming ? Pas facile à comprendre. Ni pourquoi il a besoin d’un VPN.

Quoi qu’il en soit, tu dois mettre en place du routage avancé. Il faut commencer par trouver des critères pour différencier le trafic qui doit être routé via le VPN et le trafic qui doit être routé via la passerelle du LAN. Adresse IP et/ou port source et/ou destination, protocole de transport, relation avec un paquet entrant identifié… tout est bon.

#14

Si wikipedia le dit alors :wink:

TvHeadend est un serveur de streaming de flux TV.
Pour regarder des chaines d’un autre pays il faut parfois passer par un VPN situé dans le pays en question.

Le serveur de streaming auquel je souhaite avoir accès c’est subsonic (je te laisse regarder sur wikipedia :wink: ), il s’agit d’un serveur de streaming audio qui me permet de pouvoir écouter n’importe où ma musique stockée sur mon NAS.

#15

Si j’ai bien compris, le service de streaming doit pouvoir se connecter aux flux qu’il relaie (=ouvrir des sessions) par le vpn, mais tout le reste de son activité en tant que serveur, ou il n’est que serveur et n’initie rien, et tout le trafic de tes users qui se connectent à ses services n’ont rien à voir avec le vpn.
Je n’ai plus en tête comment on fait ça, il me faut du café.

#16

Comme je l’ai écrit, il faut faire du routage avancé pour appliquer des tables de routage différentes selon les paquets (ip route, ip rule, éventuellement iptables -j MARK ou CONNMARK), le plus dur étant de définir à quels paquets il faut appliquer quelle table de routage.

On peut commencer par choisir entre deux approches différentes :

  • soit la route par défaut devient celle du VPN lorsque celui-ci est monté, comme actuellement, et il faut identifier tous les paquets sortants qui qui ne doivent pas sortir par le VPN mais via la passerelle du LAN ;

  • soit la route par défaut reste celle du LAN même lorsque le VPN est monté et il faut identifier tous les paquets qui doivent sortir via la passerelle du LAN ; c’est peut-être plus facile.

#17

J’utilise 3 services sur cette machine:

  • TvHeadend (UID 116): doit passer par le VPN et rester accessible en local
  • Subsonic: doit être accessible en local et via l’exterieur
  • LogitechMediaServer: doit être accessible en local

En fait seuls les paquets de l’UID 116 doivent passer par le VPN.

#18

C’est quoi ce truc d’ID/UID 116 ?

#19

root@multimedia:~# iptables-save
#Generated by iptables-save v1.6.0 on Sat Nov 23 18:18:35 2019
*filter
:INPUT ACCEPT [394612644:548628809047]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [127118659:10170801833]
-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 Sat Nov 23 18:18:35 2019

#20

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…) ?