[ok] connexion à mon serveur openvpn impossible

cemoi · 24-07-2017 17:50:21

Bonjour,
ça fait qq jours que je tourne en rond sur ce probléme... J'ai dist-upgrade le serveur (chez online) et mon laptop de jessie et stretch pour les deux. J'avais déja le serveur vpn coté sevreur et le client openvpn coté client qui tournaient correctement. J'avais suivi le tuto du wiki pour configurer le serveur et le client.

A priori le probléme n'a rien à voir avec la migration mais je préfaire préciser.

coté serveur quand je lance l'openvpn ça se termine par un:

openvpn /etc/openvpn/server.conf

 

Mon Jul 24 18:12:54 2017 us=412338 Initialization Sequence Completed

ifconfig -a

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500

        inet 10.8.0.1  netmask 255.255.255.255  destination 10.8.0.2

        inet6 fe80::8d19:9ba2:a5:9dad  prefixlen 64  scopeid 0x20<link>

        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)

        RX packets 0  bytes 0 (0.0 B)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 3  bytes 144 (144.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

iptables -L

Chain INPUT (policy ACCEPT)

target     prot opt source               destination

f2b-sshd   tcp  --  anywhere             anywhere             multiport dports ssh

ACCEPT     udp  --  anywhere             anywhere             udp dpt:openvpn

Chain FORWARD (policy ACCEPT)

target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination

Chain f2b-sshd (1 references)

target     prot opt source               destination

REJECT     all  --  181.41.89.132        anywhere             reject-with icmp-port-unreachable

REJECT     all  --  91.197.232.107       anywhere             reject-with icmp-port-unreachable

A priori la connexion a l'aire de se faire sur le serveur j'ai un tas de ligne du type:

Mon Jul 24 18:31:46 2017 us=521681 lotus/xipclientx.xx.xx.xx:40210 UDPv4 WRITE [38] to [AF_INET]xipclientx.xx.xx.xx:40210: P_DATA_V1 kid=0 DATA len=37

 

Voila pour le coté serveur

Coté client:

openvpn /etc/openvpn/client.conf

...

Mon Jul 24 18:31:19 2017 ROUTE_GATEWAY 192.168.0.1/255.255.255.0 IFACE=wlan0 HWADDR=xx:xx:xx:xx:xx:xx

Mon Jul 24 18:31:19 2017 TUN/TAP device tun0 opened

Mon Jul 24 18:31:19 2017 TUN/TAP TX queue length set to 100

Mon Jul 24 18:31:19 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0

Mon Jul 24 18:31:19 2017 /sbin/ip link set dev tun0 up mtu 1500

Mon Jul 24 18:31:19 2017 /sbin/ip addr add dev tun0 local 10.8.0.6 peer 10.8.0.5

Mon Jul 24 18:31:19 2017 /sbin/ip route add xipserveurx.xx.xx.xx/32 via 192.168.0.1

Mon Jul 24 18:31:19 2017 /sbin/ip route add 0.0.0.0/1 via 10.8.0.5

Mon Jul 24 18:31:19 2017 /sbin/ip route add 128.0.0.0/1 via 10.8.0.5

Mon Jul 24 18:31:19 2017 /sbin/ip route add 10.8.0.1/32 via 10.8.0.5

Mon Jul 24 18:31:19 2017 Initialization Sequence Completed

iptables -n

Table de routage IP du noyau

Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface

0.0.0         10.8.0.5        128.0.0.0       UG    0      0        0 tun0

0.0.0         192.168.0.1     0.0.0.0         UG    600    0        0 wlan0

8.0.1        10.8.0.5        255.255.255.255 UGH   0      0        0 tun0

8.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun0

0.0.0       10.8.0.5        128.0.0.0       UG    0      0        0 tun0

xipserveurx.xx.xx.xx 192.168.0.1     255.255.255.255 UGH   0      0        0 wlan0

254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0

168.0.0     0.0.0.0         255.255.255.0   U     600    0        0 wlan0

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

La route coté client me parait mauvaise mais je me demande pourquoi elle aurait changé...

Si je ping l'ip du serveur ça passe!

ping ipserveur

ipserveur ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4005ms

je peux également me connecter à mes serveurs (distant ou local) via ssh.
Avec firefox je ne peux pas charger de pages web... si je stop le client openvpn ça passe (logique quoi)

Voila je saisi pas la route du coup je tourne en rond....

Merci pour votre aide!

Dernière modification par cemoi (27-07-2017 17:50:27)

raleur · 25-07-2017 12:13:36

Tu n'as pas d'autres outils de test qu'un navigateur ? Ce n'est pas l'idéal pour le débogage.
Qu'est-ce qui te déplaît dans la table de routage ? Elle me semble normale si tu as choisi de faire passer la route par défaut par le VPN.
Si tu comptes avoir une connectivité internet avec le VPN, le serveur doit être configuré en routeur avec NAT. Est-ce le cas ?
Et les DNS, comment sont-ils configurés ?

cemoi · 25-07-2017 12:35:01

Bonjour,
coté client et sevreur je peux installer ce que je veux pour tester/deboguer mais je n'ai jamais eu besoin de faire ça jusque là.
Coté client les connexion ssh et le ping fonctionnent.

Mon problème c'est que je ne comprend pas tout et notamment la table de routage

Quand tu dis; "le serveur doit être configuré en routeur avec NAT. Est-ce le cas ?" Il forward via la régle iptables, j'ai suivi à al lettre le tuto du wiki de df https://debian-facile.org/doc:reseau:vpn:openvpn
Je précise que le serveur sert également de serveur web.

Pour les DNS coté client j'ai ceux de opennic et coté serveur ceux fournit par online.net

Je pense que je vais serieusement me mettre à niveau par ce que à chaque fois que j'ai des problémes reseau (route à configurer, régles de firewal, configuration d'interface reseau...) je suis sérieusement à la rue...

raleur · 25-07-2017 12:48:18

cemoi a écrit :

Coté client les connexion ssh et le ping fonctionnent.

Les connexions vers quoi/quelle adresse ?

cemoi a écrit :

Mon problème c'est que je ne comprend pas tout et notamment la table de routage

Il faut dire que les routes créées par openvpn sont un peu spéciales.

cemoi a écrit :

Il forward via la régle iptables

Quelle règle iptables ? C'est le NAT qui se fait avec iptables, pas le forwarding IP.

cemoi a écrit :

Je précise que le serveur sert également de serveur web

Aucune importance.

cemoi a écrit :

Pour les DNS coté client j'ai ceux de opennic

Donc ils devraient rester joignables depuis l'adresse IP publique du serveur.

cemoi a écrit :

coté serveur ceux fournit par online.net

Aucune importance.

cemoi · 25-07-2017 15:09:31

Les connexions du client vers le serveur avec le client openvpn en fonction:

ping ipserveur
ssh user@ipserveur
La ça fonctionne.

j'ai utilisé les régles mises dans le wiki pour la mise en place d'openvpn (serveur et client)

Je parle pour le coté serveur:
Pour l'activation de l'ip forwarding:

echo > "net.ipv4.ip_forward=1" /etc/sysctl.d/78-sysctl.conf

Pour activer le nouveau jeux de régle

sysctl -p /etc/sysctl.d/78-sysctl.conf

Pour les régles via iptables:

iptables -t filter -P FORWARD ACCEPT

iptables -t filter -A INPUT -p udp --dport 1194 -j ACCEPT

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Dans le /etc/openvpn/server.conf toujours coté serveur j'ai préciser les serveurs DNS:

push "redirect-gateway def1 bypass-dhcp"

push "dhcp-option DNS 185.121.177.177"

push "dhcp-option DNS 169.239.202.202"

Du coup j'ai dit une conne*** coté serveur ce sont les dns de opennic qui sont utilisé....

raleur · 25-07-2017 15:40:23

cemoi a écrit :

ping ipserveurssh user@ipserveurLa ça fonctionne

Quelle adresse IP ? L'adresse publique utilisée pour établir le VPN ou l'adresse IP privée 10.8.0.1 dans le VPN ?
Les communications avec l'adresse IP publique ne passent pas dans le VPN donc le test avec cette adresse n'est pas probant.

cemoi · 25-07-2017 18:08:33

à pardon je n'avais pas bien compris la question...

 ping 10.8.0.1 

 PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.

64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=35.9 ms

64 bytes from 10.8.0.1: icmp_seq=2 ttl=64 time=34.1 ms

64 bytes from 10.8.0.1: icmp_seq=3 ttl=64 time=34.5 ms

64 bytes from 10.8.0.1: icmp_seq=4 ttl=64 time=34.7 ms

64 bytes from 10.8.0.1: icmp_seq=5 ttl=64 time=37.3 ms

^C

--- 10.8.0.1 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4006ms

rtt min/avg/max/mdev = 34.156/35.356/37.319/1.160 ms

avec ssh ça fonctionne aussi avec l'ip publique ou l'ip 10.8.0.1

avec wget debian-facile.org il n'arrive pas à resoudre l'hote
avec curl c'est pareil:

curl debian-facile.org

curl: (6) Could not resolve host: debian-facile.org

 

par contre si je fais un wget sur l'ip du vpn alors là ça passe:

wget 10.8.0.1

--2017-07-25 19:00:15--  http://10.8.0.1/

Connexion à 10.8.0.1:80… connecté.

requête HTTP transmise, en attente de la réponse… 500 Internal Server Error

2017-07-25 19:00:15 erreur 500 : Internal Server Error.

forcémenet avec curl aussi:

curl 10.8.0.1

 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<html><head>

<title>500 Internal Server Error</title>

</head><body>

<h1>Internal Server Error</h1>

<p>The server encountered an internal error or

misconfiguration and was unable to complete

your request.</p>

<p>Please contact the server administrator at 

 webmaster@localhost to inform them of the time this error occurred,

 and the actions you performed just before this error.</p>

<p>More information about this error may be available

in the server error log.</p>

<hr>

<address>Apache/2.4.25 (Debian) Server at 10.8.0.1 Port 80</address>

</body></html>

ça veut dire que le probléme vient du fait que ça se connect bien sur le serveur vpn mais les requettes http ne sortent pas... Je comprends bien?

traceroute 10.8.0.0

traceroute to 10.8.0.1 (10.8.0.1), 30 hops max, 60 byte packets

 1  10.8.0.1 (10.8.0.1)  34.423 ms  41.984 ms  42.039 ms

par contre le traceroute ip publique du serveur ne donne pas du tout la même chose... je met pas le résultat ici car je ne veux pas laisser les ip trainer...

Dernière modification par cemoi (25-07-2017 18:18:44)

raleur · 25-07-2017 20:10:44

cemoi a écrit :

ça se connect bien sur le serveur vpn

Oui, visiblement.

cemoi a écrit :

mais les requettes http ne sortent pas

En fait ce sont les requêtes DNS qui n'aboutissent pas. Du coup il n'y a même pas de requête HTTP.
On va tout vérifier.
Sur le client avec VPN activé :

cat /etc/resolv.conf

ip route

iptables-save

traceroute -n 8.8.8.8

Sur le serveur :

sysctl net.ipv4.ip_forward

ip route

iptables-save

cemoi a écrit :

par contre le traceroute ip publique du serveur ne donne pas du tout la même chose

Normal, le traceroute vers l'adresse IP privée passe dans le VPN alors que celui vers l'adresse IP publique passe hors du VPN. Le VPN cache tout le chemin entre le client et le serveur.

Dernière modification par raleur (25-07-2017 20:13:29)

cemoi · 25-07-2017 21:38:01

Sur le client avec VPN activé :

cat /etc/resolv.conf

# Generated by NetworkManager

nameserver 169.239.202.202

nameserver 185.121.177.177

ip route

0.0.0/1 via 10.8.0.5 dev tun0 

default via 192.168.0.1 dev wlan0 proto static metric 600 

8.0.1 via 10.8.0.5 dev tun0 

8.0.5 dev tun0 proto kernel scope link src 10.8.0.6 

0.0.0/1 via 10.8.0.5 dev tun0 

xxx.ip.public.du_serveur via 192.168.0.1 dev wlan0 

254.0.0/16 dev wlan0 scope link metric 1000 

168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.13 metric 600

iptables-save

# Generated by iptables-save v1.6.0 on Tue Jul 25 22:12:29 2017

*filter

:INPUT ACCEPT [32833:46161193]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [22359:1653889]

COMMIT

# Completed on Tue Jul 25 22:12:29 2017

traceroute -n 8.8.8.8

traceroute -n 8.8.8.8

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets

 1  * * *

 2  * * *

 3  * * *

 4  * * *

 5  * * *

 6  * * *

 7  * * *

 8  * * *

 9  * * *

10  * * *

11  * * *

12  * * *

13  * * *

14  * * *

15  * * *

16  * * *

17  * * *

18  * * *

19  * * *

20  * * *

21  * * *

22  * * *

23  * * *

24  * * *

25  * * *

26  * * *

27  * * *

28  * * *

29  * * *

30  * * *

Sur le serveur (avec serveur vpn activé):

sysctl net.ipv4.ip_forward

net.ipv4.ip_forward = 0

 

ip route

default via 163.172.***.1 dev eth0 

8.0.0/24 via 10.8.0.2 dev tun0 

8.0.2 dev tun0 proto kernel scope link src 10.8.0.1 

172.***.0/24 dev eth0 proto kernel scope link src ip.publique.du.serveur

iptables-save

# Generated by iptables-save v1.6.0 on Tue Jul 25 22:27:45 2017

*nat

:PREROUTING ACCEPT [64099:4366207]

:INPUT ACCEPT [33174:2378797]

:OUTPUT ACCEPT [9526:584242]

:POSTROUTING ACCEPT [8176:490529]

-A POSTROUTING -o eth0 -j MASQUERADE

-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

COMMIT

# Completed on Tue Jul 25 22:27:45 2017

# Generated by iptables-save v1.6.0 on Tue Jul 25 22:27:45 2017

*filter

:INPUT ACCEPT [1373:89303]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [583:77812]

:f2b-sshd - [0:0]

-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd

-A INPUT -p udp -m udp --dport 1194 -j ACCEPT

-A f2b-sshd -s 181.41.89.132/32 -j REJECT --reject-with icmp-port-unreachable

-A f2b-sshd -s 132.248.32.213/32 -j REJECT --reject-with icmp-port-unreachable

-A f2b-sshd -s 61.177.172.40/32 -j REJECT --reject-with icmp-port-unreachable

-A f2b-sshd -j RETURN

COMMIT

# Completed on Tue Jul 25 22:27:45 2017

raleur · 25-07-2017 22:00:50

Bon, je pense que tu as vu où se situe le problème :

net.ipv4.ip_forward = 0

La valeur devrait être à 1 pour que le routage IP soit activé. Pas étonnant que rien ne passe à travers le serveur.

En relisant attentivement dans ton message précédent la commande censée créer le fichier /etc/sysctl.d/78-sysctl.conf qui met ce paramètre à 1 :

echo > "net.ipv4.ip_forward=1" /etc/sysctl.d/78-sysctl.conf

Je m'aperçois qu'elle est incorrecte : le ">" est mal placé, et au lieu d'écrire "net.ipv4.ip_forward=1" dans le fichier /etc/sysctl.d/78-sysctl.conf, ça fait l'inverse : écrire "/etc/sysctl.d/78-sysctl.conf" dans le fichier net.ipv4.ip_forward=1.
Est-ce vraiment cette commande que tu as exécutée ? Dans ce cas la suivante qui charge le fichier créé aurait dû terminer en erreur, le fichier n'existant pas.
Peux-tu vérifier la présence et le contenu du fichier /etc/sysctl.d/78-sysctl.conf ?

cemoi · 26-07-2017 08:22:01

Ha ouiiii...

la commande
[code=echo > "net.ipv4.ip_forward=1" /etc/sysctl.d/78-sysctl.conf[/code]
ne retourne aucune erreur...

Le fichier 78-sysctl.conf n'existe pas chez moi. Son nom est 99-sysctl.conf

[code=root]ls -l /etc/sysctl.d/[/code]
[code]total 8
lrwxrwxrwx 1 root root 14 Jul 5 22:31 99-sysctl.conf -> ../sysctl.conf
-rw-r--r-- 1 root root 29 Jul 22 14:24 net.ipv4.ip_forward=1
-rw-r--r-- 1 root root 639 Mar 6 2015 README.sysctl
[/code]

Dans le fichier 99-sysctl.conf il y a bien une ligne pour l'activation du forwarding:

[code]...
# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward=1
...[/code]

Du coup pas de forwarding...

J'ai decommenté cette ligne puis j'ai je l'i fait prendre en compte:

[code=root]sysctl -p /etc/sysctl.d/99-sysctl.conf[/code]
[code]net.ipv4.ip_forward = 1
[/code]

et là d'un coup ça fonctionne impeccable...

du coup il y a un probléme dans le wiki je vais allé corriger ça en proposant d'éditer le fichier directement.

Merci à toi pour ton aide precieuse!

Il me faut plus comprendre tout ce qui est couche reseau car basiquement je comprend trés/trop peu cet aspect... es que tu aurais une doc ou un livre de référence pour ça?

Dernière modification par cemoi (26-07-2017 08:26:00)

raleur · 26-07-2017 09:58:51

cemoi a écrit :

la commande
echo > "net.ipv4.ip_forward=1" /etc/sysctl.d/78-sysctl.conf
ne retourne aucune erreur

Celle-là, non. Elle ne fait pas ce qu'il faut mais elle s'exécute sans erreur. Elle crée un fichier nommé "net.ipv4.ip_forward=1" contenant le texte "/etc/sysctl.d/78-sysctl.conf". On peut voir ce fichier dans la liste du contenu du répertoire /etc/sysctl.d/. D'ailleurs tu peux le supprimer, il ne sert à rien.

C'est la commande suivante que tu dis avoir exécutée ensuite

sysctl -p /etc/sysctl.d/78-sysctl.conf

qui aurait dû retourner une erreur puisque le fichier /etc/sysctl.d/78-sysctl.conf n'a pas été créé.

cemoi a écrit :

Dans le fichier 99-sysctl.conf il y a bien une ligne pour l'activation du forwarding
du coup il y a un probléme dans le wiki je vais allé corriger ça en proposant d'éditer le fichier directement.

En fait on peut voir que 99-sysctl.conf n'est pas un vrai fichier mais un lien symbolique qui pointe vers le fichier /etc/sysctl.conf. L'inconvénient de modifier ce fichier, c'est qu'il fait partie du paquet procps, et peut donc être remplacé par une version plus récente lors d'une mise à jour de ce paquet. Tu devras choisir entre conserver l'ancienne version avec tes modifications locales et la nouvelle version. C'est pourquoi il est plus pratique de créer un fichier /etc/sysctl.d/*.conf qui n'est pas touché par les mises à jour de paquets, comme dans le wiki. Personnellement j'aurais choisi un nom de fichier plus évocateur que 78-sysctl.conf pour indiquer qu'il a pour but d'activer le forwarding IPv4.

Tu sais comment corriger la commande du wiki pour créer le fichier avec le bon nom et le bon contenu ?

cemoi a écrit :

es que tu aurais une doc ou un livre de référence pour ça?

Non, c'est trop vaste. J'ai les informations de base dans la tête, et pour les details je sais où chercher dans les pages de manuel et la documentation des paquets.

Dernière modification par raleur (26-07-2017 10:00:31)

cemoi · 27-07-2017 17:32:45

la commande aurait du etre;

echo "net.ipv4.ip_forward=1" >>/etc/sysctl.d/78-sysctl.conf

sauf que le plus propre serait de créer un fichier nat.conf (par exemple) avec la ligne net.ipv4.ip_forward=1

du coup un simple nano /etc/sysctl.d/nat.conf et coller dedans: net.ipv4.ip_forward=1

raleur · 27-07-2017 23:14:11

cemoi a écrit :

le plus propre serait de créer un fichier nat.conf

Très mauvais nom. ip_forward n'a rien à voir avec le NAT.

cemoi · 28-07-2017 18:42:09

j'ai mis en titre: activation de l'ipforwading pour le NAT (ça a un sens ça?...

)

J'ai mis NAT.conf pour le nom du fichier

Par contre je me susi fait avoir car on active la possibilité de forwarder les ip mais c'est bien pour faire du NAT...

enicar · 28-07-2017 18:49:20

cemoi a écrit :

Par contre je me suis fait avoir car on active la possibilité de forwarder les ip mais c'est bien pour faire du NAT...

Le forwarding permet au paquet d'entrer par une interface et de sortir par une autre interface
avec ou sans NAT… Après c'est une histoire de route et de logiciel de routage…
Quand on fait du NAT vue de l'extérieur les paquets semblent provenir de la machine qui fait
du NAT… (en gros). Lorsque le forwarding n'est pas activé les paquets ne peuvent traverser la machine
(ou alors peut-être en faisant un bridge, mais c'est une autre histoire).

En résumé pour faire du NAT, il faut activer le fowarding…

Dernière modification par enicar (28-07-2017 18:50:06)

raleur · 28-07-2017 19:11:51

cemoi a écrit :

activation de l'ipforwading pour le NAT (ça a un sens ça?

Non, pas vraiment. C'est plutôt l'inverse qui aurait un sens : activer le NAT pour les flux routés. Mais ce n'est pas avec sysctl que ça se configure, c'est avec iptables.

cemoi a écrit :

on active la possibilité de forwarder les ip mais c'est bien pour faire du NAT

Non. C'est l'inverse : tu fais du NAT pour que le forwarding serve à quelque chose dans ta situation particulière (adresses du VPN non routées à l'extérieur).

enicar a écrit :

Le forwarding permet au paquet d'entrer par une interface et de sortir par une autre interface

Voire par la même interface.

enicar a écrit :

En résumé pour faire du NAT, il faut activer le fowarding…

Toujours non. Aucun rapport.

Le forwarding et le NAT sont deux choses totalement indépendantes qui peuvent être combinées pour obtenir un certain résultat.

enicar a écrit :

Lorsque le forwarding n'est pas activé les paquets ne peuvent traverser la machine

Ce qui ne les empêche pas d'être NATés.

enicar · 28-07-2017 19:16:59

raleur a écrit :

enicar a écrit :

Lorsque le forwarding n'est pas activé les paquets ne peuvent traverser la machine

Ce qui ne les empêche pas d'être NATés.

Alors explique moi comment et dans quel situation.

raleur · 28-07-2017 19:33:48

Deux exemples assez classiques :

1) Redirection de port des flux entrants.
Soit un service qui écoute sur le port X. Mais on veut pouvoir s'y connecter par le port Y. On peut le faire avec une redirection du port Y vers le port X, qui est une forme de NAT destination (DNAT ou REDIRECT).

2) Multihoming et routage avancé des flux sortants.
Un hôte a plusieurs connexions d'accès internet avec une adresse IP différente pour chacune. On fait du routage avancé pour router les flux sortants par telle ou telle connexion en fonction du protocole, du port source ou destination... Mais la décision de routage initiale a sélectionné une interface de sortie et l'adresse IP source qui va avec. Le routage avancé va modifier l'interface de sortie mais pas l'adresse IP source (c'est trop tard, la socket a déjà été ouverte et le paquet a déjà été créé). Donc il faut du NAT pour modifier l'adresse IP source (SNAT ou MASQUERADE) en sortie pour qu'elle corresponde à l'interface.

Dernière modification par raleur (28-07-2017 19:42:45)

enicar · 28-07-2017 19:38:58

Merci pour cette explication raleur

Debian-facile

#1 24-07-2017 17:50:21

[ok] connexion à mon serveur openvpn impossible

#2 25-07-2017 12:13:36

Re : [ok] connexion à mon serveur openvpn impossible

#3 25-07-2017 12:35:01

Re : [ok] connexion à mon serveur openvpn impossible

#4 25-07-2017 12:48:18

Re : [ok] connexion à mon serveur openvpn impossible

#5 25-07-2017 15:09:31

Re : [ok] connexion à mon serveur openvpn impossible

#6 25-07-2017 15:40:23

Re : [ok] connexion à mon serveur openvpn impossible

#7 25-07-2017 18:08:33

Re : [ok] connexion à mon serveur openvpn impossible

#8 25-07-2017 20:10:44

Re : [ok] connexion à mon serveur openvpn impossible

#9 25-07-2017 21:38:01

Re : [ok] connexion à mon serveur openvpn impossible

#10 25-07-2017 22:00:50

Re : [ok] connexion à mon serveur openvpn impossible

#11 26-07-2017 08:22:01

Re : [ok] connexion à mon serveur openvpn impossible

#12 26-07-2017 09:58:51

Re : [ok] connexion à mon serveur openvpn impossible

#13 27-07-2017 17:32:45

Re : [ok] connexion à mon serveur openvpn impossible

#14 27-07-2017 23:14:11

Re : [ok] connexion à mon serveur openvpn impossible

#15 28-07-2017 18:42:09

Re : [ok] connexion à mon serveur openvpn impossible

#16 28-07-2017 18:49:20

Re : [ok] connexion à mon serveur openvpn impossible

#17 28-07-2017 19:11:51

Re : [ok] connexion à mon serveur openvpn impossible

#18 28-07-2017 19:16:59

Re : [ok] connexion à mon serveur openvpn impossible

#19 28-07-2017 19:33:48

Re : [ok] connexion à mon serveur openvpn impossible

#20 28-07-2017 19:38:58

Re : [ok] connexion à mon serveur openvpn impossible

Pied de page des forums