INterface tun0

Support Debian
#21

titi_rugby, tu dis que tu utilises Proxmox. Tu as bien choisi le mode bridge pour ta carte réseau ? Et pas une carte Virtuelle ?

#22

Merci pour l’astuce temporaire.

Bonjour Anatomic JC, oui j’ai bien choisi le mode BRIDGe et pas une carte virtuelle.(enfin j’ai rectifié depuis 2 jours!!! :blush: )

Titi_rugby

#23

Ca fonctionne avec ton astuce Pascal. merci.

Je rajouterai une route en dure ce soir sur mon routeur.

Titi_rugby

#24

Est ce qu’il ne serait pas possible de faire un script qui démarrerait les 2 lignes ci-dessous???

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -s 10.8.8.0/24 -j MASQUERADE

Si oui comment faire??? je n’y connais rien.

Titi_rugby

#25

J’ai quand même essayer de créer un script nommé IPTABLES que j’ai placé dans /etc/init.d/iptables. mais au redémarrage de la vm, rien n’est pris en compte.

###########################################################################
#!/bin/bash

###CONFIG###
#Activation du forward
echo 1 > /proc/sys/net/ipv4/ip_forward

#Nattage du reseau VPN avec le LAN local
iptables -t nat -A POSTROUTING -o eth0 -s 10.8.8.0/24 -j MASQUERADE
###########################################################################
Titi_rugby

#26

Met les commandes dans /etc/rc.local

#27

L’activation du forwarding IP au démarrage peut être faite dans /etc/sysctl.conf :

# activation du forwarding IP net.ipv4.ip_forward=1
D’ailleurs la ligne devrait déjà y être, il n’y a qu’à la décommenter.

Quant à la règle iptables, elle ne devrait pas être nécessaire une fois la route qui va bien ajoutée sur le routeur. Tu as testé ?

#28

Bonsoir Pascal,
Je l’ai mise en place mais ne pourrait faire un test grandeur nature que demain.
Je te tiendrai au jus.
Mais je suis vraiment très mauvais en réseau comme vous avez plus le constater d’ailleurs.

Titi_rugby

#29

Je viens de faire le test avec la route montée sur le routeur. et ça ne fonctionne pas… :119

titi_rugby

#30

La bonne route est bien mise en place ? (Tu as dit qu tu étais mauvais en réseau alors je me méfie)
Si oui, il va falloir dégainer tcpdump sur le serveur openvpn pour voir ce qui se passe d’un peu plus près. Peut-être que le routeur n’aime pas le routage asymétrique.

Sinon, il reste la possibilité d’ajouter la route sur toutes les machines du LAN qui doivent communiquer avec le VPN, si elles ne sont pas trop nombreuses.

#31

Bonjour, j’ai laissé tomber l’idée de rajouter une route sur mon routeur et je vais faire un script “IPTABLES” sur ma debian.

Vu que je vais avoir du mal à le faire, je reviens vers vous des ce soir.

Titi_rugby

#32

Où ça coince sur ton routeur?

#33

Je pense que je ne mets pas la route comme il faut. Mais dans le même temps je ne l’ai jamais fait sur un Linksys avec dd-wrt.

Titi_rugby

#34

Ah, c’est un DD-WRT. Je ne connais pas plus que ça, mais c’est basé sur Linux. Selon les règles iptables en place, ça peut coincer même si la route est correctement créée. Si tu as accès à un shell (telnet, ssh), peux-tu fournir le résultat des commandes suivantes stp ?

[code]route -n
iptables-save

si iptables-save ne marche pas

iptables -nvL[/code]

#35

Bonsoir,

ci-dessous la copie d’écran correspondant à ta demande.

Route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
########### 0.0.0.0 255.255.255.0 U 0 0 0 vlan1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 ############## 0.0.0.0 UG 0 0 0 vlan1

iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
102 10919 ACCEPT all – * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 DROP udp – vlan1 * 0.0.0.0/0 0.0.0.0/0 udp dpt:520
0 0 DROP udp – br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:520
0 0 ACCEPT udp – * * 0.0.0.0/0 0.0.0.0/0 udp dpt:520
0 0 DROP icmp – vlan1 * 0.0.0.0/0 0.0.0.0/0
0 0 DROP 2 – * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all – lo * 0.0.0.0/0 0.0.0.0/0 state NEW
10 1004 logaccept all – br0 * 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 DROP all – * * 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT 47 – * vlan1 192.168.1.0/24 0.0.0.0/0
0 0 ACCEPT tcp – * vlan1 192.168.1.0/24 0.0.0.0/0 tcp dpt:1723
0 0 ACCEPT all – br0 br0 0.0.0.0/0 0.0.0.0/0
0 0 logdrop all – * * 0.0.0.0/0 0.0.0.0/0 state INVALID
0 0 TCPMSS tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 tcpmss match 1461:65535 TCPMSS set 1460
242 57008 lan2wan all – br0 * 0.0.0.0/0 0.0.0.0/0
559 255K ACCEPT all – * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT tcp – * * 0.0.0.0/0 192.168.1.101 tcp dpt:443
0 0 DROP tcp – * * 0.0.0.0/0 192.168.1.101 tcp spt:80
0 0 ACCEPT tcp – * * 0.0.0.0/0 192.168.1.161 tcp dpt:25
0 0 ACCEPT tcp – * * 0.0.0.0/0 192.168.1.101 tcp dpt:4443
0 0 TRIGGER all – vlan1 br0 0.0.0.0/0 0.0.0.0/0 TRIGGER type:in match:0 relate:0
18 1253 trigger_out all – br0 * 0.0.0.0/0 0.0.0.0/0
18 1253 ACCEPT all – br0 * 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 DROP all – * * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 92 packets, 15212 bytes)
pkts bytes target prot opt in out source destination

Chain advgrp_1 (0 references)
pkts bytes target prot opt in out source destination

Chain advgrp_10 (0 references)
pkts bytes target prot opt in out source destination

Chain advgrp_2 (0 references)
pkts bytes target prot opt in out source destination

Chain advgrp_3 (0 references)
pkts bytes target prot opt in out source destination

Chain advgrp_4 (0 references)
pkts bytes target prot opt in out source destination

Chain advgrp_5 (0 references)
pkts bytes target prot opt in out source destination

Chain advgrp_6 (0 references)
pkts bytes target prot opt in out source destination

Chain advgrp_7 (0 references)
pkts bytes target prot opt in out source destination

Chain advgrp_8 (0 references)
pkts bytes target prot opt in out source destination

Chain advgrp_9 (0 references)
pkts bytes target prot opt in out source destination

Chain grp_1 (0 references)
pkts bytes target prot opt in out source destination

Chain grp_10 (0 references)
pkts bytes target prot opt in out source destination

Chain grp_2 (0 references)
pkts bytes target prot opt in out source destination

Chain grp_3 (0 references)
pkts bytes target prot opt in out source destination

Chain grp_4 (0 references)
pkts bytes target prot opt in out source destination

Chain grp_5 (0 references)
pkts bytes target prot opt in out source destination

Chain grp_6 (0 references)
pkts bytes target prot opt in out source destination

Chain grp_7 (0 references)
pkts bytes target prot opt in out source destination

Chain grp_8 (0 references)
pkts bytes target prot opt in out source destination

Chain grp_9 (0 references)
pkts bytes target prot opt in out source destination

Chain lan2wan (1 references)
pkts bytes target prot opt in out source destination

Chain logaccept (1 references)
pkts bytes target prot opt in out source destination
10 1004 ACCEPT all – * * 0.0.0.0/0 0.0.0.0/0

Chain logdrop (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all – * * 0.0.0.0/0 0.0.0.0/0

Chain logreject (0 references)
pkts bytes target prot opt in out source destination
0 0 REJECT tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp reject-with tcp-reset

Chain trigger_out (1 references)
pkts bytes target prot opt in out source destination

En espérant que cela te parle car moi pas dutout!!! lol

Titi_rugby

#36

Oui ça me parle, sinon je n’aurais pas demandé.

1) Table de routage
Si je ne m’abuse, br0 est l’interface LAN (pont entre l’interface wifi intégrée et l’interface vlan0 liée au VLAN des ports LAN du switch ethernet intégré) et vlan1 est l’interface WAN/internet (liée au VLAN du port WAN/internet du switch ethernet).
Je vois

  • la route du sous-réseau LAN 192.168.1.0/255.255.255.0 sur br0,
  • la route du sous-réseau WAN et la route par défaut vers internet sur vlan1,
  • la route 127.0.0.0/255.0.0.0 sur l’interface de loopback lo (on ne la voit pas toujours car elle peut être dans une autre table de routage que la commande route n’affiche pas).
    Mais je ne vois pas la route vers 10.8.8.0/255.255.255.0 sur br0 avec comme passerelle l’adresse 192.168.1.x du serveur openvpn, que tu es censé avoir ajoutée. Sans cette route, cela ne peut pas fonctionner.

[EDIT] PS : J’avais fait une petite erreur dans l’écriture de la destination de cette route (dernier 0 manquant dans le masque) dans un précédent message, j’ai corrigé.

2) Règles iptables
Je vois bien la règle iptables suivante dans la chaîne FORWARD

qui autorise tout le trafic entrant et ressortant par l’interface LAN br0, ce qui serait le cas du trafic retour des machines du LAN (hors serveur) vers le VPN si la route manquante était présente. Cette règle est situé juste avant la règle suivante qui bloque les paquets dans l’état INVALID, donc les paquets retour ne devraient pas être bloqués même s’ils sont classés dans l’état INVALID par le suivi de connexion (ce qui peut arriver car le routeur ne voit pas passer les paquets dans le sens aller).

Reste un détail à vérifier : l’absence de règle de NAT susceptible de perturber la comunication avec le VPN en changeant l’adresse source des paquets retour. Une telle règle est nécessaire pour que les redirections de port fonctionnent depuis le LAN et pas seulement depuis internet, donc il n’est pas impossible qu’elle soit présente.

#37

C’est bien ce que je disais, je suis une bille en réseau.
Je n’ai pas du la mettre au bon endroit.
Je regarderai ça ce soir.

titi_rugby

#38

Bonjour tout le monde,

Bizarrement, je me sens vraiment concerné et je n’arrive pas à trouver de solution. :open_mouth:

Je vous explique la situation :

J’ai installé le serveur vpn sur un serveur Debian.
Tout fonctionne normalement. Le serveur n’est pas hébergé chez moi (il est au boulot)

J’ai créé un compte utilisateur.

Chez moi :
J’ai 2 pc : 1 sur windows seven (appelé PC1) et 1 pc sur ubuntu (PC2)
les 2 sont derrière une freebox.

  • Le PC1 sous seven arrive à se connecter au vpn.
    J’ai installé une virtual box sur le PC1 et installé Ubuntu. -> La connexion vpn fonctionne également.

  • Sur le PC2 (ubuntu), impossible de se connecter en passant par le manager (délai de connexion dépassé…)

Par contre, lorsque je lance openvpn cient.conf dans le terminal, j’obtiens “Initialization Sequence Completed”

et là, je m’aperçois que je pinger l’adresse 10.8.0.1 (ip du sevreur distant). Donc ca fonctionne.

Par contre, impossible de pinger sur 192.168.1.3 (ip local du serveur distant) et j’ai vraiment besoin de pouvoir accéder au réseau 192.168.0.x

Je désespère :frowning:

Ce qui est hallucinant, c’est que le PC1 se connecte sans problème (seven et ubuntu sur virtualbox)

Si vous avez une idée…

Merci d’avance.

Bonne soirée.