Re: Pb routage NAT suite update/reboot

[François TOURDE]

Le 19782ième jour après Epoch,
Erwann Le Bras écrivait:

> Je ne comprends pas comment ça fonctionnait avant, j'en déduis que
> cette config n'était pas active.

C'est probablement lié à la valeur de "metric", ton ancienne freebox ne
la mettait pas en place, alors que la nouvelle oui, donc la route étant
choisie avec comme objectif la métrique la plus petite, ça a pû marcher
avant, mais plus maintenant ;)

Re: Pb routage NAT suite update/reboot

[Erwann Le Bras]

bonsoir

Merci à vous deux pour le debug ; le pb venait bien de la passerelle 
déclarée au niveau eth0.


Je ne comprends pas comment ça fonctionnait avant, j'en déduis que cette 
config n'était pas active.


amitiés

Le 26/02/2024 à 18:11, Erwann Le Bras a écrit :


bonsoir la team!

j'ai un serveur Debian (version stable) qui sert de passerelle entre 
mon réseau interne et l'extérieur. Il est en route en permanence et 
s'installe les mises à jour de sécurité, sans rebooter.


  * eth0 est l'interface interne, IP statique.
  * eth1 est l'interface externe,connectée à une Freebox qui lui donne
l'IP.
  * tun0 est l'interface VPN

Sur la Freebox, une DMZ redirige les flux entrants vers mon serveur 
pour ouvrir mon serveur sur l'extérieur (SSH, WEB, VPN...).


IPTable fait le tri en entrée et assure le routage des paquets à 
l'extérieur et Fail2ban bannit les indésirables.


Tout cela fonctionne depuis plusieurs années sans pb malgré les 
changements d'opérateur et de version Debian.



Récemment, une maintenance matérielle (upgrade RAM) m'a contraint à le 
redémarrer après qq mois sans histoire.


Au démarrage, rien ne va plus : extérieur difficilement joignable, NAT 
inopérant, DMZ HS (services non joignables depuis l'extérieur).


Inversement, le serveur n'a plus accès à internet (ping HS)

J'ai pensé à une régression du au noyau, un redémarrage  en version 
6.1.0-15 n'a rien donné.


uname -a
Linux quietty 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 
(2024-02-01) x86_64 GNU/Linux



J'ai trouvé des IP martiennes dans la syslog, je ne sais pas si c'est 
lié :


2024-02-26T16:51:24.146290+01:00 quietty kernel: [ 1180.427493] IPv4: 
martian source *192.168.1.1* from 45.155.91.29, on dev *eth1*
2024-02-26T16:51:24.146322+01:00 quietty kernel: [ 1180.427508] ll 
header: : *8e a8 a4 c7 35 98* 70 fc 8f 5e 60 da 08 00
2024-02-26T16:51:33.478276+01:00 quietty kernel: [ 1189.762277] IPv4: 
martian source *192.168.1.1* from 43.133.145.230, on dev *eth1*
2024-02-26T16:51:33.478309+01:00 quietty kernel: [ 1189.762292] ll 
header: : *8e a8 a4 c7 35 98* 70 fc 8f 5e 60 da 08 00
2024-02-26T16:51:36.742277+01:00 quietty kernel: [ 1193.025728] IPv4: 
martian source 1*92.168.1.1* from 179.105.36.19, on dev *eth1*
2024-02-26T16:51:36.742306+01:00 quietty kernel: [ 1193.025742] ll 
header: : *8e a8 a4 c7 35 98 *70 fc 8f 5e 60 da 08 00
2024-02-26T16:51:49.210275+01:00 quietty kernel: [ 1205.495322] IPv4: 
martian source *192.168.1.1* from 91.148.190.174, on dev *eth1*
2024-02-26T16:51:49.210305+01:00 quietty kernel: [ 1205.495335] ll 
header: : *8e a8 a4 c7 35 98* 70 fc 8f 5e 60 da 08 00
2024-02-26T16:51:58.990298+01:00 quietty kernel: [ 1215.272829] IPv4: 
martian source *192.168.1.1* from 176.111.174.29, on dev *eth1*
2024-02-26T16:51:58.990328+01:00 quietty kernel: [ 1215.272841] ll 
header: : *8e a8 a4 c7 35 9*8 70 fc 8f 5e 60 da 08 00


Je n'avais pas ça avant. Une recherche sur Internet ne m'a pas 
vraiment aidé.



Quelques éléments techniques :

* ip addr :*
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN 
group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc fq_codel 
state UNKNOWN group default qlen 1000

    link/ether 00:50:bf:d8:b9:1f brd ff:ff:ff:ff:ff:ff
    altname enp5s3
    inet 192.168.2.1/24 brd 192.168.2.255 scope global eth0
   valid_lft forever preferred_lft forever
3: *eth1*:  mtu 1500 qdisc fq_codel 
state UP group default qlen 1000

    link/ether *8e:a8:a4:c7:35:98* brd ff:ff:ff:ff:ff:ff




    altname enp2s0
    inet *192.168.1.1*/24 metric 1024 brd 192.168.1.255 scope global 
dynamic eth1

   valid_lft 42186sec preferred_lft 42186sec
4: tun0:  mtu 1500 qdisc 
fq_codel state UNKNOWN group default qlen 500

    link/none
    inet 192.168.3.1/24 scope global tun0
   valid_lft forever preferred_lft forever


*configuration des interfaces :*

/etc/systemd/network/eth0.network
[Match]
Name=eth0
#MACAddress=Adresse MAC de l'interface

[Link]
#MACAddress=Changer l'adresse MAC
#MTUBytes=Changer la valeur du MTU

[Network]
Address=192.168.2.1/24
Gateway=192.168.2.1
DNS=192.168.2.1 127.0.0.1
Domains=vets.in
IPv6PrivacyExtensions=false


/etc/systemd/network/eth1.network

[Match]
Name=*eth1*

[Network]
DHCP=*ipv4*

*ip route*
default via 192.168.2.1 dev eth0 proto static
default via 192.168.1.254 dev eth1 proto dhcp src 192.168.1.1 metric 1024
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1 metric 
1024

192.168.1.1 dev eth1 proto dhcp scope host src 192.168.1.1 metric 1024
192.168.1.254 dev eth1 proto dhcp scope link src 192.168.1.1 metric 1024
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.1
192.168.3.0/24 dev tun0 proto kernel scope link src 192.168.3.1

(192.168.1.254 : Freebox)


*iptables -L -v*
Chain INPUT (policy DROP 582 packets, 64731 bytes)
 pkts bytes target prot

Re: Pb routage NAT suite update/reboot

[François TOURDE]

Bonjour,

Le 19779ième jour après Epoch,
Erwann Le Bras écrivait:

[...]
>  * eth0 est l'interface interne, IP statique.
>  * eth1 est l'interface externe,connectée à une Freebox qui lui donne l'IP.
>  * tun0 est l'interface VPN
[...]

> * ip addr :*
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
> group default qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
>    valid_lft forever preferred_lft forever
> 2: eth0:  mtu 1500 qdisc fq_codel
> state UNKNOWN group default qlen 1000
>     link/ether 00:50:bf:d8:b9:1f brd ff:ff:ff:ff:ff:ff
>     altname enp5s3
>     inet 192.168.2.1/24 brd 192.168.2.255 scope global eth0
>    valid_lft forever preferred_lft forever
> 3: *eth1*:  mtu 1500 qdisc fq_codel
> state UP group default qlen 1000
>     link/ether *8e:a8:a4:c7:35:98* brd ff:ff:ff:ff:ff:ff
>     altname enp2s0
>     inet *192.168.1.1*/24 metric 1024 brd 192.168.1.255 scope global
> dynamic eth1
>    valid_lft 42186sec preferred_lft 42186sec
> 4: tun0:  mtu 1500 qdisc
> fq_codel state UNKNOWN group default qlen 500
>     link/none
>     inet 192.168.3.1/24 scope global tun0
>    valid_lft forever preferred_lft forever
>

Jusque là, rien de choquant :)

> /etc/systemd/network/eth0.network
> [Match]
> Name=eth0
> #MACAddress=Adresse MAC de l'interface
>
> [Link]
> #MACAddress=Changer l'adresse MAC
> #MTUBytes=Changer la valeur du MTU
>
> [Network]
> Address=192.168.2.1/24
> Gateway=192.168.2.1

Aïe ... Je pense que tu peux enlever 'Gateway' là, c'est probablement
pour ça que tu as des soucis. Explications plus bas.

[...]
> *ip route*
> default via 192.168.2.1 dev eth0 proto static
> default via 192.168.1.254 dev eth1 proto dhcp src 192.168.1.1 metric
> 1024

Voilà, tu as deux routes par défaut, la première (et probablement
prioritaire) ne vas pas vers ta box, donc l'accès internet n'est pas
opérationnel dans ce cas.

> 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1 metric 1024
[...]
> 192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.1
> 192.168.3.0/24 dev tun0 proto kernel scope link src 192.168.3.1

Ces 3 infos dans le routage sont suffisantes pour router l'interne vers
eth0, le VPN vers tun0 et le réseau de la box par eth1.

C'est aussi probablement pourquoi tu as des IP martiennes (du
192.168.1.x qui essaye de sortir par eth0 à cause de la directive
gateway).

Mes 2¢

-- 
A gift of a flower will soon be made to you.

Re: Pb routage NAT suite update/reboot

[NoSpam]

Bonsoir


Le 26/02/2024 à 18:11, Erwann Le Bras a écrit :
[...]


*ip route*
default via 192.168.2.1 dev eth0 proto static
default via 192.168.1.254 dev eth1 proto dhcp src 192.168.1.1 metric 1024
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1 metric 
1024

192.168.1.1 dev eth1 proto dhcp scope host src 192.168.1.1 metric 1024
192.168.1.254 dev eth1 proto dhcp scope link src 192.168.1.1 metric 1024
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.1
192.168.3.0/24 dev tun0 proto kernel scope link src 192.168.3.1

(192.168.1.254 : Freebox)


2 routes par défaut est une erreur. Supprime la première

Une fois réalisé, un ping vers la Frebox est OK ?


[...]

Les services fonctionnent bien, j'y ai accès depuis le réseau de la 
Freebox (192.168.1.0) mais pas depuis l'adresse externe (qui n'a pas 
changé).


Donc un ping depuis la Freebox vers le réseau 192.168.2.0 est 
fonctionnel ? As tu rajouté une route pour que cela fonctionne car de 
mémoire la route par défaut doit être l'interface WAN de la FB ?



J'exclus un dysfonctionnement de la Freebox, elle vient d'être changé.

De ce que tu écris, la Freebox est en mode routeur. Si elle a été 
remplacée, vérifie dans ses réglages que les règles auxquelles tu 
t'attends soient encore en place et que la topologie est bien celle que 
tu veux.

[...]

Pb routage NAT suite update/reboot

[Erwann Le Bras]

bonsoir la team!

j'ai un serveur Debian (version stable) qui sert de passerelle entre mon 
réseau interne et l'extérieur. Il est en route en permanence et 
s'installe les mises à jour de sécurité, sans rebooter.


 * eth0 est l'interface interne, IP statique.
 * eth1 est l'interface externe,connectée à une Freebox qui lui donne l'IP.
 * tun0 est l'interface VPN

Sur la Freebox, une DMZ redirige les flux entrants vers mon serveur pour 
ouvrir mon serveur sur l'extérieur (SSH, WEB, VPN...).


IPTable fait le tri en entrée et assure le routage des paquets à 
l'extérieur et Fail2ban bannit les indésirables.


Tout cela fonctionne depuis plusieurs années sans pb malgré les 
changements d'opérateur et de version Debian.



Récemment, une maintenance matérielle (upgrade RAM) m'a contraint à le 
redémarrer après qq mois sans histoire.


Au démarrage, rien ne va plus : extérieur difficilement joignable, NAT 
inopérant, DMZ HS (services non joignables depuis l'extérieur).


Inversement, le serveur n'a plus accès à internet (ping HS)

J'ai pensé à une régression du au noyau, un redémarrage  en version 
6.1.0-15 n'a rien donné.


uname -a
Linux quietty 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 
(2024-02-01) x86_64 GNU/Linux



J'ai trouvé des IP martiennes dans la syslog, je ne sais pas si c'est lié :

2024-02-26T16:51:24.146290+01:00 quietty kernel: [ 1180.427493] IPv4: 
martian source *192.168.1.1* from 45.155.91.29, on dev *eth1*
2024-02-26T16:51:24.146322+01:00 quietty kernel: [ 1180.427508] ll 
header: : *8e a8 a4 c7 35 98* 70 fc 8f 5e 60 da 08 00
2024-02-26T16:51:33.478276+01:00 quietty kernel: [ 1189.762277] IPv4: 
martian source *192.168.1.1* from 43.133.145.230, on dev *eth1*
2024-02-26T16:51:33.478309+01:00 quietty kernel: [ 1189.762292] ll 
header: : *8e a8 a4 c7 35 98* 70 fc 8f 5e 60 da 08 00
2024-02-26T16:51:36.742277+01:00 quietty kernel: [ 1193.025728] IPv4: 
martian source 1*92.168.1.1* from 179.105.36.19, on dev *eth1*
2024-02-26T16:51:36.742306+01:00 quietty kernel: [ 1193.025742] ll 
header: : *8e a8 a4 c7 35 98 *70 fc 8f 5e 60 da 08 00
2024-02-26T16:51:49.210275+01:00 quietty kernel: [ 1205.495322] IPv4: 
martian source *192.168.1.1* from 91.148.190.174, on dev *eth1*
2024-02-26T16:51:49.210305+01:00 quietty kernel: [ 1205.495335] ll 
header: : *8e a8 a4 c7 35 98* 70 fc 8f 5e 60 da 08 00
2024-02-26T16:51:58.990298+01:00 quietty kernel: [ 1215.272829] IPv4: 
martian source *192.168.1.1* from 176.111.174.29, on dev *eth1*
2024-02-26T16:51:58.990328+01:00 quietty kernel: [ 1215.272841] ll 
header: : *8e a8 a4 c7 35 9*8 70 fc 8f 5e 60 da 08 00


Je n'avais pas ça avant. Une recherche sur Internet ne m'a pas vraiment 
aidé.



Quelques éléments techniques :

* ip addr :*
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN 
group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc fq_codel state 
UNKNOWN group default qlen 1000

    link/ether 00:50:bf:d8:b9:1f brd ff:ff:ff:ff:ff:ff
    altname enp5s3
    inet 192.168.2.1/24 brd 192.168.2.255 scope global eth0
   valid_lft forever preferred_lft forever
3: *eth1*:  mtu 1500 qdisc fq_codel 
state UP group default qlen 1000

    link/ether *8e:a8:a4:c7:35:98* brd ff:ff:ff:ff:ff:ff
    altname enp2s0
    inet *192.168.1.1*/24 metric 1024 brd 192.168.1.255 scope global 
dynamic eth1

   valid_lft 42186sec preferred_lft 42186sec
4: tun0:  mtu 1500 qdisc 
fq_codel state UNKNOWN group default qlen 500

    link/none
    inet 192.168.3.1/24 scope global tun0
   valid_lft forever preferred_lft forever


*configuration des interfaces :*

/etc/systemd/network/eth0.network
[Match]
Name=eth0
#MACAddress=Adresse MAC de l'interface

[Link]
#MACAddress=Changer l'adresse MAC
#MTUBytes=Changer la valeur du MTU

[Network]
Address=192.168.2.1/24
Gateway=192.168.2.1
DNS=192.168.2.1 127.0.0.1
Domains=vets.in
IPv6PrivacyExtensions=false


/etc/systemd/network/eth1.network

[Match]
Name=*eth1*

[Network]
DHCP=*ipv4*

*ip route*
default via 192.168.2.1 dev eth0 proto static
default via 192.168.1.254 dev eth1 proto dhcp src 192.168.1.1 metric 1024
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1 metric 1024
192.168.1.1 dev eth1 proto dhcp scope host src 192.168.1.1 metric 1024
192.168.1.254 dev eth1 proto dhcp scope link src 192.168.1.1 metric 1024
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.1
192.168.3.0/24 dev tun0 proto kernel scope link src 192.168.3.1

(192.168.1.254 : Freebox)


*iptables -L -v*
Chain INPUT (policy DROP 582 packets, 64731 bytes)
 pkts bytes target prot opt in out source   
destination

30176 2346K ACCEPT all  --  lo any anywhere anywhere
 3225  522K ACCEPT all  --  eth0   any anywhere anywhere
 820K 1189M ACCEPT all  --  any    any anywhere 
anywhere

Re: Monitorer la connectivité WAN en vue du re-routage

[Olivier]

J'ai trouve [1] qui semble répondre à ma question.
Les projets Debian, Fedora, ... et d'autres semblent entretenir des
appli web qui retournent un message convenu à chaque fois qu'elles
reçoivent certaines requêtes HTTP.

1. J'ignore la tenue en charge de ces appli. Ont-elles des conditions
d'utilisation ? Connaissez-vous des sites alternatifs (chez Google,
OVH ou autre)  ?

2. Le programme qui intègre ce test de connectivité est NetworkManager.
J'avoue ne pas avoir l'habitude d'utiliser NetworkManager sur un serveur.
Néanmoins, rédiger un simple script indépendant faisant à peu près
l'équivalent me semble pas trop difficile.

3. Quelqu'un a-t-il expérimenté ?
Une perte de connectivité avec l'un de ces sites a-t-elle souvent été
synonyme de perte du lien vers Internet ?

[1] 
https://www.digi.com/resources/documentation/digidocs/90002285/reference/yocto/r_network_failover.htm?TocPath=Digi%20Embedded%20Yocto%7CSystem%20development%7CSoftware%20extensions%7C_3#Check

Le sam. 26 août 2023 à 16:53, NoSpam  a écrit :
>
>
> Le 26/08/2023 à 10:19, BERTRAND Joël a écrit :
> > [...]
> >> La sécurité en vivant caché :) A l'inverse beaucoup de routeurs répondent
> >> au ping. Si tu fais un traceroute tu le vois bien.
> >   Surtout que bloquer le ping est une très mauvaise idée (problème de
> > fragmentation, de session...). Personnellement, lorsqu'un fournisseur
> > m'impose de bloquer le ping ou renâcle, je change de crèmerie. Le ping,
> > ce n'est pas simplement un protocole permettant de savoir s'il y a un
> > machine qui répond (d'autant qu'un nmap -P0 fait ça tout aussi bien).
> > C'est un protocole important.
> Et en encore plus en ipv6
>

Re: Monitorer la connectivité WAN en vue du re-routage

[NoSpam]

Le 26/08/2023 à 10:19, BERTRAND Joël a écrit :

[...]

La sécurité en vivant caché :) A l'inverse beaucoup de routeurs répondent
au ping. Si tu fais un traceroute tu le vois bien.

Surtout que bloquer le ping est une très mauvaise idée (problème de
fragmentation, de session...). Personnellement, lorsqu'un fournisseur
m'impose de bloquer le ping ou renâcle, je change de crèmerie. Le ping,
ce n'est pas simplement un protocole permettant de savoir s'il y a un
machine qui répond (d'autant qu'un nmap -P0 fait ça tout aussi bien).
C'est un protocole important.

Et en encore plus en ipv6

Re: Monitorer la connectivité WAN en vue du re-routage

[BERTRAND Joël]

Michel Verdier a écrit :
> Le 25 août 2023 Olivier a écrit :
> 
>> 1. Connaissez-vous un document qui justifie techniquement ces
>> "questions de sécurité" ?
> 
> La sécurité en vivant caché :) A l'inverse beaucoup de routeurs répondent
> au ping. Si tu fais un traceroute tu le vois bien.

Surtout que bloquer le ping est une très mauvaise idée (problème de
fragmentation, de session...). Personnellement, lorsqu'un fournisseur
m'impose de bloquer le ping ou renâcle, je change de crèmerie. Le ping,
ce n'est pas simplement un protocole permettant de savoir s'il y a un
machine qui répond (d'autant qu'un nmap -P0 fait ça tout aussi bien).
C'est un protocole important.

Bien cordialement,

JB

Re: Monitorer la connectivité WAN en vue du re-routage

[Michel Verdier]

Le 25 août 2023 Olivier a écrit :

> 1. Connaissez-vous un document qui justifie techniquement ces
> "questions de sécurité" ?

La sécurité en vivant caché :) A l'inverse beaucoup de routeurs répondent
au ping. Si tu fais un traceroute tu le vois bien.

> Par ailleurs, il me semble avoir déjà lu qu'il "valait mieux utiliser
> le HTTP et lire les réponses retournées pour estimer l'état de la
> connectivité Internet". J'imagine que plusieurs gros acteurs
> d'Internet ont mis en place ce genre de moyens.

Oui une requête http vers www.google.com qui t'indique que c'est bon et
aussi le temps de réponse donc la qualité "réelle" du réseau. Mais par
contre ça ne t'indiquera pas les machines intermédiaires qui seraient HS.

> 2. Quelles machines et quels outils (installables sur Debian) peut-on
> librement utiliser pour estimer l'état de la connectivité Internet" ?

nagios fait ça très bien mais c'est un peu long à configurer donc ça
dépend de l'investissement que tu es prêt à mettre
sinon tu fais un traceroute et tu analyses le résultat
pour un truc comme ça j'utilise le paquet mtr-tiny
mtr -c 1 -r www.google.com

Re: Monitorer la connectivité WAN en vue du re-routage

[Olivier]

Bonjour,

J'ai plusieurs installations qui bénéficient de plusieurs liens vers Internet.
J'aimerai savoir détecter à peu près en continu (détecter et basculer
en 5 minutes) les pannes et rétablissements de ces liens.

Une première méthode très simple consiste à envoyer un ping au routeur
fourni par l'ISP: s'il ne répond pas, on considère que le lien est HS.
S'il répond à nouveau, on considère que le lien (re-)fonctionne.
Malheureusement, cette méthode laisse passer les cas (assez fréquents)
où c'est le lien en amont du routeur de l'ISP qui est HS  (ce routeur
est sur site).

J'observe que mon ISP invoque des "questions de sécurité" pour que par
défaut, son routeur ne réponde jamais au ping. En le suppliant, il a
déjà accepté de changer ce réglage mais pour combien de temps ?

1. Connaissez-vous un document qui justifie techniquement ces
"questions de sécurité" ?


Par ailleurs, il me semble avoir déjà lu qu'il "valait mieux utiliser
le HTTP et lire les réponses retournées pour estimer l'état de la
connectivité Internet". J'imagine que plusieurs gros acteurs
d'Internet ont mis en place ce genre de moyens.

2. Quelles machines et quels outils (installables sur Debian) peut-on
librement utiliser pour estimer l'état de la connectivité Internet" ?


Slts

Le ven. 25 août 2023 à 16:32, Olivier  a écrit :
>
> Désolé, le message précédent est parti sans être terminé. Le bon va
> bientôt suivre.
>
> Le ven. 25 août 2023 à 16:31, Olivier  a écrit :
> >
> > Bonjour,
> >
> > J'ai plusieurs installations qui bénéficient de plusieurs liens en
> > fibre vers Internet.
> > J'aimerai savoir détecter à peu près en continu les pannes et
> > rétablissements de ces liens.
> >
> > Une première méthode très simple consiste à envoyer un ping au routeur
> > fourni par l'ISP: s'il ne répond pas, on considère que le lien est HS.
> > S'il répond à nouveau, on considère que le lien fonctionne.
> > Malheureusement, cette méthode laisse passer (assez fréquents) ou
> > c'est le lien en amont du routeur de l'ISP qui est HS.
> >
> > J'observe que mon ISP invoque des "questions de sécurité" pour que par
> > défaut, son routeur ne réponde jamais  les réponses au ping. En le
> > suppliant, il accepte de changer ce réglage mais pour combien de temps
> > ?
> >
> > Par ailleurs, il me semble avoir déjà lu qu'il "valait mieux utiliser
> > le HTTP pour questionner des machines sur l'état de leur
> > connectivité".
> >
> >
> > 1. Connaissez-vous un document qui justifie techniquement ces
> > "questions de sécurité" ?
> >
> > 2. Plutôt que le ping, j'ai compris qu'il valait mieux utiliser le
> > HTTP pour questionner l'état des machines sur

Re: Monitorer la connectivité WAN en vue du re-routage

[Olivier]

Désolé, le message précédent est parti sans être terminé. Le bon va
bientôt suivre.

Le ven. 25 août 2023 à 16:31, Olivier  a écrit :
>
> Bonjour,
>
> J'ai plusieurs installations qui bénéficient de plusieurs liens en
> fibre vers Internet.
> J'aimerai savoir détecter à peu près en continu les pannes et
> rétablissements de ces liens.
>
> Une première méthode très simple consiste à envoyer un ping au routeur
> fourni par l'ISP: s'il ne répond pas, on considère que le lien est HS.
> S'il répond à nouveau, on considère que le lien fonctionne.
> Malheureusement, cette méthode laisse passer (assez fréquents) ou
> c'est le lien en amont du routeur de l'ISP qui est HS.
>
> J'observe que mon ISP invoque des "questions de sécurité" pour que par
> défaut, son routeur ne réponde jamais  les réponses au ping. En le
> suppliant, il accepte de changer ce réglage mais pour combien de temps
> ?
>
> Par ailleurs, il me semble avoir déjà lu qu'il "valait mieux utiliser
> le HTTP pour questionner des machines sur l'état de leur
> connectivité".
>
>
> 1. Connaissez-vous un document qui justifie techniquement ces
> "questions de sécurité" ?
>
> 2. Plutôt que le ping, j'ai compris qu'il valait mieux utiliser le
> HTTP pour questionner l'état des machines sur

Monitorer la connectivité WAN en vue du re-routage

[Olivier]

Bonjour,

J'ai plusieurs installations qui bénéficient de plusieurs liens en
fibre vers Internet.
J'aimerai savoir détecter à peu près en continu les pannes et
rétablissements de ces liens.

Une première méthode très simple consiste à envoyer un ping au routeur
fourni par l'ISP: s'il ne répond pas, on considère que le lien est HS.
S'il répond à nouveau, on considère que le lien fonctionne.
Malheureusement, cette méthode laisse passer (assez fréquents) ou
c'est le lien en amont du routeur de l'ISP qui est HS.

J'observe que mon ISP invoque des "questions de sécurité" pour que par
défaut, son routeur ne réponde jamais  les réponses au ping. En le
suppliant, il accepte de changer ce réglage mais pour combien de temps
?

Par ailleurs, il me semble avoir déjà lu qu'il "valait mieux utiliser
le HTTP pour questionner des machines sur l'état de leur
connectivité".


1. Connaissez-vous un document qui justifie techniquement ces
"questions de sécurité" ?

2. Plutôt que le ping, j'ai compris qu'il valait mieux utiliser le
HTTP pour questionner l'état des machines sur

Re: serveur Debian testing avec deux ethernet (et routage)

[NoSpam]

Bonjour

Le 23/08/2021 à 08:40, Olivier a écrit :

Il faut :
activer l'IP forwarding 
(https://linuxconfig.org/how-to-turn-on-off-ip-forwarding-in-linux 
<https://linuxconfig.org/how-to-turn-on-off-ip-forwarding-in-linux>)

configurer le NAT (avec IPTables ou équivalent)

Dans Debian & Co iptables est remplacé par nftables.


Slts

Le dim. 22 août 2021 à 22:07, Basile Starynkevitch 
mailto:bas...@starynkevitch.net>> a écrit :


Bonjour la liste

A la maison (de geek) j'ai plusieurs ordinateurs -tous sous Linux,
mais
pas forcément Debian-  et surtout de l'Ethernet (le wifi sert
occasionnellement, surtout pour les tablettes).

J'ai un serveur (de récupération, c'était un déchet d'une boite
d'avocats) sous Debian testing avec deux interfaces réseaux:

Voici la sortie de ifconfig pour les deux interfaces réseaux:

eno1: flags=4163  mtu 1500
 inet 192.168.2.2  netmask 255.255.255.0  broadcast
192.168.2.255
 inet6 2a01:e0a:3d0:7b50:9e8e:99ff:fe64:fcc2 prefixlen 64
scopeid 0x0
 inet6 fe80::9e8e:99ff:fe64:fcc2  prefixlen 64 scopeid
0x20
 ether 9c:8e:99:64:fc:c2  txqueuelen 1000  (Ethernet)
 RX packets 3892  bytes 378141 (369.2 KiB)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 192  bytes 19267 (18.8 KiB)
 TX errors 0  dropped 0 overruns 0  carrier 0 collisions 0
 device interrupt 16

eno2: flags=4163  mtu 1500
 inet 192.168.1.20  netmask 255.255.255.0  broadcast
192.168.1.255
 inet6 fe80::9e8e:99ff:fe64:fcc3  prefixlen 64 scopeid
0x20
 ether 9c:8e:99:64:fc:c3  txqueuelen 1000  (Ethernet)
 RX packets 113  bytes 13209 (12.8 KiB)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 107  bytes 10837 (10.5 KiB)
 TX errors 0  dropped 0 overruns 0  carrier 0 collisions 0
 device interrupt 17

Où 192.168.2.x contient le modem Fibre-optique Free, et
192.168.1.y est
un réseau local (avec l'imprimante dessus), et un PC interne (en
ethernet) dans le cabinet de mon épouse (psychologue)


Comment configurer le routage?

J'ai l'impression que la commande route est obsolète

Librement.

-- 
Basile Starynkevitch                  
<mailto:bas...@starynkevitch.net>>
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/ <http://starynkevitch.net/Basile/>

Re: serveur Debian testing avec deux ethernet (et routage)

[Olivier]

Il faut :
activer l'IP forwarding (
https://linuxconfig.org/how-to-turn-on-off-ip-forwarding-in-linux)
configurer le NAT (avec IPTables ou équivalent)

Slts

Le dim. 22 août 2021 à 22:07, Basile Starynkevitch 
a écrit :

> Bonjour la liste
>
> A la maison (de geek) j'ai plusieurs ordinateurs -tous sous Linux, mais
> pas forcément Debian-  et surtout de l'Ethernet (le wifi sert
> occasionnellement, surtout pour les tablettes).
>
> J'ai un serveur (de récupération, c'était un déchet d'une boite
> d'avocats) sous Debian testing avec deux interfaces réseaux:
>
> Voici la sortie de ifconfig pour les deux interfaces réseaux:
>
> eno1: flags=4163  mtu 1500
>  inet 192.168.2.2  netmask 255.255.255.0  broadcast 192.168.2.255
>  inet6 2a01:e0a:3d0:7b50:9e8e:99ff:fe64:fcc2  prefixlen 64
> scopeid 0x0
>  inet6 fe80::9e8e:99ff:fe64:fcc2  prefixlen 64  scopeid 0x20
>  ether 9c:8e:99:64:fc:c2  txqueuelen 1000  (Ethernet)
>  RX packets 3892  bytes 378141 (369.2 KiB)
>  RX errors 0  dropped 0  overruns 0  frame 0
>  TX packets 192  bytes 19267 (18.8 KiB)
>  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>  device interrupt 16
>
> eno2: flags=4163  mtu 1500
>  inet 192.168.1.20  netmask 255.255.255.0  broadcast 192.168.1.255
>  inet6 fe80::9e8e:99ff:fe64:fcc3  prefixlen 64  scopeid 0x20
>  ether 9c:8e:99:64:fc:c3  txqueuelen 1000  (Ethernet)
>  RX packets 113  bytes 13209 (12.8 KiB)
>  RX errors 0  dropped 0  overruns 0  frame 0
>  TX packets 107  bytes 10837 (10.5 KiB)
>  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>  device interrupt 17
>
> Où 192.168.2.x contient le modem Fibre-optique Free, et 192.168.1.y est
> un réseau local (avec l'imprimante dessus), et un PC interne (en
> ethernet) dans le cabinet de mon épouse (psychologue)
>
>
> Comment configurer le routage?
>
> J'ai l'impression que la commande route est obsolète
>
> Librement.
>
> --
> Basile Starynkevitch  
> (only mine opinions / les opinions sont miennes uniquement)
> 92340 Bourg-la-Reine, France
> web page: starynkevitch.net/Basile/
>
>

Re: serveur Debian testing avec deux ethernet (et routage)

[Étienne Mollier]

Bonsoir Basile,

Basile Starynkevitch, on 2021-08-22:
> Comment configurer le routage?
> 
> J'ai l'impression que la commande route est obsolète

Je pense que `route`, pour configurer le routage de la machine,
a été intégrée à la commande `ip` :

$ ip route
default via 192.168.1.254 dev enp4s0 
192.168.1.0/24 dev enp4s0 proto kernel scope link src 192.168.1.100 

La documentation est disponible dans la page de manuel de
ip-route(8) [1].

[1]: https://manpages.debian.org/bullseye/iproute2/ip-route.8.en.html

Bonne soirée,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Re: serveur Debian testing avec deux ethernet (et routage)

[Julio Herrero]

El dom, 22-08-2021 a las 22:07 +0200, Basile Starynkevitch escribió:
> Comment configurer le routage?

/etc/sysctl.conf

...
net.ipv4.ip_forward=1
...

Re: serveur Debian testing avec deux ethernet (et routage)

[Jérémy Prego]

bonjour,

Le 22/08/2021 à 22:07, Basile Starynkevitch a écrit :



Comment configurer le routage?



routage de quoi vers quoi  ? à quoi doit avoir accès l'imprimante / 
l'ordinateur sur le réseau 1.y ?



J'ai l'impression que la commande route est obsolète


utiliser plutôt ip route du paquet iproute2

Librement.


Jerem

Re: serveur Debian testing avec deux ethernet (et routage)

[Basile Starynkevitch]

On 22/08/2021 22:12, Jérémy Prego wrote:

bonjour,

Le 22/08/2021 à 22:07, Basile Starynkevitch a écrit :



Comment configurer le routage?



routage de quoi vers quoi  ? à quoi doit avoir accès l'imprimante / 
l'ordinateur sur le réseau 1.y ?



aux machines du réseau 2.x (mais pas à Internet, vu qu'il y a un autre 
modem fibre sur 1.y, en pratique utilisé par une seulemachine)







J'ai l'impression que la commande route est obsolète


utiliser plutôt ip route du paquet iproute2

Librement.


Jerem


--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

serveur Debian testing avec deux ethernet (et routage)

[Basile Starynkevitch]

Bonjour la liste

A la maison (de geek) j'ai plusieurs ordinateurs -tous sous Linux, mais 
pas forcément Debian-  et surtout de l'Ethernet (le wifi sert 
occasionnellement, surtout pour les tablettes).


J'ai un serveur (de récupération, c'était un déchet d'une boite 
d'avocats) sous Debian testing avec deux interfaces réseaux:


Voici la sortie de ifconfig pour les deux interfaces réseaux:

eno1: flags=4163  mtu 1500
    inet 192.168.2.2  netmask 255.255.255.0  broadcast 192.168.2.255
    inet6 2a01:e0a:3d0:7b50:9e8e:99ff:fe64:fcc2  prefixlen 64  
scopeid 0x0

    inet6 fe80::9e8e:99ff:fe64:fcc2  prefixlen 64  scopeid 0x20
    ether 9c:8e:99:64:fc:c2  txqueuelen 1000  (Ethernet)
    RX packets 3892  bytes 378141 (369.2 KiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 192  bytes 19267 (18.8 KiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    device interrupt 16

eno2: flags=4163  mtu 1500
    inet 192.168.1.20  netmask 255.255.255.0  broadcast 192.168.1.255
    inet6 fe80::9e8e:99ff:fe64:fcc3  prefixlen 64  scopeid 0x20
    ether 9c:8e:99:64:fc:c3  txqueuelen 1000  (Ethernet)
    RX packets 113  bytes 13209 (12.8 KiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 107  bytes 10837 (10.5 KiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    device interrupt 17

Où 192.168.2.x contient le modem Fibre-optique Free, et 192.168.1.y est 
un réseau local (avec l'imprimante dessus), et un PC interne (en 
ethernet) dans le cabinet de mon épouse (psychologue)



Comment configurer le routage?

J'ai l'impression que la commande route est obsolète

Librement.

--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: Conseils sur le routage de client à client avec OpenVPN

[Daniel Huhardeaux]

Le 24/01/2019 à 11:32, Olivier a écrit :



Le jeu. 24 janv. 2019 à 11:18, Daniel Huhardeaux > a écrit :




Rien ne t'empêche de mettre une seconde configuration VPN en parallèle
chez tes clients (et chez toi) sur un autre port !

Je suis d'accord.


Pour ma part, je réitère: un serveur VPN central sur lequel vont se
connecter les clients et toi, du réseau bureau ou déplacement.

                  serveur VPN
                  /     | ...\
              clt1    clt2    Cltx

Le lien est permanent pour les clients sauf pour toi (si tu le désire)


Je suis d'accord sauf peut-être sur la persistance des liens car ne 
l'oublions pas, j'ai des plages d'adresses identiques sur des sites 
différents et ça va rester.


Quelle techno de VPN te sembles la plus adaptée pour ça ?


tun

On garde OpenVPN (pas de logiciels supplémentaire à installer): juste 
une re-configuration au cas par cas pour la deuxième instance d'OpenVPN ?

Ça me semble une très bonne idée mais je préfère demander.


Oui




Pas de port ouvert sauf celui pour le VPN et ssh en secours. Cela veut
dire que tu pourras te connecter (ssh avec mot de passe) chez tes
clients à partir de n'importe quel matériel, pas seulement de ceux qui
te sont connus.


 >
 >
 >
 > Le mer. 23 janv. 2019 à 16:16, Pascal Hambourg
mailto:pas...@plouf.fr.eu.org>
 > >>
a écrit :
 >
 >     Le 23/01/2019 à 15:58, Olivier a écrit :
 >      >
 >      > [1]
https://serverfault.com/questions/736274/openvpn-client-to-client
 >
 >     Ce lien confirme ce que j'écrivais ci-dessous :
 >
 >      > Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg
 >     mailto:pas...@plouf.fr.eu.org>
>> a
 >      > écrit :
 >      >
 >      >> Le 23/01/2019 à 14:39, Olivier Bitsch a écrit :
 >      >>>
 >      >>> 1. Oui tu as bien compris, client-to-client ne transite
pas le
 >     paquet par
 >      >>> le serveur. Du coup pas de filtrage possible si c'est option
 >     est activée.
 >      >>
 >      >> Si j'ai bien compris, plus précisément les paquets envoyés à
 >     l'intérieur
 >      >> du tunnel entre deux clients ne transitent pas par
l'interface
 >     tun/tap
 >      >> ni la pile réseau de la machine qui fait tourner le
serveur openvpn,
 >      >> mais les paquets transportant le tunnel passent quand
même par le
 >      >> serveur openvpn.
 >

Re: Conseils sur le routage de client à client avec OpenVPN [RESOLU]

[Olivier]

Grâce aux différents conseils ici reçus, j'ai pu rapidement mettre en place
un prototype de VPN dédié à la télé-gestion de réseaux locaux distants en
complément de mon VPN dédié à la télé-gestion de machines distantes.

- Mes deux VPN utilisent OpenVPN.
- On peut faire tourner parallèlement plusieurs instances d'OpenVPN mais
chacune doit avoir son propre procole/port d'écoute.
- On peut mettre en communs des certificats et clés.
- La topologie subnet est recommandée (celle par défaut est net30)
- L'option client-to-client facilite les communications "directes"
inter-clients
- Chaque instance d'OpenVPN produit son fichier openvpn-status.lo qui
contient une photo de la table de routage interne à OpenVPN à savoir la
liste des clients OpenVPN et la liste des réseaux locaux déclarés par ces
clients
- Au démarrage, un client OpenVPN modifie la table de routage du client: je
n'ai pas eu besoin d'ajouter des règles pour le NAT.

Merci infiniment à tous pour votre aide

Re: Conseils sur le routage de client à client avec OpenVPN

[Olivier]

Le jeu. 24 janv. 2019 à 11:18, Daniel Huhardeaux  a
écrit :

>
>
> Rien ne t'empêche de mettre une seconde configuration VPN en parallèle
> chez tes clients (et chez toi) sur un autre port !
>
Je suis d'accord.


> Pour ma part, je réitère: un serveur VPN central sur lequel vont se
> connecter les clients et toi, du réseau bureau ou déplacement.
>
>  serveur VPN
>  / | ...\
>  clt1clt2Cltx
>
> Le lien est permanent pour les clients sauf pour toi (si tu le désire)
>

Je suis d'accord sauf peut-être sur la persistance des liens car ne
l'oublions pas, j'ai des plages d'adresses identiques sur des sites
différents et ça va rester.

Quelle techno de VPN te sembles la plus adaptée pour ça ?
On garde OpenVPN (pas de logiciels supplémentaire à installer): juste une
re-configuration au cas par cas pour la deuxième instance d'OpenVPN ?
Ça me semble une très bonne idée mais je préfère demander.


>
> Pas de port ouvert sauf celui pour le VPN et ssh en secours. Cela veut
> dire que tu pourras te connecter (ssh avec mot de passe) chez tes
> clients à partir de n'importe quel matériel, pas seulement de ceux qui
> te sont connus.
>
>
> >
> >
> >
> > Le mer. 23 janv. 2019 à 16:16, Pascal Hambourg  > > a écrit :
> >
> > Le 23/01/2019 à 15:58, Olivier a écrit :
> >  >
> >  > [1]
> https://serverfault.com/questions/736274/openvpn-client-to-client
> >
> > Ce lien confirme ce que j'écrivais ci-dessous :
> >
> >  > Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg
> > mailto:pas...@plouf.fr.eu.org>> a
> >  > écrit :
> >  >
> >  >> Le 23/01/2019 à 14:39, Olivier Bitsch a écrit :
> >  >>>
> >  >>> 1. Oui tu as bien compris, client-to-client ne transite pas le
> > paquet par
> >  >>> le serveur. Du coup pas de filtrage possible si c'est option
> > est activée.
> >  >>
> >  >> Si j'ai bien compris, plus précisément les paquets envoyés à
> > l'intérieur
> >  >> du tunnel entre deux clients ne transitent pas par l'interface
> > tun/tap
> >  >> ni la pile réseau de la machine qui fait tourner le serveur
> openvpn,
> >  >> mais les paquets transportant le tunnel passent quand même par le
> >  >> serveur openvpn.
> >
>
>

Re: Conseils sur le routage de client à client avec OpenVPN

[Daniel Huhardeaux]

Le 24/01/2019 à 10:54, Olivier a écrit :

Bonjour,

La nuit porte conseil et en repensant à ce qui précède, je pense que mon 
besoin premier est d'utiliser mon VPN comme un tunnel laissant passer 
des flux entre deux clients du VPN

sans les interpréter lui-même.

Le VPN est le seul lien que j'ai avec des sites distants et je ne peux 
pas risquer de perdre un lien en reconfigurant OpenVPN.
Or il me semble que les paramètres de routage d'OpenVPN ont une portée 
générale avec des précautions que j'ai du mal à respecter (adresses 
uniques, ...).


En conclusion:
1- je ne change pas ma configuration d'OpenVPN
2- s'il existe une technique pour utiliser ma configuration OpenVPN 
comme un "tunnel entre mon PC et un LAN distant" et sans le 
re-configurer, ça m'intéresse
3- s'il existe une autre technologie de VPN (IPSEC ? Wireguard ? ...) 
pour faire ce que je recherche et utilisable en parallèle à OpenVPN, ça 
m'intéresse aussi.


Pour le point 3, je n'ai pas besoin d'avoir un tunnel permanent entre 
mon PC et le LAN distant: j'ai juste besoin de pouvoir établir ce tunnel 
le temps d'une session de déboguage.
Je peux pouvoir initier ce tunnel quand je suis en déplacement et 
connecté à réseau local dont je ne pourrai pas modifier la configuration 
du routeur: je devrai donc passer par une machine tierce sur Internet 
qui aura les ports ouverts nécessaires.


Pour compléter mon cahier des charges:
- toutes les machines concernées (mon PC, machine tierce, routeur sur le 
LAN distant) sont sous Debian avec toutefois des versions variées 
(jessie, stretch, ...).


Conseils, remarques et suggestions bienvenues !


Rien ne t'empêche de mettre une seconde configuration VPN en parallèle 
chez tes clients (et chez toi) sur un autre port !


Pour ma part, je réitère: un serveur VPN central sur lequel vont se 
connecter les clients et toi, du réseau bureau ou déplacement.


serveur VPN
/ | ...\
clt1clt2Cltx

Le lien est permanent pour les clients sauf pour toi (si tu le désire)

Pas de port ouvert sauf celui pour le VPN et ssh en secours. Cela veut 
dire que tu pourras te connecter (ssh avec mot de passe) chez tes 
clients à partir de n'importe quel matériel, pas seulement de ceux qui 
te sont connus.







Le mer. 23 janv. 2019 à 16:16, Pascal Hambourg <mailto:pas...@plouf.fr.eu.org>> a écrit :


Le 23/01/2019 à 15:58, Olivier a écrit :
 >
 > [1] https://serverfault.com/questions/736274/openvpn-client-to-client

Ce lien confirme ce que j'écrivais ci-dessous :

 > Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg
mailto:pas...@plouf.fr.eu.org>> a
 > écrit :
 >
 >> Le 23/01/2019 à 14:39, Olivier Bitsch a écrit :
 >>>
 >>> 1. Oui tu as bien compris, client-to-client ne transite pas le
paquet par
 >>> le serveur. Du coup pas de filtrage possible si c'est option
est activée.
 >>
 >> Si j'ai bien compris, plus précisément les paquets envoyés à
l'intérieur
 >> du tunnel entre deux clients ne transitent pas par l'interface
tun/tap
 >> ni la pile réseau de la machine qui fait tourner le serveur openvpn,
 >> mais les paquets transportant le tunnel passent quand même par le
 >> serveur openvpn.

Re: Conseils sur le routage de client à client avec OpenVPN

[Olivier]

Bonjour,

La nuit porte conseil et en repensant à ce qui précède, je pense que mon
besoin premier est d'utiliser mon VPN comme un tunnel laissant passer des
flux entre deux clients du VPN
sans les interpréter lui-même.

Le VPN est le seul lien que j'ai avec des sites distants et je ne peux pas
risquer de perdre un lien en reconfigurant OpenVPN.
Or il me semble que les paramètres de routage d'OpenVPN ont une portée
générale avec des précautions que j'ai du mal à respecter (adresses
uniques, ...).

En conclusion:
1- je ne change pas ma configuration d'OpenVPN
2- s'il existe une technique pour utiliser ma configuration OpenVPN comme
un "tunnel entre mon PC et un LAN distant" et sans le re-configurer, ça
m'intéresse
3- s'il existe une autre technologie de VPN (IPSEC ? Wireguard ? ...) pour
faire ce que je recherche et utilisable en parallèle à OpenVPN, ça
m'intéresse aussi.

Pour le point 3, je n'ai pas besoin d'avoir un tunnel permanent entre mon
PC et le LAN distant: j'ai juste besoin de pouvoir établir ce tunnel le
temps d'une session de déboguage.
Je peux pouvoir initier ce tunnel quand je suis en déplacement et connecté
à réseau local dont je ne pourrai pas modifier la configuration du routeur:
je devrai donc passer par une machine tierce sur Internet qui aura les
ports ouverts nécessaires.

Pour compléter mon cahier des charges:
- toutes les machines concernées (mon PC, machine tierce, routeur sur le
LAN distant) sont sous Debian avec toutefois des versions variées (jessie,
stretch, ...).

Conseils, remarques et suggestions bienvenues !



Le mer. 23 janv. 2019 à 16:16, Pascal Hambourg  a
écrit :

> Le 23/01/2019 à 15:58, Olivier a écrit :
> >
> > [1] https://serverfault.com/questions/736274/openvpn-client-to-client
>
> Ce lien confirme ce que j'écrivais ci-dessous :
>
> > Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg 
> a
> > écrit :
> >
> >> Le 23/01/2019 à 14:39, Olivier Bitsch a écrit :
> >>>
> >>> 1. Oui tu as bien compris, client-to-client ne transite pas le paquet
> par
> >>> le serveur. Du coup pas de filtrage possible si c'est option est
> activée.
> >>
> >> Si j'ai bien compris, plus précisément les paquets envoyés à l'intérieur
> >> du tunnel entre deux clients ne transitent pas par l'interface tun/tap
> >> ni la pile réseau de la machine qui fait tourner le serveur openvpn,
> >> mais les paquets transportant le tunnel passent quand même par le
> >> serveur openvpn.
>
>

Re: Conseils sur le routage de client à client avec OpenVPN

[Pascal Hambourg]

Le 23/01/2019 à 15:58, Olivier a écrit :


[1] https://serverfault.com/questions/736274/openvpn-client-to-client


Ce lien confirme ce que j'écrivais ci-dessous :


Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg  a
écrit :


Le 23/01/2019 à 14:39, Olivier Bitsch a écrit :


1. Oui tu as bien compris, client-to-client ne transite pas le paquet par
le serveur. Du coup pas de filtrage possible si c'est option est activée.


Si j'ai bien compris, plus précisément les paquets envoyés à l'intérieur
du tunnel entre deux clients ne transitent pas par l'interface tun/tap
ni la pile réseau de la machine qui fait tourner le serveur openvpn,
mais les paquets transportant le tunnel passent quand même par le
serveur openvpn.

Re: Conseils sur le routage de client à client avec OpenVPN

[Olivier]

Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg  a
écrit :

>
> Il y a une bidouille possible à base de double NAT source+destination.
> Pour chaque réseau utilisant l'adressage 192.168.1.0/24 en interne, on
> définit un réseau externe unique, on configure le routage des réseaux
> externes sur le serveur openvpn et on met en place des règles NETMAP sur
> la passerelle de chaque réseau pour faire en sorte que :
> - quand un paquet est émis vers le tunnel, son adresse source est mappée
> en son adresse externe correspondant au réseau ;
> - quant un paquet est reçu par le tunnel à destination d'une adresse
> externe, son adresse est mappée en l'adresse interne correspondante.
>
> Evidemment, ça ne marche qu'avec les protocoles supportés par le NAT.
>
>
Excellent !
Je ne connaissait pas l'option -j NETMAP qui a l'air adaptée car si sur
beaucoup de sites distants, je retrouve les mêmes adresses IP, j'ai aussi
une nomenclature avec un entier unique pour chaque site.
Il devrait pas être difficile d'associer cet entier à une plage d'adresse
propre à chaque site.

Merci infiniment pour l'avoir signalée

Re: Conseils sur le routage de client à client avec OpenVPN

[Olivier]

Mea culpa: voici le lien manquant !

[1] https://serverfault.com/questions/736274/openvpn-client-to-client

Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg  a
écrit :

> Le 23/01/2019 à 14:39, Olivier Bitsch a écrit :
> >
> > 1. Oui tu as bien compris, client-to-client ne transite pas le paquet par
> > le serveur. Du coup pas de filtrage possible si c'est option est activée.
>
> Si j'ai bien compris, plus précisément les paquets envoyés à l'intérieur
> du tunnel entre deux clients ne transitent pas par l'interface tun/tap
> ni la pile réseau de la machine qui fait tourner le serveur openvpn,
> mais les paquets transportant le tunnel passent quand même par le
> serveur openvpn.
>
> > 2. Si tous les réseaux connectés sont sur le même réseau (192.168.1.0/24
> ),
> > je ne vois pas comment il sera possible de router les paquets d'un réseau
> > comme il faut. Donc je ne vois pas comment ça peut marcher.
>
> Il y a une bidouille possible à base de double NAT source+destination.
> Pour chaque réseau utilisant l'adressage 192.168.1.0/24 en interne, on
> définit un réseau externe unique, on configure le routage des réseaux
> externes sur le serveur openvpn et on met en place des règles NETMAP sur
> la passerelle de chaque réseau pour faire en sorte que :
> - quand un paquet est émis vers le tunnel, son adresse source est mappée
> en son adresse externe correspondant au réseau ;
> - quant un paquet est reçu par le tunnel à destination d'une adresse
> externe, son adresse est mappée en l'adresse interne correspondante.
>
> Evidemment, ça ne marche qu'avec les protocoles supportés par le NAT.
>
> >> J'ai découvert que je pouvais utiliser l'option client-to-client
> d'OpenVPN
> >> pour permettre la communication directe entre deux clients OpenVPN.
> >> J'ai lu en [1], que cette communication s'opérait à "l'insu de la
> >> configuration réseau du serveur OpenVPN" : les flux passaient
> directement
> >> d'un client OpenVPN à un autre sans que je puisse, avec le firewall du
> >> serveur OpenVPN définir des régles très précises comme celle de
> n'autoriser
> >> que la communication depuis ou vers un ou deux clients OpenVPN.
>
> Qu'est-ce que [1] ?
>
>

Re: Conseils sur le routage de client à client avec OpenVPN

[Pascal Hambourg]

Le 23/01/2019 à 14:39, Olivier Bitsch a écrit :


1. Oui tu as bien compris, client-to-client ne transite pas le paquet par
le serveur. Du coup pas de filtrage possible si c'est option est activée.


Si j'ai bien compris, plus précisément les paquets envoyés à l'intérieur 
du tunnel entre deux clients ne transitent pas par l'interface tun/tap 
ni la pile réseau de la machine qui fait tourner le serveur openvpn, 
mais les paquets transportant le tunnel passent quand même par le 
serveur openvpn.



2. Si tous les réseaux connectés sont sur le même réseau (192.168.1.0/24),
je ne vois pas comment il sera possible de router les paquets d'un réseau
comme il faut. Donc je ne vois pas comment ça peut marcher.


Il y a une bidouille possible à base de double NAT source+destination.
Pour chaque réseau utilisant l'adressage 192.168.1.0/24 en interne, on 
définit un réseau externe unique, on configure le routage des réseaux 
externes sur le serveur openvpn et on met en place des règles NETMAP sur 
la passerelle de chaque réseau pour faire en sorte que :
- quand un paquet est émis vers le tunnel, son adresse source est mappée 
en son adresse externe correspondant au réseau ;
- quant un paquet est reçu par le tunnel à destination d'une adresse 
externe, son adresse est mappée en l'adresse interne correspondante.


Evidemment, ça ne marche qu'avec les protocoles supportés par le NAT.


J'ai découvert que je pouvais utiliser l'option client-to-client d'OpenVPN
pour permettre la communication directe entre deux clients OpenVPN.
J'ai lu en [1], que cette communication s'opérait à "l'insu de la
configuration réseau du serveur OpenVPN" : les flux passaient directement
d'un client OpenVPN à un autre sans que je puisse, avec le firewall du
serveur OpenVPN définir des régles très précises comme celle de n'autoriser
que la communication depuis ou vers un ou deux clients OpenVPN.


Qu'est-ce que [1] ?

Re: Conseils sur le routage de client à client avec OpenVPN

[Baptiste Chappe]

Hello,

Première intervention sur la ML :)

Je remote avec un VPS OVH 600 sites distants via du OpenVPN et du Mikrotik
sur site. Des sites en chine (pas HK) via des protocoles exotiques pour ne
pas être filtrer (voir stunnel).
Les réseaux clients ne doivent pas avoir de même subnet.
C'est un peu compliqué au départ mais en étant rigoureux, je fais du 1
touch provisionning  sur mes clients OpenVPN

Un exemple de configuration de ma "tete" vpn vers un client Mikro en Europe.

port 443
proto tcp
dev tun


ca /etc/openvpn/CL001-XXX/ca.crt
cert /etc/openvpn/CL001-XXX/server.crt
key /etc/openvpn/CL001-XXX/server.key
dh /etc/openvpn/CL001-XXX/dh2048.pem

# IP DU SERVEUR
server 172.30.1.0 255.255.255.0

client-config-dir /etc/openvpn/CL001-XXX/CSO
ccd-exclusive

# LE SERVEUR APPRENDS LES ROUTES - TAPER ROUTE

route 192.168.1.0 255.255.255.0
route 192.168.68.0 255.255.255.0
route 192.168.5.0 255.255.255.0

keepalive 10 120
cipher aes256
auth sha1

log-append /var/log/openvpn.log
status /var/log/openvpn-status.log
verb 4
mute 20

Un exemple de configuration de ma "tete" vpn vers un client Mikro

### CSO ##

#ifconfig-push 172.30.1.2 172.30.1.1
push "route 172.30.2.0 255.255.255.0"
push "route 172.30.99.0 255.255.255.0"
#push "route 192.168.5.0 255.255.255.0"
iroute 192.168.1.0 255.255.255.0

Une trace depuis un autre VPS

root@ > traceroute 192.168.1.251
traceroute to 192.168.1.251 (192.168.1.251), 30 hops max, 60 byte packets
 1  VPN-OVH-MONITORING (172.30.2.1)  11.316 ms  22.360 ms  22.343 ms
 2  MF-MONITORING (192.168.1.251)  33.140 ms  44.087 ms  44.108 ms
root@ ~ >

Bon courage,

Baptiste Chappe



Le mer. 23 janv. 2019 à 14:39, Olivier Bitsch  a
écrit :

> Bonjour Olivier,
>
> 1. Oui tu as bien compris, client-to-client ne transite pas le paquet par
> le serveur. Du coup pas de filtrage possible si c'est option est activée.
>
> 2. Si tous les réseaux connectés sont sur le même réseau (192.168.1.0/24),
> je ne vois pas comment il sera possible de router les paquets d'un réseau
> comme il faut. Donc je ne vois pas comment ça peut marcher.
>
> 3. Pour les étapes B et C, et sous réserve que chaque réseau aient leur
> propre adressage, il faut utiliser la topologie subnet avec OpenVPN. Je
> peux te donner des exemples si tu en as besoin.
>
> obitwo
>
> Le mar. 22 janv. 2019 à 16:48, Olivier  a écrit :
>
>> Bonjour,
>>
>> J'ai plusieurs réseaux locaux distants dont le routeur est un serveur
>> Debian sur lequel un client OpenVPN  est installé.
>>
>> Je souhaite pouvoir depuis mon propre PC sur lequel est aussi installé un
>> client OpenVPN, atteindre les machines connectées des différents réseaux
>> locaux distants qui par ailleurs, sont à peu près tous configurés de la
>> même façon (tous en 192.168.1.0/24, par exemple).
>>
>> Pour fixer les choses, j'envisage d'opérer de la façon suivante:
>> +  sur mon PC:
>> A. je lance mon client OpenVPN
>> B. j'adapte ma configuration réseau en indiquant comment atteindre les
>> machines d'un réseau distant
>> + sur mon serveur OpenVPN
>> C. j'adapte ma configuration réseau
>> + sur un routeur Debian distant particulier:
>> D. j'adapte la configuration réseau afin que les machines du réseau local
>> puissent communiquer avec mon PC (par chance, le routeur Debian est déjà la
>> passerelle par défaut de ces machines).
>>
>> Le serveur OpenVPN est une machine sur le cloud.
>> J'ai découvert que je pouvais utiliser l'option client-to-client
>> d'OpenVPN pour permettre la communication directe entre deux clients
>> OpenVPN.
>> J'ai lu en [1], que cette communication s'opérait à "l'insu de la
>> configuration réseau du serveur OpenVPN" : les flux passaient directement
>> d'un client OpenVPN à un autre sans que je puisse, avec le firewall du
>> serveur OpenVPN définir des régles très précises comme celle de n'autoriser
>> que la communication depuis ou vers un ou deux clients OpenVPN.
>>
>> Mes questions:
>> 1. Ai-je bien compris [1] et [1] est-il bien toujours valable ?
>>
>> 2. J'imaginais configurer l'étape D si dessus par un simple NAT avec
>> iptables du type (10.8.1.70 est l'IP dans le VPN du routeur Debian):
>> iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70
>> Qu'en pensez-vous ?
>>
>> 3. Que faire pour les étapes B et C ?
>> J'ai essayé sans trop de succès différentes commande "ip route add" sans
>> succès pour l'instant.
>>
>> Slts
>>
>>
>>
>>
>>
>>
>>

Re: Conseils sur le routage de client à client avec OpenVPN

[Olivier]

Le mer. 23 janv. 2019 à 14:39, Olivier Bitsch  a
écrit :

> Bonjour Olivier,
>
> 1. Oui tu as bien compris, client-to-client ne transite pas le paquet par
> le serveur. Du coup pas de filtrage possible si c'est option est activée.
>
> 2. Si tous les réseaux connectés sont sur le même réseau (192.168.1.0/24),
> je ne vois pas comment il sera possible de router les paquets d'un réseau
> comme il faut. Donc je ne vois pas comment ça peut marcher.
>

Je viens d'y passer la matinée mais sans succès malheureusement.

En mode client-to-client, les clients peuvent facilement se parler mais
c'est tout:
une commande "ip route add 192.168.1.0/24 via 10.8.1.40"  est refusée même
si je peux atteindre (via openvpn) l'adresse 10.8.1.40.

J'ai l'impression qu'il faut jouer avec des paramètres OpenVPN  comme route
(côte client OpenVPN) et/ou iroute (côte serveur OpenVPN) mais je n'ai pas
encore essayé.

>
> 3. Pour les étapes B et C, et sous réserve que chaque réseau aient leur
> propre adressage, il faut utiliser la topologie subnet avec OpenVPN. Je
> peux te donner des exemples si tu en as besoin.
>
> obitwo
>
> Le mar. 22 janv. 2019 à 16:48, Olivier  a écrit :
>
>> Bonjour,
>>
>> J'ai plusieurs réseaux locaux distants dont le routeur est un serveur
>> Debian sur lequel un client OpenVPN  est installé.
>>
>> Je souhaite pouvoir depuis mon propre PC sur lequel est aussi installé un
>> client OpenVPN, atteindre les machines connectées des différents réseaux
>> locaux distants qui par ailleurs, sont à peu près tous configurés de la
>> même façon (tous en 192.168.1.0/24, par exemple).
>>
>> Pour fixer les choses, j'envisage d'opérer de la façon suivante:
>> +  sur mon PC:
>> A. je lance mon client OpenVPN
>> B. j'adapte ma configuration réseau en indiquant comment atteindre les
>> machines d'un réseau distant
>> + sur mon serveur OpenVPN
>> C. j'adapte ma configuration réseau
>> + sur un routeur Debian distant particulier:
>> D. j'adapte la configuration réseau afin que les machines du réseau local
>> puissent communiquer avec mon PC (par chance, le routeur Debian est déjà la
>> passerelle par défaut de ces machines).
>>
>> Le serveur OpenVPN est une machine sur le cloud.
>> J'ai découvert que je pouvais utiliser l'option client-to-client
>> d'OpenVPN pour permettre la communication directe entre deux clients
>> OpenVPN.
>> J'ai lu en [1], que cette communication s'opérait à "l'insu de la
>> configuration réseau du serveur OpenVPN" : les flux passaient directement
>> d'un client OpenVPN à un autre sans que je puisse, avec le firewall du
>> serveur OpenVPN définir des régles très précises comme celle de n'autoriser
>> que la communication depuis ou vers un ou deux clients OpenVPN.
>>
>> Mes questions:
>> 1. Ai-je bien compris [1] et [1] est-il bien toujours valable ?
>>
>> 2. J'imaginais configurer l'étape D si dessus par un simple NAT avec
>> iptables du type (10.8.1.70 est l'IP dans le VPN du routeur Debian):
>> iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70
>> Qu'en pensez-vous ?
>>
>> 3. Que faire pour les étapes B et C ?
>> J'ai essayé sans trop de succès différentes commande "ip route add" sans
>> succès pour l'instant.
>>
>> Slts
>>
>>
>>
>>
>>
>>
>>

Re: Conseils sur le routage de client à client avec OpenVPN

[Olivier Bitsch]

Bonjour Olivier,

1. Oui tu as bien compris, client-to-client ne transite pas le paquet par
le serveur. Du coup pas de filtrage possible si c'est option est activée.

2. Si tous les réseaux connectés sont sur le même réseau (192.168.1.0/24),
je ne vois pas comment il sera possible de router les paquets d'un réseau
comme il faut. Donc je ne vois pas comment ça peut marcher.

3. Pour les étapes B et C, et sous réserve que chaque réseau aient leur
propre adressage, il faut utiliser la topologie subnet avec OpenVPN. Je
peux te donner des exemples si tu en as besoin.

obitwo

Le mar. 22 janv. 2019 à 16:48, Olivier  a écrit :

> Bonjour,
>
> J'ai plusieurs réseaux locaux distants dont le routeur est un serveur
> Debian sur lequel un client OpenVPN  est installé.
>
> Je souhaite pouvoir depuis mon propre PC sur lequel est aussi installé un
> client OpenVPN, atteindre les machines connectées des différents réseaux
> locaux distants qui par ailleurs, sont à peu près tous configurés de la
> même façon (tous en 192.168.1.0/24, par exemple).
>
> Pour fixer les choses, j'envisage d'opérer de la façon suivante:
> +  sur mon PC:
> A. je lance mon client OpenVPN
> B. j'adapte ma configuration réseau en indiquant comment atteindre les
> machines d'un réseau distant
> + sur mon serveur OpenVPN
> C. j'adapte ma configuration réseau
> + sur un routeur Debian distant particulier:
> D. j'adapte la configuration réseau afin que les machines du réseau local
> puissent communiquer avec mon PC (par chance, le routeur Debian est déjà la
> passerelle par défaut de ces machines).
>
> Le serveur OpenVPN est une machine sur le cloud.
> J'ai découvert que je pouvais utiliser l'option client-to-client d'OpenVPN
> pour permettre la communication directe entre deux clients OpenVPN.
> J'ai lu en [1], que cette communication s'opérait à "l'insu de la
> configuration réseau du serveur OpenVPN" : les flux passaient directement
> d'un client OpenVPN à un autre sans que je puisse, avec le firewall du
> serveur OpenVPN définir des régles très précises comme celle de n'autoriser
> que la communication depuis ou vers un ou deux clients OpenVPN.
>
> Mes questions:
> 1. Ai-je bien compris [1] et [1] est-il bien toujours valable ?
>
> 2. J'imaginais configurer l'étape D si dessus par un simple NAT avec
> iptables du type (10.8.1.70 est l'IP dans le VPN du routeur Debian):
> iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70
> Qu'en pensez-vous ?
>
> 3. Que faire pour les étapes B et C ?
> J'ai essayé sans trop de succès différentes commande "ip route add" sans
> succès pour l'instant.
>
> Slts
>
>
>
>
>
>
>

Re: Conseils sur le routage de client à client avec OpenVPN

[Daniel Huhardeaux]

Le 22/01/2019 à 19:18, Olivier a écrit :



Le mar. 22 janv. 2019 à 17:31, Daniel Huhardeaux <mailto:no-s...@tootai.net>> a écrit :


Le 22/01/2019 à 16:48, Olivier a écrit :
 > Bonjour,

Bonjour



1. les machines des réseaux de l'entreprise: un serveur OpenVPN en mode
tun, tous les serveurs des sites clients s'y connectent, je peux
joindre
n'importe quel machine sur ces autres réseaux, aucun n'a le même plan
d'adresses IP.

Comment le "routage" entre le réseau distant et les clients du VPN ?


Le serveur OpenVPN sait comment joindre chaque IP puisque chaque client 
pousse sa route. Pour que cela fonctionne aussi avec les machines 
Windows un masquerade fait son job. J'ai créé un script (cde up de la 
config openvpn) qui fait le travail lorsque le VPN est monté, script 
installé sur chaque client OpenVPN d'un site.


--
Daniel

Re: Conseils sur le routage de client à client avec OpenVPN

[Daniel Huhardeaux]

Le 22/01/2019 à 19:16, Olivier a écrit :

Merci Daniel pour ta réponse.

J'aurai pu le préciser mais j'arrive à me connecter ponctuellement aux 
équipements distants via des commandes SSH du type ssh -f -N foo@remote 
-L1234:192.168.151:80 mais c'est assez fastidieux car je dois désigner 
les ports distants, choisir des ports disponibles sur ma machine, 
ajouter un éventuel rebond.


Je recherche maintenant à re-configurer le réseau afin d'avoir une 
re-configuration ponctuelle plus générique


Justement, en centralisant les connexions sur un serveur, VPN et/ou ssh, 
tu ne reconfigures plus le réseau: le fichier ~/.ssh/config contiendra 
les commandes nécessaires afin de ne faire qu'un simple "ssh "


Je trouve d'ailleurs dommage que mosh ne gère pas le fichier config de ssh.



Le mar. 22 janv. 2019 à 17:31, Daniel Huhardeaux > a écrit :


Le 22/01/2019 à 16:48, Olivier a écrit :
 > Bonjour,

Bonjour

 >
 > J'ai plusieurs réseaux locaux distants dont le routeur est un
serveur
 > Debian sur lequel un client OpenVPN  est installé.
 >
 > Je souhaite pouvoir depuis mon propre PC sur lequel est aussi
installé
 > un client OpenVPN, atteindre les machines connectées des différents
 > réseaux locaux distants qui par ailleurs, sont à peu près tous
 > configurés de la même façon (tous en 192.168.1.0/24

 > , par exemple).
 >
 > Pour fixer les choses, j'envisage d'opérer de la façon suivante:
 > +  sur mon PC:
 > A. je lance mon client OpenVPN
 > B. j'adapte ma configuration réseau en indiquant comment
atteindre les
 > machines d'un réseau distant
 > + sur mon serveur OpenVPN
 > C. j'adapte ma configuration réseau
 > + sur un routeur Debian distant particulier:
 > D. j'adapte la configuration réseau afin que les machines du réseau
 > local puissent communiquer avec mon PC (par chance, le routeur
Debian
 > est déjà la passerelle par défaut de ces machines).
 >
 > Le serveur OpenVPN est une machine sur le cloud.
 > J'ai découvert que je pouvais utiliser l'option client-to-client
 > d'OpenVPN pour permettre la communication directe entre deux clients
 > OpenVPN.
 > J'ai lu en [1], que cette communication s'opérait à "l'insu de la
 > configuration réseau du serveur OpenVPN" : les flux passaient
 > directement d'un client OpenVPN à un autre sans que je puisse,
avec le
 > firewall du serveur OpenVPN définir des régles très précises
comme celle
 > de n'autoriser que la communication depuis ou vers un ou deux
clients
 > OpenVPN.
 >
 > Mes questions:
 > 1. Ai-je bien compris [1] et [1] est-il bien toujours valable ?
 >
 > 2. J'imaginais configurer l'étape D si dessus par un simple NAT avec
 > iptables du type (10.8.1.70 est l'IP dans le VPN du routeur Debian):
 > iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70
 > Qu'en pensez-vous ?
 >
 > 3. Que faire pour les étapes B et C ?
 > J'ai essayé sans trop de succès différentes commande "ip route
add" sans
 > succès pour l'instant.

Perso j'utilise 2 types d'organisations:

1. les machines des réseaux de l'entreprise: un serveur OpenVPN en mode
tun, tous les serveurs des sites clients s'y connectent, je peux
joindre
n'importe quel machine sur ces autres réseaux, aucun n'a le même plan
d'adresses IP.

L'inconvénient pour toi est que justement tous les réseaux auxquels tu
veux te joindre ont le même plan d'adressage IP

2. les réseaux des clients: j'utilise un serveur OpenVPN mode tun en DC
auquel les serveurs clients se connectent soit via OpenVPN soit en ssh
avec autossh (reverse ssh).

Dans les 2 cas, à partir de mon portable je peux joindre n'importe quel
machine derrière les réseaux clients en utilisant les commandes ssh
(pour le cas 2 essentiellement ProxyCommand pour tous les clients,
Hostname en plus pour ceux en VPN)

-- 
Daniel

Re: Conseils sur le routage de client à client avec OpenVPN

[Olivier]

Le mar. 22 janv. 2019 à 17:31, Daniel Huhardeaux  a
écrit :

> Le 22/01/2019 à 16:48, Olivier a écrit :
> > Bonjour,
>
> Bonjour
>
>
>
> 1. les machines des réseaux de l'entreprise: un serveur OpenVPN en mode
> tun, tous les serveurs des sites clients s'y connectent, je peux joindre
> n'importe quel machine sur ces autres réseaux, aucun n'a le même plan
> d'adresses IP.
>
> Comment le "routage" entre le réseau distant et les clients du VPN ?

Re: Conseils sur le routage de client à client avec OpenVPN

[Olivier]

Merci Daniel pour ta réponse.

J'aurai pu le préciser mais j'arrive à me connecter ponctuellement aux
équipements distants via des commandes SSH du type ssh -f -N foo@remote
-L1234:192.168.151:80 mais c'est assez fastidieux car je dois désigner les
ports distants, choisir des ports disponibles sur ma machine, ajouter un
éventuel rebond.

Je recherche maintenant à re-configurer le réseau afin d'avoir une
re-configuration ponctuelle plus générique

Le mar. 22 janv. 2019 à 17:31, Daniel Huhardeaux  a
écrit :

> Le 22/01/2019 à 16:48, Olivier a écrit :
> > Bonjour,
>
> Bonjour
>
> >
> > J'ai plusieurs réseaux locaux distants dont le routeur est un serveur
> > Debian sur lequel un client OpenVPN  est installé.
> >
> > Je souhaite pouvoir depuis mon propre PC sur lequel est aussi installé
> > un client OpenVPN, atteindre les machines connectées des différents
> > réseaux locaux distants qui par ailleurs, sont à peu près tous
> > configurés de la même façon (tous en 192.168.1.0/24
> > , par exemple).
> >
> > Pour fixer les choses, j'envisage d'opérer de la façon suivante:
> > +  sur mon PC:
> > A. je lance mon client OpenVPN
> > B. j'adapte ma configuration réseau en indiquant comment atteindre les
> > machines d'un réseau distant
> > + sur mon serveur OpenVPN
> > C. j'adapte ma configuration réseau
> > + sur un routeur Debian distant particulier:
> > D. j'adapte la configuration réseau afin que les machines du réseau
> > local puissent communiquer avec mon PC (par chance, le routeur Debian
> > est déjà la passerelle par défaut de ces machines).
> >
> > Le serveur OpenVPN est une machine sur le cloud.
> > J'ai découvert que je pouvais utiliser l'option client-to-client
> > d'OpenVPN pour permettre la communication directe entre deux clients
> > OpenVPN.
> > J'ai lu en [1], que cette communication s'opérait à "l'insu de la
> > configuration réseau du serveur OpenVPN" : les flux passaient
> > directement d'un client OpenVPN à un autre sans que je puisse, avec le
> > firewall du serveur OpenVPN définir des régles très précises comme celle
> > de n'autoriser que la communication depuis ou vers un ou deux clients
> > OpenVPN.
> >
> > Mes questions:
> > 1. Ai-je bien compris [1] et [1] est-il bien toujours valable ?
> >
> > 2. J'imaginais configurer l'étape D si dessus par un simple NAT avec
> > iptables du type (10.8.1.70 est l'IP dans le VPN du routeur Debian):
> > iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70
> > Qu'en pensez-vous ?
> >
> > 3. Que faire pour les étapes B et C ?
> > J'ai essayé sans trop de succès différentes commande "ip route add" sans
> > succès pour l'instant.
>
> Perso j'utilise 2 types d'organisations:
>
> 1. les machines des réseaux de l'entreprise: un serveur OpenVPN en mode
> tun, tous les serveurs des sites clients s'y connectent, je peux joindre
> n'importe quel machine sur ces autres réseaux, aucun n'a le même plan
> d'adresses IP.
>
> L'inconvénient pour toi est que justement tous les réseaux auxquels tu
> veux te joindre ont le même plan d'adressage IP
>
> 2. les réseaux des clients: j'utilise un serveur OpenVPN mode tun en DC
> auquel les serveurs clients se connectent soit via OpenVPN soit en ssh
> avec autossh (reverse ssh).
>
> Dans les 2 cas, à partir de mon portable je peux joindre n'importe quel
> machine derrière les réseaux clients en utilisant les commandes ssh
> (pour le cas 2 essentiellement ProxyCommand pour tous les clients,
> Hostname en plus pour ceux en VPN)
>
> --
> Daniel
>
>

Re: Conseils sur le routage de client à client avec OpenVPN

[Daniel Huhardeaux]

Le 22/01/2019 à 16:48, Olivier a écrit :

Bonjour,


Bonjour



J'ai plusieurs réseaux locaux distants dont le routeur est un serveur 
Debian sur lequel un client OpenVPN  est installé.


Je souhaite pouvoir depuis mon propre PC sur lequel est aussi installé 
un client OpenVPN, atteindre les machines connectées des différents 
réseaux locaux distants qui par ailleurs, sont à peu près tous 
configurés de la même façon (tous en 192.168.1.0/24 
, par exemple).


Pour fixer les choses, j'envisage d'opérer de la façon suivante:
+  sur mon PC:
A. je lance mon client OpenVPN
B. j'adapte ma configuration réseau en indiquant comment atteindre les 
machines d'un réseau distant

+ sur mon serveur OpenVPN
C. j'adapte ma configuration réseau
+ sur un routeur Debian distant particulier:
D. j'adapte la configuration réseau afin que les machines du réseau 
local puissent communiquer avec mon PC (par chance, le routeur Debian 
est déjà la passerelle par défaut de ces machines).


Le serveur OpenVPN est une machine sur le cloud.
J'ai découvert que je pouvais utiliser l'option client-to-client 
d'OpenVPN pour permettre la communication directe entre deux clients 
OpenVPN.
J'ai lu en [1], que cette communication s'opérait à "l'insu de la 
configuration réseau du serveur OpenVPN" : les flux passaient 
directement d'un client OpenVPN à un autre sans que je puisse, avec le 
firewall du serveur OpenVPN définir des régles très précises comme celle 
de n'autoriser que la communication depuis ou vers un ou deux clients 
OpenVPN.


Mes questions:
1. Ai-je bien compris [1] et [1] est-il bien toujours valable ?

2. J'imaginais configurer l'étape D si dessus par un simple NAT avec 
iptables du type (10.8.1.70 est l'IP dans le VPN du routeur Debian):

iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70
Qu'en pensez-vous ?

3. Que faire pour les étapes B et C ?
J'ai essayé sans trop de succès différentes commande "ip route add" sans 
succès pour l'instant.


Perso j'utilise 2 types d'organisations:

1. les machines des réseaux de l'entreprise: un serveur OpenVPN en mode 
tun, tous les serveurs des sites clients s'y connectent, je peux joindre 
n'importe quel machine sur ces autres réseaux, aucun n'a le même plan 
d'adresses IP.


L'inconvénient pour toi est que justement tous les réseaux auxquels tu 
veux te joindre ont le même plan d'adressage IP


2. les réseaux des clients: j'utilise un serveur OpenVPN mode tun en DC 
auquel les serveurs clients se connectent soit via OpenVPN soit en ssh 
avec autossh (reverse ssh).


Dans les 2 cas, à partir de mon portable je peux joindre n'importe quel 
machine derrière les réseaux clients en utilisant les commandes ssh 
(pour le cas 2 essentiellement ProxyCommand pour tous les clients, 
Hostname en plus pour ceux en VPN)


--
Daniel

Conseils sur le routage de client à client avec OpenVPN

[Olivier]

Bonjour,

J'ai plusieurs réseaux locaux distants dont le routeur est un serveur
Debian sur lequel un client OpenVPN  est installé.

Je souhaite pouvoir depuis mon propre PC sur lequel est aussi installé un
client OpenVPN, atteindre les machines connectées des différents réseaux
locaux distants qui par ailleurs, sont à peu près tous configurés de la
même façon (tous en 192.168.1.0/24, par exemple).

Pour fixer les choses, j'envisage d'opérer de la façon suivante:
+  sur mon PC:
A. je lance mon client OpenVPN
B. j'adapte ma configuration réseau en indiquant comment atteindre les
machines d'un réseau distant
+ sur mon serveur OpenVPN
C. j'adapte ma configuration réseau
+ sur un routeur Debian distant particulier:
D. j'adapte la configuration réseau afin que les machines du réseau local
puissent communiquer avec mon PC (par chance, le routeur Debian est déjà la
passerelle par défaut de ces machines).

Le serveur OpenVPN est une machine sur le cloud.
J'ai découvert que je pouvais utiliser l'option client-to-client d'OpenVPN
pour permettre la communication directe entre deux clients OpenVPN.
J'ai lu en [1], que cette communication s'opérait à "l'insu de la
configuration réseau du serveur OpenVPN" : les flux passaient directement
d'un client OpenVPN à un autre sans que je puisse, avec le firewall du
serveur OpenVPN définir des régles très précises comme celle de n'autoriser
que la communication depuis ou vers un ou deux clients OpenVPN.

Mes questions:
1. Ai-je bien compris [1] et [1] est-il bien toujours valable ?

2. J'imaginais configurer l'étape D si dessus par un simple NAT avec
iptables du type (10.8.1.70 est l'IP dans le VPN du routeur Debian):
iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70
Qu'en pensez-vous ?

3. Que faire pour les étapes B et C ?
J'ai essayé sans trop de succès différentes commande "ip route add" sans
succès pour l'instant.

Slts

Re: pb routage avancé, pas la bonne connexion dans netstat

[Jérémy PREGO]

Le 18/03/2018 à 12:24, Pascal Hambourg a écrit :
Fais en sorte que eth0 ne tombe pas. Par exemple avec une 
configuration IP statique.




justement, c'est le problème que j'ai, la, j'ai pris l'exemple d'une vm, 
mais sur mon serveur, eth0 est une connexion qui doit être en dhcp, 
(ftth directement connecté au linux)., donc il arrive parfois que ça 
bug. peut être que la solution serait de mettre une connexion par 
défault en ip fixe, même si elle pointe vers rien, et de faire une route 
par défaut alternative pour la ftth, histoire que ce soit elle qui soit 
prioritaire quand elle fonctionne, et qu'elle n'ammène pas tout le reste 
avec elle, quand elle tombe :(


Ce n'est pas possible dans cette configuration. Le marquage de paquet 
par iptables ne peut avoir lieu que lorsque le paquet a déjà été 
généré, donc après que l'interface de sortie et l'adresse source ont 
déjà été déterminées par la décision de routage initiale.


je m'y attendais un peu, voilà pourquoi j'ai posé la question de cette 
façon, mais ça m'arrange pas :(


Tu n'as pas aussi une règle iptables SNAT ou MASQUERADE ?


si si, sur eth1

Re: pb routage avancé, pas la bonne connexion dans netstat

[Pascal Hambourg]

Le 18/03/2018 à 04:47, Jérémy PREGO a écrit :


eth0, 192.168.56.6/24 (par défaut)
eth1, 192.168.8.100/24

dans cette exemple, je redirige le port tcp 80 en destination vers eth1 
avec iptables et le marquage de paquet. aucun souci pour ça, ça 
fonctionne bien, ça sort bien par eth1. Mais il y a un mais, c'est que 
dans netstat, ça affiche la connexion établie  par eth0, donc, si pour 
n'importe quel raison eth0 tombe, la connexion se réinitialise ...


Fais en sorte que eth0 ne tombe pas. Par exemple avec une configuration 
IP statique.


comment faire pour que ça passe bien par eth1 dès l'établissement de la 
connexion ? est-ce que c'est possible d'ailleurs dans cette configuration ?


Ce n'est pas possible dans cette configuration. Le marquage de paquet 
par iptables ne peut avoir lieu que lorsque le paquet a déjà été généré, 
donc après que l'interface de sortie et l'adresse source ont déjà été 
déterminées par la décision de routage initiale.



voilà ce que je fais pour faire mon routage:

root@debian:~# netstat -antp |grep 46.105
tcp    0  0 192.168.56.6:32928  46.105.x.x:80 ESTABLISHED 
983/wget

root@debian:~# cat route.sh
#!/bin/bash

ip rule add fwmark 0x1 table 100

iptables -t mangle -A OUTPUT  -p tcp --dport 80 -j MARK --set-mark 0x1

ip -4 route add default via 192.168.8.1 dev usb4g-1 table 100
ip rule add from 192.168.8.100 table 100


Tu n'as pas aussi une règle iptables SNAT ou MASQUERADE ?

pb routage avancé, pas la bonne connexion dans netstat

[Jérémy PREGO]

bonjour,

tout d'abord désolé pour ce titre un peu bizarre, mais je ne sais pas 
comment décrire ça mieux :(


je m'explique.

une debian stretch sur laquelle je fais du routage avancé, donc j'ai 
deux interfaces.


eth0, 192.168.56.6/24 (par défaut)
eth1, 192.168.8.100/24

dans cette exemple, je redirige le port tcp 80 en destination vers eth1 
avec iptables et le marquage de paquet. aucun souci pour ça, ça 
fonctionne bien, ça sort bien par eth1. Mais il y a un mais, c'est que 
dans netstat, ça affiche la connexion établie  par eth0, donc, si pour 
n'importe quel raison eth0 tombe, la connexion se réinitialise ...


comment faire pour que ça passe bien par eth1 dès l'établissement de la 
connexion ? est-ce que c'est possible d'ailleurs dans cette configuration ?


merci d'avance !

jerem

voilà ce que je fais pour faire mon routage:

root@debian:~# netstat -antp |grep 46.105
tcp    0  0 192.168.56.6:32928  46.105.x.x:80 ESTABLISHED 
983/wget

root@debian:~# cat route.sh
#!/bin/bash

ip rule add fwmark 0x1 table 100

iptables -t mangle -A OUTPUT  -p tcp --dport 80 -j MARK --set-mark 0x1

ip -4 route add default via 192.168.8.1 dev usb4g-1 table 100
ip rule add from 192.168.8.100 table 100

root@debian:~#

Re: Routage - Route - wifi - wifi android

[Vincent Lefevre]

Bonjour,

On 2017-02-16 16:17:31 +0100, G2PC wrote:
> Sur certains points d'accès wifi ou wifi partagé depuis un téléphone
> android, la connexion s'établit mais le réseau internet ne fonctionne pas.
> 
> Sur d'autres wifi connectés le réseau internet fonctionne.

J'ai aussi remarqué ça dans le passé (mais je n'utilise pas beaucoup
le tethering, surtout sur du wifi).

Pour info:

  
http://android.stackexchange.com/questions/47819/how-can-phone-companies-detect-tethering-incl-wifi-hotspot

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Routage - Route - wifi - wifi android

[G2PC]

Bonjour

Sur certains points d'accès wifi ou wifi partagé depuis un téléphone
android, la connexion s'établit mais le réseau internet ne fonctionne pas.

Sur d'autres wifi connectés le réseau internet fonctionne.

Re: [Un peu HS] Comment s'assurer du routage openvpn ?

[BERTRAND Joël]

Eric Degenetais a écrit :

Je crois qu'il traîne encore des routeurs qui ne gèrent ni IPV6 ni la
transition IPV6-IPV4. IPV6 est désactivé chez moi car la livebox
m'avait fait le coup.
Le symptôme de ce que j'avais constaté (et résolu à grand renfort de
google mon ami...) est que la résolution DNS présente des défaillances
aléatoires. L'explication (telle que je l'avais comprise) est que
quand le système support IPV6, il envoie à la fois des requêtes DNS
IPV4 et IPV6. Si tu as sur la route un système avec un résolveur
incompatible, il répond par des DNS fail sur les requêtes IPV6.
Résultat, aléatoirement, soit la requête IPV4 répond en premier et tu
réussis à résoudre le nom et contacter ta cible, soit c'est la IPV6
qui répond en premier et tu te prends le mur...



	Sans compter la gestion folklorique d'IPv6 lorsqu'il est officiellement 
supporté. Je me bats avec l'IPv6 forwarding du noyau Linux qui 
fonctionne franchement bizarrement et avec les MTU parfois étranges des 
réseaux IPv6. IPv6, c'est encore un truc pas fiable et très chatouilleux.


Cordialement,

JKB

Re: [Un peu HS] Comment s'assurer du routage openvpn ?

[Eric Degenetais]

Je crois qu'il traîne encore des routeurs qui ne gèrent ni IPV6 ni la
transition IPV6-IPV4. IPV6 est désactivé chez moi car la livebox
m'avait fait le coup.
Le symptôme de ce que j'avais constaté (et résolu à grand renfort de
google mon ami...) est que la résolution DNS présente des défaillances
aléatoires. L'explication (telle que je l'avais comprise) est que
quand le système support IPV6, il envoie à la fois des requêtes DNS
IPV4 et IPV6. Si tu as sur la route un système avec un résolveur
incompatible, il répond par des DNS fail sur les requêtes IPV6.
Résultat, aléatoirement, soit la requête IPV4 répond en premier et tu
réussis à résoudre le nom et contacter ta cible, soit c'est la IPV6
qui répond en premier et tu te prends le mur...

__
Éric Dégenètais
Henix



http://www.henix.com
http://www.squashtest.org



Le 22 mars 2016 à 09:39, C. Mourad Jaber <m...@nativobject.net> a écrit :
> Le 16/03/2016 10:26, C. Mourad Jaber a écrit :
>>
>> Bonjour,
>>
>> Je rencontre une difficulté avec openvpn...
>>
>> J'ai mis en place une solution openvpn qui me permet de router vers
>> internet.
>>
>> Je l'utilise pour éviter les réseaux non sûres (wifi publique par
>> exemple)
>>
>> Dans la majorité des cas, cela semble fonctionner, sauf pour certains
>> portails captifs où il me semble que la résolution dns semble rester celle
>> du wifi et donc les redirections se font mal ou bien certains site/numéro de
>> port ne sont pas accessibles...
>>
>> Au niveau client, j'utilise le widget network-manager.
>>
>> Étant une bille en routage réseau, y'a-t-il des règles à ajouter dans
>> openvpn pour s'assurer que la route par défaut est bien le tunnel chiffré ?
>>
>> ++
>>
>> Mourad
>>
> J'ai avancé un peu, cela semble lié à IPV6...
>
> Mon serveur VPN est en IPV4 uniquement et le réseau qui me pose problème
> gère les 2 protocoles (IPV4 et IPV6)...
>
> Si je désactive l'IPV6 sur ma machine, tout ce passe bien, je peux de
> nouveau accéder aux miroirs debian, par exemple...
>
> Si l'IPV6 est actif j'ai des erreurs de connexion...
>
> Donc ce n'est probablement pas un soucis de openvpn mais un problème plus
> profond...
>
> Mes 2 cents
>
> Mourad
>

Re: [Un peu HS] Comment s'assurer du routage openvpn ?

[C. Mourad Jaber]

Le 16/03/2016 10:26, C. Mourad Jaber a écrit :

Bonjour,

Je rencontre une difficulté avec openvpn...

J'ai mis en place une solution openvpn qui me permet de router vers internet.

Je l'utilise pour éviter les réseaux non sûres (wifi publique par exemple)

Dans la majorité des cas, cela semble fonctionner, sauf pour certains portails captifs 
où il me semble que la résolution dns semble rester celle du wifi et donc les 
redirections se font mal ou bien certains site/numéro de port ne sont pas accessibles...


Au niveau client, j'utilise le widget network-manager.

Étant une bille en routage réseau, y'a-t-il des règles à ajouter dans openvpn pour 
s'assurer que la route par défaut est bien le tunnel chiffré ?


++

Mourad


J'ai avancé un peu, cela semble lié à IPV6...

Mon serveur VPN est en IPV4 uniquement et le réseau qui me pose problème gère les 2 
protocoles (IPV4 et IPV6)...


Si je désactive l'IPV6 sur ma machine, tout ce passe bien, je peux de nouveau accéder aux 
miroirs debian, par exemple...


Si l'IPV6 est actif j'ai des erreurs de connexion...

Donc ce n'est probablement pas un soucis de openvpn mais un problème plus 
profond...

Mes 2 cents

Mourad

[Un peu HS] Comment s'assurer du routage openvpn ?

[C. Mourad Jaber]

Bonjour,

Je rencontre une difficulté avec openvpn...

J'ai mis en place une solution openvpn qui me permet de router vers internet.

Je l'utilise pour éviter les réseaux non sûres (wifi publique par exemple)

Dans la majorité des cas, cela semble fonctionner, sauf pour certains portails captifs où 
il me semble que la résolution dns semble rester celle du wifi et donc les redirections se 
font mal ou bien certains site/numéro de port ne sont pas accessibles...


Au niveau client, j'utilise le widget network-manager.

Étant une bille en routage réseau, y'a-t-il des règles à ajouter dans openvpn pour 
s'assurer que la route par défaut est bien le tunnel chiffré ?


++

Mourad

[résolu] Re: Pb de routage entre deux sites via openvpn

[Yann COHEN]

Résolu :
le nom du fichier ccd qui contient les options spécifique du client doit
être le full qualified name du client qui se connecte : avec le nom de
domaine complet.

Yann.

Le vendredi 29 août 2014 à 18:29 +0200, Yann Cohen a écrit : 
 Bonjour,
 
 je sèche sur un problème de routage entre deux sites qui sont connectés
 via openvpn.
 
 Chaque coté du tunnel est un serveur debian (old-stable et jessie).
 
 Le serveur (firewall) est coté old-stable, le client coté jessie.
 
 Le serveur dessert les réseaux 192.168.3.0/24, 192.168.4.0/24 et
 192.168.1.0/24
 
 Le vpn est dans le plan d'@ 192.168.100.0/24
 
 Le client (sky) dessert le réseau 192.168.29.0/24.
 
 la table de routage coté serveur est la suivante :
[...]

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/1409916046.3575.4.camel@yan

Re: [résolu] Re: Pb de routage entre deux sites via openvpn

[Christophe]

Bonsoir,

Le 05/09/2014 13:20, Yann COHEN a écrit :


Résolu :
le nom du fichier ccd qui contient les options spécifique du client doit
être le full qualified name du client qui se connecte : avec le nom de
domaine complet.

Yann.



En fait ça dépend surtout de comment tu as nommé le certificat client à 
sa création (champ Common Name) : c'est la dessus que le ccd se base 
pour pousser les options spécifiques au client.


@+
Christophe.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/5409ec86.4050...@stuxnet.org

Re: Pb de routage entre deux sites via openvpn

[Yann Cohen]

Bonjour,

Voici les compléments de configuration.

De plus, il me semble avoir omis une information :
les serveurs, dont firewall, sont des machines virtuelles (xen 4.0.1) et
après une nuit de sommeil, je me rappelle avoir eu des problèmes avec
UDP sur ce type de configuration (les requêtes snmp ne fonctionnaient
pas bien).


Le samedi 30 août 2014 à 16:30 +0200, Pascal Hambourg a écrit :
 Yann Cohen a écrit :
  Bonjour,
  
  je sèche sur un problème de routage entre deux sites qui sont connectés
  via openvpn. [...]
 
 Les tables de routage du serveur et du client VPN semblent correctes.
 
 Pour vérifier le routage d'une adresse donnée, exécuter la commande :
 
 ip route get adresse

Coté du réseau client sur une machine en .29
yann@yco-sts-linux:~$ ip route get 192.168.3.50
192.168.3.50 via 192.168.29.10 dev wlan0  src 192.168.29.100 
cache 

Sur sky (client vpn  @.29.10):
root@sky:~# ip route get 192.168.3.50
192.168.3.50 via 192.168.100.21 dev tun0  src 192.168.100.22 
cache 

Sur firewall (serveur vpn @ .3.70, .4.70 et .1.70)
root@firewall:~# ip route get 192.168.29.20
192.168.29.20 via 192.168.100.2 dev tun0  src 192.168.100.1 
cache  mtu 1500 advmss 1460 hoplimit 64

Sur une machine du reseau .3
root@store:~# ip route get 192.168.29.20
192.168.29.20 via 192.168.3.70 dev eth0  src 192.168.3.50 
cache  mtu 1500 advmss 1460 hoplimit 64

iptables-save
Le client :
root@sky:~# iptables-save
# Generated by iptables-save v1.4.21 on Sun Aug 31 07:41:53 2014
*raw
:PREROUTING ACCEPT [234993:26026712]
:OUTPUT ACCEPT [136592:22661450]
-A PREROUTING -p icmp -j TRACE
-A PREROUTING -p icmp -j TRACE
-A OUTPUT -p icmp -j TRACE
-A OUTPUT -p icmp -j TRACE
COMMIT
# Completed on Sun Aug 31 07:41:53 2014
# Generated by iptables-save v1.4.21 on Sun Aug 31 07:41:53 2014
*filter
:INPUT DROP [100:5164]
:FORWARD DROP [79014:9588079]
:OUTPUT DROP [122:12336]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state NEW -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m state --state NEW -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state --state NEW -j ACCEPT
COMMIT
# Completed on Sun Aug 31 07:41:53 2014


Le serveur
root@firewall:~# iptables-save
# Generated by iptables-save v1.4.8 on Sun Aug 31 07:46:02 2014
*raw
:PREROUTING ACCEPT [5697445:3943580901]
:OUTPUT ACCEPT [2767699:2626019169]
-A PREROUTING -p icmp -j TRACE 
-A OUTPUT -p icmp -j TRACE 
COMMIT
# Completed on Sun Aug 31 07:46:02 2014
# Generated by iptables-save v1.4.8 on Sun Aug 31 07:46:02 2014
*nat
:PREROUTING ACCEPT [13814184:1193564665]
:POSTROUTING ACCEPT [4542101:299178859]
:OUTPUT ACCEPT [690955:44154381]
-A PREROUTING -d 192.168.1.70/32 -p tcp -m tcp --sport 20 --dport
1024:65535 -j DNAT --to-destination 192.168.4.40 
-A PREROUTING -d 192.168.1.70/32 -p tcp -m tcp -m multiport --dports
1143,1080,1025,21,20,80,443,143,993,110,995,25,465 -j DNAT
--to-destination 192.168.4.40 
-A PREROUTING -s 192.168.3.0/24 -p tcp -m tcp --dport 80 -j DNAT
--to-destination 192.168.3.70:3128 
-A POSTROUTING -o eth1 -j SNAT --to-source 192.168.1.70 
COMMIT
# Completed on Sun Aug 31 07:46:02 2014
# Generated by iptables-save v1.4.8 on Sun Aug 31 07:46:02 2014
*filter
:INPUT DROP [1:373]
:FORWARD DROP [88:4584]
:OUTPUT DROP [0:0]
:fail2ban-ssh - [0:0]
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -m state --state NEW -j ACCEPT 
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -m state --state NEW -j ACCEPT 
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A OUTPUT -m state --state NEW -j ACCEPT 
-A fail2ban-ssh -j RETURN 
COMMIT
# Completed on Sun Aug 31 07:46:02 2014

 
 sur chaque machine Linux impliquée dans le chemin entre la source
 (incluse) et la destination.
 
 Pour les règles iptables, merci de fournir la sortie d'iptables-save qui
 est plus complète et plus lisible qu'iptables -L.
 
  Les pings depuis une machine sur le .29 vers une machine sur le .3,
  entrent sur br0 de sky, passent sur tun0 de sky mais ne sortent pas de
  tun0 de firewall.
 
 Là j'ai un gros doute. Si ça entre dans le tunnel, ça doit en sortir.
 Sinon c'est le VPN qui ne fait pas son boulot.
 

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1409464855.8368.34.ca...@yco-sts-linux.ianco.homelinux.org

Re: Pb de routage entre deux sites via openvpn

[Pascal Hambourg]

Daniel Huhardeaux a écrit :
 
 Pour ce que tu veux faire il faut passer par des interfaces tap. En tun 
 tu peux le faire, mais il faut rajouter des règles de firewall 
 spécifiques aux clients tun, cela devient une usine à gaz.

Pardon ?
Les interfaces tap sont utiles pour simuler un lien ethernet sur le VPN,
et notamment pour faire du pontage avec ce lien.
Si c'est juste pour du trafic IP routé ça n'apporte rien par rapport à
des interfaces tun, et les règles iptables nécessaires sont les mêmes
dans les deux cas.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/5401dd96.90...@plouf.fr.eu.org

Re: Pb de routage entre deux sites via openvpn

[Pascal Hambourg]

Yann Cohen a écrit :
 Bonjour,
 
 je sèche sur un problème de routage entre deux sites qui sont connectés
 via openvpn. [...]

Les tables de routage du serveur et du client VPN semblent correctes.

Pour vérifier le routage d'une adresse donnée, exécuter la commande :

ip route get adresse

sur chaque machine Linux impliquée dans le chemin entre la source
(incluse) et la destination.

Pour les règles iptables, merci de fournir la sortie d'iptables-save qui
est plus complète et plus lisible qu'iptables -L.

 Les pings depuis une machine sur le .29 vers une machine sur le .3,
 entrent sur br0 de sky, passent sur tun0 de sky mais ne sortent pas de
 tun0 de firewall.

Là j'ai un gros doute. Si ça entre dans le tunnel, ça doit en sortir.
Sinon c'est le VPN qui ne fait pas son boulot.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/5401e005.9040...@plouf.fr.eu.org

Re: Pb de routage entre deux sites via openvpn

[Johnny B]

Hello,

@Yann on a toujours pas eu ta conf iptables ni ta conf openvpn ;)




Le 08/30/2014 04:30 PM, Pascal Hambourg a écrit :

Yann Cohen a écrit :

Bonjour,

je sèche sur un problème de routage entre deux sites qui sont connectés
via openvpn. [...]

Les tables de routage du serveur et du client VPN semblent correctes.

Pour vérifier le routage d'une adresse donnée, exécuter la commande :

ip route get adresse

sur chaque machine Linux impliquée dans le chemin entre la source
(incluse) et la destination.

Pour les règles iptables, merci de fournir la sortie d'iptables-save qui
est plus complète et plus lisible qu'iptables -L.


Les pings depuis une machine sur le .29 vers une machine sur le .3,
entrent sur br0 de sky, passent sur tun0 de sky mais ne sortent pas de
tun0 de firewall.

Là j'ai un gros doute. Si ça entre dans le tunnel, ça doit en sortir.
Sinon c'est le VPN qui ne fait pas son boulot.



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/5401ee5b.7080...@gmail.com

Pb de routage entre deux sites via openvpn

[Yann Cohen]

Bonjour,

je sèche sur un problème de routage entre deux sites qui sont connectés
via openvpn.

Chaque coté du tunnel est un serveur debian (old-stable et jessie).

Le serveur (firewall) est coté old-stable, le client coté jessie.

Le serveur dessert les réseaux 192.168.3.0/24, 192.168.4.0/24 et
192.168.1.0/24

Le vpn est dans le plan d'@ 192.168.100.0/24

Le client (sky) dessert le réseau 192.168.29.0/24.

la table de routage coté serveur est la suivante :
root@firewall:/etc/openvpn# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags   MSS Window  irtt
Iface
192.168.100.2   0.0.0.0 255.255.255.255 UH0 0  0
tun0
192.168.100.0   192.168.100.2   255.255.255.0   UG0 0  0
tun0
192.168.4.0 0.0.0.0 255.255.255.0   U 0 0  0
eth2
192.168.3.0 0.0.0.0 255.255.255.0   U 0 0  0
eth0
192.168.1.0 0.0.0.0 255.255.255.0   U 0 0  0
eth1
192.168.29.0192.168.100.2   255.255.255.0   UG0 0  0
tun0
0.0.0.0 192.168.1.1 0.0.0.0 UG0 0  0
eth1

la table de routage coté client est la suivante :
root@sky:~# netstat -rn
Table de routage IP du noyau
Destination Passerelle  Genmask Indic   MSS Fenêtre irtt
Iface
0.0.0.0 192.168.29.10.0.0.0 UG0 0  0
br0
192.168.1.0 192.168.100.21  255.255.255.0   UG0 0  0
tun0
192.168.3.0 192.168.100.21  255.255.255.0   UG0 0  0
tun0
192.168.4.0 192.168.100.21  255.255.255.0   UG0 0  0
tun0
192.168.29.00.0.0.0 255.255.255.0   U 0 0  0
br0
192.168.100.1   192.168.100.21  255.255.255.255 UGH   0 0  0
tun0
192.168.100.21  0.0.0.0 255.255.255.255 UH0 0  0
tun0

Les routes viennent de la configuration openvpn via les directives :
push route pour .4, .3, .1
route et iroute pour .29

via fwbuilder la table de routage est configurée de chaque coté pour ne
rien bloquer (enfin c'est ce que je crois...).

De chaque coté j'ai mis en place un tshark sur l'interface tun0 et un
sur l'interface eth0 ou br0. Objectif suivre les paquets icmp.

Les pings et les pongs depuis le client (sky) vers l'adresse du serveur
(firewall) en .3 passent.

Les pings depuis firewall vers sky sur l'adresse en .29 ne sont pas
envoyés sur tun0 de firewall.

Les pings depuis une machine sur le .29 vers une machine sur le .3,
entrent sur br0 de sky, passent sur tun0 de sky mais ne sortent pas de
tun0 de firewall.

Je sèche sur ce problème depuis un bon paquets d'heures.

Je suppose que le problème est coté serveur (firewall) mais je ne sais
plus où chercher.

Je suis donc preneur de toute piste...

Cordialement.

Yann.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1409329760.8368.1.ca...@yco-sts-linux.ianco.homelinux.org

Re: Pb de routage entre deux sites via openvpn

[Johnny B]

Salut,

Quelle est ta conf de routage iptables ?

Quelle est ta conf openvpn.conf ?


Le 08/29/2014 06:29 PM, Yann Cohen a écrit :

Bonjour,

je sèche sur un problème de routage entre deux sites qui sont connectés
via openvpn.

Chaque coté du tunnel est un serveur debian (old-stable et jessie).

Le serveur (firewall) est coté old-stable, le client coté jessie.

Le serveur dessert les réseaux 192.168.3.0/24, 192.168.4.0/24 et
192.168.1.0/24

Le vpn est dans le plan d'@ 192.168.100.0/24

Le client (sky) dessert le réseau 192.168.29.0/24.

la table de routage coté serveur est la suivante :
root@firewall:/etc/openvpn# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags   MSS Window  irtt
Iface
192.168.100.2   0.0.0.0 255.255.255.255 UH0 0  0
tun0
192.168.100.0   192.168.100.2   255.255.255.0   UG0 0  0
tun0
192.168.4.0 0.0.0.0 255.255.255.0   U 0 0  0
eth2
192.168.3.0 0.0.0.0 255.255.255.0   U 0 0  0
eth0
192.168.1.0 0.0.0.0 255.255.255.0   U 0 0  0
eth1
192.168.29.0192.168.100.2   255.255.255.0   UG0 0  0
tun0
0.0.0.0 192.168.1.1 0.0.0.0 UG0 0  0
eth1

la table de routage coté client est la suivante :
root@sky:~# netstat -rn
Table de routage IP du noyau
Destination Passerelle  Genmask Indic   MSS Fenêtre irtt
Iface
0.0.0.0 192.168.29.10.0.0.0 UG0 0  0
br0
192.168.1.0 192.168.100.21  255.255.255.0   UG0 0  0
tun0
192.168.3.0 192.168.100.21  255.255.255.0   UG0 0  0
tun0
192.168.4.0 192.168.100.21  255.255.255.0   UG0 0  0
tun0
192.168.29.00.0.0.0 255.255.255.0   U 0 0  0
br0
192.168.100.1   192.168.100.21  255.255.255.255 UGH   0 0  0
tun0
192.168.100.21  0.0.0.0 255.255.255.255 UH0 0  0
tun0

Les routes viennent de la configuration openvpn via les directives :
push route pour .4, .3, .1
route et iroute pour .29

via fwbuilder la table de routage est configurée de chaque coté pour ne
rien bloquer (enfin c'est ce que je crois...).

De chaque coté j'ai mis en place un tshark sur l'interface tun0 et un
sur l'interface eth0 ou br0. Objectif suivre les paquets icmp.

Les pings et les pongs depuis le client (sky) vers l'adresse du serveur
(firewall) en .3 passent.

Les pings depuis firewall vers sky sur l'adresse en .29 ne sont pas
envoyés sur tun0 de firewall.

Les pings depuis une machine sur le .29 vers une machine sur le .3,
entrent sur br0 de sky, passent sur tun0 de sky mais ne sortent pas de
tun0 de firewall.

Je sèche sur ce problème depuis un bon paquets d'heures.

Je suppose que le problème est coté serveur (firewall) mais je ne sais
plus où chercher.

Je suis donc preneur de toute piste...

Cordialement.

Yann.



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/5400d0d1.9050...@gmail.com

Re: Pb de routage entre deux sites via openvpn

[Yann Cohen]

Le vendredi 29 août 2014 à 21:13 +0200, Johnny B a écrit :
 Salut,
Bonsoir,

ci après les conf...
 
 Quelle est ta conf de routage iptables ?
Coté serveur
root@firewall:~# iptables -L
Chain INPUT (policy DROP)
target prot opt source   destination 
fail2ban-ssh  tcp  --  anywhere anywhere
multiport dports ssh 
ACCEPT all  --  anywhere anywherestate
RELATED,ESTABLISHED 
ACCEPT all  --  anywhere anywherestate NEW 

Chain FORWARD (policy DROP)
target prot opt source   destination 
ACCEPT all  --  anywhere anywherestate
RELATED,ESTABLISHED 
ACCEPT all  --  anywhere anywherestate NEW 

Chain OUTPUT (policy DROP)
target prot opt source   destination 
ACCEPT all  --  anywhere anywherestate
RELATED,ESTABLISHED 
ACCEPT all  --  anywhere anywherestate NEW 

Chain fail2ban-ssh (1 references)
target prot opt source   destination 
RETURN all  --  anywhere anywhere

Coté client
root@sky:~# iptables -L
Chain INPUT (policy DROP)
target prot opt source   destination 
ACCEPT all  --  anywhere anywhere state
RELATED,ESTABLISHED
ACCEPT all  --  anywhere anywhere state NEW

Chain FORWARD (policy DROP)
target prot opt source   destination 
ACCEPT all  --  anywhere anywhere state
RELATED,ESTABLISHED
ACCEPT all  --  anywhere anywhere state NEW

Chain OUTPUT (policy DROP)
target prot opt source   destination 
ACCEPT all  --  anywhere anywhere state
RELATED,ESTABLISHED
ACCEPT all  --  anywhere anywhere state NEW

 
 Quelle est ta conf openvpn.conf ?
Serveur
root@firewall:~# grep -v -e # -e ; -e^
$ /etc/openvpn/server.conf
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
dh dh1024.pem
server 192.168.100.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push route 192.168.3.0 255.255.255.0
push route 192.168.4.0 255.255.255.0
push route 192.168.1.0 255.255.255.0
client-config-dir ccd
route 192.168.29.0 255.255.255.0
push route 192.168.29.0 255.255.255.0
client-to-client
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
log openvpn.log
verb 4

ccd
iroute 192.168.29.0 255.255.255.0

Client
root@sky:~# grep -v -e # -e ; -e^
$ /etc/openvpn/connect/clients.d/sky.lys-net/client.conf 
client
dev tun
proto udp
remote xx.yy.zz.www 1194
resolv-retry infinite
cipher DES-EDE3-CBC
ca ca.crt
cert sky.lys-net.crt
key sky.lys-net.key
tls-auth ta.key 1
nobind
persist-key
persist-tun
comp-lzo
verb 3


 
 
 Le 08/29/2014 06:29 PM, Yann Cohen a écrit :
  Bonjour,
 
  je sèche sur un problème de routage entre deux sites qui sont connectés
  via openvpn.
 
  Chaque coté du tunnel est un serveur debian (old-stable et jessie).
 
  Le serveur (firewall) est coté old-stable, le client coté jessie.
 
  Le serveur dessert les réseaux 192.168.3.0/24, 192.168.4.0/24 et
  192.168.1.0/24
 
  Le vpn est dans le plan d'@ 192.168.100.0/24
 
  Le client (sky) dessert le réseau 192.168.29.0/24.
 
  la table de routage coté serveur est la suivante :
  root@firewall:/etc/openvpn# netstat -rn
  Kernel IP routing table
  Destination Gateway Genmask Flags   MSS Window  irtt
  Iface
  192.168.100.2   0.0.0.0 255.255.255.255 UH0 0  0
  tun0
  192.168.100.0   192.168.100.2   255.255.255.0   UG0 0  0
  tun0
  192.168.4.0 0.0.0.0 255.255.255.0   U 0 0  0
  eth2
  192.168.3.0 0.0.0.0 255.255.255.0   U 0 0  0
  eth0
  192.168.1.0 0.0.0.0 255.255.255.0   U 0 0  0
  eth1
  192.168.29.0192.168.100.2   255.255.255.0   UG0 0  0
  tun0
  0.0.0.0 192.168.1.1 0.0.0.0 UG0 0  0
  eth1
 
  la table de routage coté client est la suivante :
  root@sky:~# netstat -rn
  Table de routage IP du noyau
  Destination Passerelle  Genmask Indic   MSS Fenêtre irtt
  Iface
  0.0.0.0 192.168.29.10.0.0.0 UG0 0  0
  br0
  192.168.1.0 192.168.100.21  255.255.255.0   UG0 0  0
  tun0
  192.168.3.0 192.168.100.21  255.255.255.0   UG0 0  0
  tun0
  192.168.4.0 192.168.100.21  255.255.255.0   UG0 0  0
  tun0
  192.168.29.00.0.0.0 255.255.255.0   U 0 0  0
  br0
  192.168.100.1   192.168.100.21  255.255.255.255 UGH   0 0  0
  tun0
  192.168.100.21  0.0.0.0 255.255.255.255 UH0 0  0
  tun0
 
  Les routes viennent de la configuration openvpn

Re: Pb de routage entre deux sites via openvpn

[Daniel Huhardeaux]

Le 29/08/2014 18:29, Yann Cohen a écrit :

Bonjour,


Bonsoir


[...]

De chaque coté j'ai mis en place un tshark sur l'interface tun0 et un
sur l'interface eth0 ou br0. Objectif suivre les paquets icmp.

Les pings et les pongs depuis le client (sky) vers l'adresse du serveur
(firewall) en .3 passent.

Les pings depuis firewall vers sky sur l'adresse en .29 ne sont pas
envoyés sur tun0 de firewall.

Les pings depuis une machine sur le .29 vers une machine sur le .3,
entrent sur br0 de sky, passent sur tun0 de sky mais ne sortent pas de
tun0 de firewall.

Je sèche sur ce problème depuis un bon paquets d'heures.

Je suppose que le problème est coté serveur (firewall) mais je ne sais
plus où chercher.
[...]


Pour ce que tu veux faire il faut passer par des interfaces tap. En tun 
tu peux le faire, mais il faut rajouter des règles de firewall 
spécifiques aux clients tun, cela devient une usine à gaz.


--
Daniel

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/5400e071.2050...@tootai.net

Re: problème de routage avec 2 interfaces réseau

[Pascal Hambourg]

moi-meme a écrit :
 
 Network-manager a une interface graphique je crois ?
 parce que le ne veux pas de X.

Il a aussi une interface en ligne de commande, nmcli.
L'interface graphique est une option qui ne fait pas partie du paquet de
base network-manager.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/50f14db1.50...@plouf.fr.eu.org

Re: problème de routage avec 2 interfaces réseau

[Max@list]

On 04/01/2013 20:21, moi-meme wrote:
 Le Fri, 04 Jan 2013 19:50:01 +0100, Bernard Schoenacker a écrit :

 Le Fri, 4 Jan 2013 17:55:50 +0100,
 Boiteux Frederic fboit...@prosodie.com a écrit :

 Salut « moi-même »,

   Il est possible d'avoir 2 routes par défaut (ou plus !), une pour
 chaque interface, et de définir une priorité lorsque les deux existent
 (avec la « métrique »), j'ai fait cela sur mon portable pour avoir ce
 genre de config, et je crois que c'est ce que fait également
 network-manager... C'est juste un peu cryptique / peu documenté,
 j'essaierai de te trouver plus d'infos et je le posterai ici...

 Fred.


 -Message d'origine-
 De : robo...@news.nic.it [mailto:robo...@news.nic.it] De la part de
 moi-meme Envoyé : jeudi 3 janvier 2013 19:18 À :
 debian-user-french@lists.debian.org Objet : problème de routage avec 2
 interfaces réseau

 J'ai mon Raspberry avec une Raspbian dedans (je reste en charte).

 J'ai une clé wifi et une RJ45 branchés.

 Les deux séparément fonctionnent sans problème. D'office je suis sur la
 RJ45.
 Si je le débranche je perds la liaison.

 Si je boote avec le Wifi seul c'est lui qui a la route par défaut.

 En fait j'ai un route par défaut qui utilise le RJ45. Une seule route
 par défaut (ce qui semble normal).

 Les deux liaisons sont configurées en IP fixe via
 /etc/network/interface.

 Comment je fais pour garder la liaison en cas de changement de mode ?

 Merci d'avance
 bonjour,

  serait il possible d'obtenir le début du fichier interfaces ?

  normalement il est possible d'activer hotplug pour l'un et 
 l'autre
  ...

  exemple :
  allow-hotplug eth0



  slt
  bernard
 à votre service : 

 auto lo

 iface lo inet loopback
 #iface eth0 inet dhcp
 #iface eth0 inet static
 #address 192.168.10.209
 #netmask 255.255.255.0
 #gateway 192.168.10.10

 allow-hotplug eth0 wlan0
 iface wlan0 inet manual
 wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf

 #iface default inet dhcp
 iface default inet static
 address 192.168.10.208
 netmask 255.255.255.0
 gateway 192.168.10.10

 le wpa_supplicant.conf n'a que des infos WiFi.
 (J'ai désactivé eth0 provisoirement)

 Cerise sur le gâteau avec la même adresse IP quelle que soit l'interface.
 (je rêve peut-être)

Bonjour,

Effectivement j'ai d'abord pensé à jouer avec la métrique (paquet
ifmetric: 
http://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_ifmetric_package)

Mais ce que tu veux faire est en fait du bonding, en clair un failover
entre tes deux interfaces avec une même ip et passerelle, je te laisse
te documenter:
http://wiki.debian.org/Bonding
http://www.debianhelp.co.uk/bonding.htm
...
https://www.google.com/search?q=debian+bonding

En espérant que ça t'aide

Re: problème de routage avec 2 interfaces réseau

[moi-meme]

Le Sat, 05 Jan 2013 00:50:01 +0100, Pascal Hambourg a écrit :

 ifplugd doit pouvoir faire ce genre de chose aussi.

Network-manager a une interface graphique je crois ?
parce que le ne veuxpas ded  X.

je pense que je vais tenter la manip avec ifplugd..

J'ai d'autres trucs à tester avant sur mon Raspberry, je reviendrais dire 
le résultat.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/50e87432$0$6138$426a3...@news.free.fr

Re: problème de routage avec 2 interfaces réseau

[moi-meme]

Le Sat, 05 Jan 2013 00:50:01 +0100, Pascal Hambourg a écrit :

 Boiteux Frederic a écrit :
 
   Il est possible d'avoir 2 routes par défaut (ou plus !), une pour
 chaque interface, et de définir une priorité lorsque les deux existent
 (avec la « métrique »)
 
 Certes, mais la route la moins prioritaire (avec la métrique la plus
 élevée) ne sera utilisée que si la route la plus prioritaire (avec la
 métrique la plus faible) est supprimée. Et pour cela il ne suffit pas de
 débrancher l'interface correspondante, ce qui ne change strictement
 rien à la table de routage : il faut soit désactiver l'interface, soit
 supprimer la route lorsqu'on détecte que la liaison est perdue. C'est ce
 que network manager fait ; ifplugd doit pouvoir faire ce genre de chose
 aussi.

ben j'ai essayé. 
pas probant.

Configuré pour les 2 interfaces  eth0 et wlan0

Le basculement wlan0 - eth0  impeccable.

Dans l'autre sens il faut réactiver wlan0 (ifdown/ifup) et ça ne marche 
pas à tous les coups.

Dans la doc Debian ils ne parlent que de eth0. Cela n'est peut-être pas 
valable pour du WiFi (ce que je constate)

Je vais abandonner la manip : trop de complications pour quelque chose 
qui ne servira quasiment jamais.

Merci pour les conseils.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/50e8a2aa$0$21948$426a3...@news.free.fr

RE: problème de routage avec 2 interfaces réseau

[Boiteux Frederic]

Salut « moi-même »,

  Il est possible d'avoir 2 routes par défaut (ou plus !), une pour chaque 
interface, et de définir une priorité lorsque les deux existent (avec la « 
métrique »), j'ai fait cela sur mon portable pour avoir ce genre de config, et 
je crois que c'est ce que fait également network-manager... C'est juste un peu 
cryptique / peu documenté, j'essaierai de te trouver plus d'infos et je le 
posterai ici...

Fred.

 
-Message d'origine-
De : robo...@news.nic.it [mailto:robo...@news.nic.it] De la part de moi-meme
Envoyé : jeudi 3 janvier 2013 19:18
À : debian-user-french@lists.debian.org
Objet : problème de routage avec 2 interfaces réseau

J'ai mon Raspberry avec une Raspbian dedans (je reste en charte).

J'ai une clé wifi et une RJ45 branchés.

Les deux séparément fonctionnent sans problème.
D'office je suis sur la RJ45.
Si je le débranche je perds la liaison.

Si je boote avec le Wifi seul c'est lui qui a la route par défaut.

En fait j'ai un route par défaut qui utilise le RJ45.
Une seule route par défaut (ce qui semble normal).

Les deux liaisons sont configurées en IP fixe  via /etc/network/interface.

Comment je fais pour garder la liaison en cas de changement de mode ?

Merci d'avance

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/50e5cb40$0$2355$426a7...@news.free.fr

Re: problème de routage avec 2 interfaces réseau

[Bernard Schoenacker]

Le Fri, 4 Jan 2013 17:55:50 +0100,
Boiteux Frederic fboit...@prosodie.com a écrit :

   Salut « moi-même »,
 
   Il est possible d'avoir 2 routes par défaut (ou plus !), une pour
 chaque interface, et de définir une priorité lorsque les deux
 existent (avec la « métrique »), j'ai fait cela sur mon portable pour
 avoir ce genre de config, et je crois que c'est ce que fait également
 network-manager... C'est juste un peu cryptique / peu documenté,
 j'essaierai de te trouver plus d'infos et je le posterai ici...
 
   Fred.
 
  
 -Message d'origine-
 De : robo...@news.nic.it [mailto:robo...@news.nic.it] De la part de
 moi-meme Envoyé : jeudi 3 janvier 2013 19:18
 À : debian-user-french@lists.debian.org
 Objet : problème de routage avec 2 interfaces réseau
 
 J'ai mon Raspberry avec une Raspbian dedans (je reste en charte).
 
 J'ai une clé wifi et une RJ45 branchés.
 
 Les deux séparément fonctionnent sans problème.
 D'office je suis sur la RJ45.
 Si je le débranche je perds la liaison.
 
 Si je boote avec le Wifi seul c'est lui qui a la route par défaut.
 
 En fait j'ai un route par défaut qui utilise le RJ45.
 Une seule route par défaut (ce qui semble normal).
 
 Les deux liaisons sont configurées en IP fixe
 via /etc/network/interface.
 
 Comment je fais pour garder la liaison en cas de changement de mode ?
 
 Merci d'avance

bonjour,

serait il possible d'obtenir le début du fichier interfaces ?

normalement il est possible d'activer hotplug pour l'un et 
l'autre ...

exemple :
allow-hotplug eth0



slt
bernard

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130104194717.6565ca26.bernard.schoenac...@free.fr

Re: problème de routage avec 2 interfaces réseau

[moi-meme]

Le Fri, 04 Jan 2013 19:50:01 +0100, Bernard Schoenacker a écrit :

 Le Fri, 4 Jan 2013 17:55:50 +0100,
 Boiteux Frederic fboit...@prosodie.com a écrit :
 
  Salut « moi-même »,
 
   Il est possible d'avoir 2 routes par défaut (ou plus !), une pour
 chaque interface, et de définir une priorité lorsque les deux existent
 (avec la « métrique »), j'ai fait cela sur mon portable pour avoir ce
 genre de config, et je crois que c'est ce que fait également
 network-manager... C'est juste un peu cryptique / peu documenté,
 j'essaierai de te trouver plus d'infos et je le posterai ici...
 
  Fred.
 
 
 -Message d'origine-
 De : robo...@news.nic.it [mailto:robo...@news.nic.it] De la part de
 moi-meme Envoyé : jeudi 3 janvier 2013 19:18 À :
 debian-user-french@lists.debian.org Objet : problème de routage avec 2
 interfaces réseau
 
 J'ai mon Raspberry avec une Raspbian dedans (je reste en charte).
 
 J'ai une clé wifi et une RJ45 branchés.
 
 Les deux séparément fonctionnent sans problème. D'office je suis sur la
 RJ45.
 Si je le débranche je perds la liaison.
 
 Si je boote avec le Wifi seul c'est lui qui a la route par défaut.
 
 En fait j'ai un route par défaut qui utilise le RJ45. Une seule route
 par défaut (ce qui semble normal).
 
 Les deux liaisons sont configurées en IP fixe via
 /etc/network/interface.
 
 Comment je fais pour garder la liaison en cas de changement de mode ?
 
 Merci d'avance
 
 bonjour,
 
   serait il possible d'obtenir le début du fichier interfaces ?
 
   normalement il est possible d'activer hotplug pour l'un et 
l'autre
   ...
 
   exemple :
   allow-hotplug eth0
 
 
 
   slt
   bernard

à votre service : 

auto lo

iface lo inet loopback
#iface eth0 inet dhcp
#iface eth0 inet static
#address 192.168.10.209
#netmask 255.255.255.0
#gateway 192.168.10.10

allow-hotplug eth0 wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf

#iface default inet dhcp
iface default inet static
address 192.168.10.208
netmask 255.255.255.0
gateway 192.168.10.10

le wpa_supplicant.conf n'a que des infos WiFi.
(J'ai désactivé eth0 provisoirement)

Cerise sur le gâteau avec la même adresse IP quelle que soit l'interface.
(je rêve peut-être)

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/50e72bac$0$1978$426a7...@news.free.fr

Re: problème de routage avec 2 interfaces réseau

[Pascal Hambourg]

Boiteux Frederic a écrit :
 
   Il est possible d'avoir 2 routes par défaut (ou plus !), une pour
 chaque interface, et de définir une priorité lorsque les deux existent
 (avec la « métrique »)

Certes, mais la route la moins prioritaire (avec la métrique la plus
élevée) ne sera utilisée que si la route la plus prioritaire (avec la
métrique la plus faible) est supprimée. Et pour cela il ne suffit pas de
débrancher l'interface correspondante, ce qui ne change strictement
rien à la table de routage : il faut soit désactiver l'interface, soit
supprimer la route lorsqu'on détecte que la liaison est perdue. C'est ce
que network manager fait ; ifplugd doit pouvoir faire ce genre de chose
aussi.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/50e765fa.5000...@plouf.fr.eu.org

problème de routage avec 2 interfaces réseau

[moi-meme]

J'ai mon Raspberry avec une Raspbian dedans (je reste en charte).

J'ai une clé wifi et une RJ45 branchés.

Les deux séparément fonctionnent sans problème.
D'office je suis sur la RJ45.
Si je le débranche je perds la liaison.

Si je boote avec le Wifi seul c'est lui qui a la route par défaut.

En fait j'ai un route par défaut qui utilise le RJ45.
Une seule route par défaut (ce qui semble normal).

Les deux liaisons sont configurées en IP fixe  via /etc/network/interface.

Comment je fais pour garder la liaison en cas de changement de mode ?

Merci d'avance

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/50e5cb40$0$2355$426a7...@news.free.fr

Re: question routage debian

[Anthony Bourguignon]

Le jeudi 05 juillet 2012 à 00:45 +0200, prego jérémy a écrit :
 bonjour,
 
 j'utilise une debian comme routeur pour gérrer mes connexions
 donc pour passer par une connexion ou par l'autre je fais donc des 
 routes avec le paquet du même nom
 
 route add google.fr gw ma_passrelle
 ou
 route add -net netmask-de-google/8 gw ma_passerelle

Pour l'exemple que tu donnes, avec ip route ça donne :
ip route add netmask-de-google/8 via ma_passerelle dev interface_réseau

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/1341475594.1882.4.camel@anthony

question routage debian

[prego jérémy]

bonjour,

j'utilise une debian comme routeur pour gérrer mes connexions
donc pour passer par une connexion ou par l'autre je fais donc des 
routes avec le paquet du même nom


route add google.fr gw ma_passrelle
ou
route add -net netmask-de-google/8 gw ma_passerelle

j'aimerai faire ça avec ip route plutot que route mais je ny suis pas arrivé

mon objectif

créer une table la ça va je sais faire

mettre mes règles   avec ip rull si j'ai bien compris  et faire sortir 
la table vers une passerelle pour que toutes les règles sortent vers la 
passerel pour pas les modifier une par une en cas de panne de connexion



est-ce possible ?

Jérémy

P.S j'arrive avec le jfwmark a obtenir mon résultat mais cela ne me 
conviens pas tout à fait


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4ff4c771.1020...@prego-network.net

Re: [Un peu long] Souci de routage réseau vers une VM Xen 4.0 en squeeze

[François TOURDE]

Le 15370ième jour après Epoch,
Pascal Hambourg écrivait:

 François TOURDE a écrit :
 Pascal Hambourg écrivait:
 
 François TOURDE a écrit :

 Depuis l'intérieur vers le monde extérieur:
 23:31:27.602257 IP 88.191.221.39  88.191.229.82: ICMP echo request, id 
 28933, seq 1, length 64
 23:31:28.601556 IP 88.191.221.39  88.191.229.82: ICMP echo request, id 
 28933, seq 2, length 64
 Sur quelle interface du dom0 ?
 Qu'est-ce que ça donne dans l'autre sens, sur toutes les interfaces ?
 
 Une seule interface sur le Dom0, en tout cas physique.

 Mais il y a bien une interface virtuelle en liaison avec le domU.

Très juste, mais je n'arrive pas à faire un dump de cette interface.

 Faut quand même imaginer la signification du truc :
 - passerelle : tout l'internet est quelque part derrière elle ;
 - pas de passerelle : tout l'internet est directement sur le LAN !

C'est ça. Du coup, pas la peine de gâcher une entrée de routage, c'est
le Dom0 qui va le faire :)

 Pour que tout ça marche, je pense qu'il faut que le dom0 fasse proxy ARP
 sur son interface virtuelle connectée au domU. Est-ce le cas ?
 
 Oui, cf. un peu plus haut.

 Plus haut il était question de l'interface physique.

Très juste, j'ai lu trop vite.

Mais en l'occurence, c'est Xen qui installe et paramètre cette
interface. Je suppose qu'il fait ça bien :)

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/87liomxjd5@fermat.tourde.home

Re: [Un peu long] Souci de routage réseau vers une VM Xen 4.0 en squeeze

[François TOURDE]

Le 15366ième jour après Epoch,
Guillaume écrivait:

 Est ce que tu as bien dans ton fichier /etc/network/interfaces ceci :

 auto eth0
 iface eth0 inet static
   address mon_adresse_ip_failover
   netmask 255.255.255.255
   post-up /sbin/ip route add ADDR_IP_MACHINE_HOTE/32 dev eth0
   post-up /sbin/ip route add default via ADDR_IP_MACHINE_HOTE

J'ai pas tout à fait ça, mais c'est équiv.

 Sinon pourquoi ne pas mettre ton Dom0 en mode bridge (avec MAC
 virtuelle associée a l'ip failover créer dans ta console) ?

Parce que j'ai pas encore essayé le mode bridge, et que j'ai pas envie
de migrer tous mes serveurs comme ça. :)

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/871uqfa8e2@fermat.tourde.home

Re: [Un peu long] Souci de routage réseau vers une VM Xen 4.0 en squeeze

[François TOURDE]

Le 15367ième jour après Epoch,
Pascal Hambourg écrivait:

 Salut,

 François TOURDE a écrit :
 
 Quand je fais un ping du DomU depuis l'extérieur, ça ne réponds
 pas. Quand je le fais depuis le Dom0, ça marche.
 
 Le traceroute s'arrête au Dom0.

 Et dans l'autre sens, du domU vers l'extérieur ?

Idem, pas de réponses.

 Un tcpdump ICMP dans le Dom0 donne par exemple:
 
 Depuis l'intérieur vers le monde extérieur:
 23:31:27.602257 IP 88.191.221.39  88.191.229.82: ICMP echo request, id 
 28933, seq 1, length 64
 23:31:28.601556 IP 88.191.221.39  88.191.229.82: ICMP echo request, id 
 28933, seq 2, length 64

 Sur quelle interface du dom0 ?
 Qu'est-ce que ça donne dans l'autre sens, sur toutes les interfaces ?

Une seule interface sur le Dom0, en tout cas physique. L'autre sens ne
marche pas mieux mais j'ai pas les traces.

 Un tcpdump ARP dans le Dom0 donne par exemple:
 
 23:35:47.264189 ARP, Request who-has 88.191.221.39 tell 88.191.122.1, length 
 46
 23:35:48.056003 ARP, Reply 88.191.221.39 is-at c8:0a:a9:03:35:bf, length 28
 (Le Dom0 indique bien que pour l'IP du DomU, c'est l'adresse MAC du Dom0
 qu'il faut contacter)

 Le dom0 fait proxy ARP sur son interface extérieure ?

Forcément, il est en ip_forwarding.

 La table de routage du DomU est triviale:
 
 Kernel IP routing table
 Destination Gateway Genmask Flags Metric RefUse Iface
 88.191.221.0*   255.255.255.0   U 0  00 eth0
 default *   0.0.0.0 U 0  00 eth0

 Une route par défaut sans adresse de passerelle sur une interface
 ethernet, je n'appelle pas ça trivial.

Bah moi si :) ... Ça signifie quoi que tu aies à dire, fais-le par
l'interface, et pas par une IP.

 Pour que tout ça marche, je pense qu'il faut que le dom0 fasse proxy ARP
 sur son interface virtuelle connectée au domU. Est-ce le cas ?

Oui, cf. un peu plus haut.

 On peut avoir la sortie de ip addr et ip route sur le dom0 et le domU
 ?

Pas là, je suis en train de tout basculer sur une nouvelle machine, il
semblerait que le souci vienne de Dedibox, avec un routeur CISCO qui a
besoin qu'on réinitialise le routage, et des fois ça marche, des fois
pas :(

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/87wr878tlx@fermat.tourde.home

Re: [Un peu long] Souci de routage réseau vers une VM Xen 4.0 en squeeze

[Pascal Hambourg]

François TOURDE a écrit :
 Pascal Hambourg écrivait:
 
 François TOURDE a écrit :

 Depuis l'intérieur vers le monde extérieur:
 23:31:27.602257 IP 88.191.221.39  88.191.229.82: ICMP echo request, id 
 28933, seq 1, length 64
 23:31:28.601556 IP 88.191.221.39  88.191.229.82: ICMP echo request, id 
 28933, seq 2, length 64
 Sur quelle interface du dom0 ?
 Qu'est-ce que ça donne dans l'autre sens, sur toutes les interfaces ?
 
 Une seule interface sur le Dom0, en tout cas physique.

Mais il y a bien une interface virtuelle en liaison avec le domU.

 Le dom0 fait proxy ARP sur son interface extérieure ?
 
 Forcément, il est en ip_forwarding.
 
 La table de routage du DomU est triviale:

 Kernel IP routing table
 Destination Gateway Genmask Flags Metric RefUse 
 Iface
 88.191.221.0*   255.255.255.0   U 0  00 eth0
 default *   0.0.0.0 U 0  00 eth0
 Une route par défaut sans adresse de passerelle sur une interface
 ethernet, je n'appelle pas ça trivial.
 
 Bah moi si :) ... Ça signifie quoi que tu aies à dire, fais-le par
 l'interface, et pas par une IP.

Faut quand même imaginer la signification du truc :
- passerelle : tout l'internet est quelque part derrière elle ;
- pas de passerelle : tout l'internet est directement sur le LAN !

 Pour que tout ça marche, je pense qu'il faut que le dom0 fasse proxy ARP
 sur son interface virtuelle connectée au domU. Est-ce le cas ?
 
 Oui, cf. un peu plus haut.

Plus haut il était question de l'interface physique.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4f285c91.5080...@plouf.fr.eu.org

Re: [Un peu long] Souci de routage réseau vers une VM Xen 4.0 en squeeze

[Pascal Hambourg]

Salut,

François TOURDE a écrit :
 
 Quand je fais un ping du DomU depuis l'extérieur, ça ne réponds
 pas. Quand je le fais depuis le Dom0, ça marche.
 
 Le traceroute s'arrête au Dom0.

Et dans l'autre sens, du domU vers l'extérieur ?

 Un tcpdump ICMP dans le Dom0 donne par exemple:
 
 Depuis l'intérieur vers le monde extérieur:
 23:31:27.602257 IP 88.191.221.39  88.191.229.82: ICMP echo request, id 
 28933, seq 1, length 64
 23:31:28.601556 IP 88.191.221.39  88.191.229.82: ICMP echo request, id 
 28933, seq 2, length 64

Sur quelle interface du dom0 ?
Qu'est-ce que ça donne dans l'autre sens, sur toutes les interfaces ?

 Un tcpdump ARP dans le Dom0 donne par exemple:
 
 23:35:47.264189 ARP, Request who-has 88.191.221.39 tell 88.191.122.1, length 
 46
 23:35:48.056003 ARP, Reply 88.191.221.39 is-at c8:0a:a9:03:35:bf, length 28
 (Le Dom0 indique bien que pour l'IP du DomU, c'est l'adresse MAC du Dom0
 qu'il faut contacter)

Le dom0 fait proxy ARP sur son interface extérieure ?

 La table de routage du DomU est triviale:
 
 Kernel IP routing table
 Destination Gateway Genmask Flags Metric RefUse Iface
 88.191.221.0*   255.255.255.0   U 0  00 eth0
 default *   0.0.0.0 U 0  00 eth0

Une route par défaut sans adresse de passerelle sur une interface
ethernet, je n'appelle pas ça trivial.
Pour que tout ça marche, je pense qu'il faut que le dom0 fasse proxy ARP
sur son interface virtuelle connectée au domU. Est-ce le cas ?

On peut avoir la sortie de ip addr et ip route sur le dom0 et le domU ?

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4f23bfde@plouf.fr.eu.org

Re: [Un peu long] Souci de routage réseau vers une VM Xen 4.0 en squeeze

[François TOURDE]

Le 15366ième jour après Epoch,
Guillaume écrivait:

 Le 26/01/2012 23:45, François TOURDE a écrit :
 Salut la liste.

 J'ai un souci que je ne sais par quel bout prendre...
[...]

 Bonjour,

 ton dom0 est en mode bridge ou en mode routed ?

En mode routed. J'ai oublié de préciser, désolé.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/87ipjxec4v@fermat.tourde.home

Re: [Un peu long] Souci de routage réseau vers une VM Xen 4.0 en squeeze

[Guillaume]

Le 27/01/2012 10:19, François TOURDE a écrit :


En mode routed. J'ai oublié de préciser, désolé.



Est ce que tu as bien dans ton fichier /etc/network/interfaces ceci :

auto eth0
iface eth0 inet static
address mon_adresse_ip_failover
netmask 255.255.255.255
post-up /sbin/ip route add ADDR_IP_MACHINE_HOTE/32 dev eth0
post-up /sbin/ip route add default via ADDR_IP_MACHINE_HOTE

Sinon pourquoi ne pas mettre ton Dom0 en mode bridge (avec MAC virtuelle 
associée a l'ip failover créer dans ta console) ?



Guillaume

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4f228ac1.6030...@gwilhom.fr

[Un peu long] Souci de routage réseau vers une VM Xen 4.0 en squeeze

[François TOURDE]

Salut la liste.

J'ai un souci que je ne sais par quel bout prendre...

Le contexte:

Un serveur Dedibox noyau 2.6.32-5-xen-amd64, dans laquelle j'ai un DomU
2.6.32-5-amd64 mais sans les modules (j'explique après).

Quand je fais un ping du DomU depuis l'extérieur, ça ne réponds
pas. Quand je le fais depuis le Dom0, ça marche.

Le traceroute s'arrête au Dom0.

Ce n'est pas les seuls Dom0/DomU dans ce cas de figure, mais tous les
autres fonctionnent correctement.

Quelques détails:

Le DomU était en Lenny dans un Dom0 Lenny aussi. Je le migre dans un
Dom0 qui est Squeeze, du coup le fichier de config xen pointe sur un
noyau 2.6.32 mais celui-ci n'est pas encore installé dans le DomU. C'est
pour ça que les modules ne sont pas encore présents.

J'ai réalisé cette procédure plus de 10 fois depuis le début de mes
migrations, mais avec CE DomU dans CE Dom0, ça ne marche pas.

Un tcpdump ICMP dans le Dom0 donne par exemple:

Depuis l'intérieur vers le monde extérieur:
23:31:27.602257 IP 88.191.221.39  88.191.229.82: ICMP echo request, id 28933, 
seq 1, length 64
23:31:28.601556 IP 88.191.221.39  88.191.229.82: ICMP echo request, id 28933, 
seq 2, length 64

Depuis l'extérieur vers le Dom0
23:31:39.474844 IP 62.147.184.98  88.191.122.173: ICMP echo request, id 28039, 
seq 1, length 64
23:31:39.474917 IP 88.191.122.173  62.147.184.98: ICMP echo reply, id 28039, 
seq 1, length 64
23:31:40.478253 IP 62.147.184.98  88.191.122.173: ICMP echo request, id 28039, 
seq 2, length 64
23:31:40.478300 IP 88.191.122.173  62.147.184.98: ICMP echo reply, id 28039, 
seq 2, length 64

Un tcpdump ARP dans le Dom0 donne par exemple:

23:35:47.264189 ARP, Request who-has 88.191.221.39 tell 88.191.122.1, length 46
23:35:48.056003 ARP, Reply 88.191.221.39 is-at c8:0a:a9:03:35:bf, length 28
(Le Dom0 indique bien que pour l'IP du DomU, c'est l'adresse MAC du Dom0
qu'il faut contacter)

La table de routage du DomU est triviale:

Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
88.191.221.0*   255.255.255.0   U 0  00 eth0
default *   0.0.0.0 U 0  00 eth0

L'IP forwarding du Dom0 est bien en place:

root@srv06:~# cat /proc/sys/net/ipv4/ip_forward
1

Je ne sais plus où regarder. Si une âme généreuse peut ne serait-ce que
m'aiguiller un peu, j'avoue que ça m'aiderai pas mal :)

Merci d'avoir lu jusque là.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/87mx9adqwz@fermat.tourde.home

Re: [Un peu long] Souci de routage réseau vers une VM Xen 4.0 en squeeze

[Guillaume]

Le 26/01/2012 23:45, François TOURDE a écrit :

Salut la liste.

J'ai un souci que je ne sais par quel bout prendre...

Le contexte:

Un serveur Dedibox noyau 2.6.32-5-xen-amd64, dans laquelle j'ai un DomU
2.6.32-5-amd64 mais sans les modules (j'explique après).

Quand je fais un ping du DomU depuis l'extérieur, ça ne réponds
pas. Quand je le fais depuis le Dom0, ça marche.

Le traceroute s'arrête au Dom0.

Ce n'est pas les seuls Dom0/DomU dans ce cas de figure, mais tous les
autres fonctionnent correctement.

Quelques détails:

Le DomU était en Lenny dans un Dom0 Lenny aussi. Je le migre dans un
Dom0 qui est Squeeze, du coup le fichier de config xen pointe sur un
noyau 2.6.32 mais celui-ci n'est pas encore installé dans le DomU. C'est
pour ça que les modules ne sont pas encore présents.

J'ai réalisé cette procédure plus de 10 fois depuis le début de mes
migrations, mais avec CE DomU dans CE Dom0, ça ne marche pas.

Un tcpdump ICMP dans le Dom0 donne par exemple:

Depuis l'intérieur vers le monde extérieur:
23:31:27.602257 IP 88.191.221.39  88.191.229.82: ICMP echo request, id 28933, 
seq 1, length 64
23:31:28.601556 IP 88.191.221.39  88.191.229.82: ICMP echo request, id 28933, 
seq 2, length 64

Depuis l'extérieur vers le Dom0
23:31:39.474844 IP 62.147.184.98  88.191.122.173: ICMP echo request, id 28039, 
seq 1, length 64
23:31:39.474917 IP 88.191.122.173  62.147.184.98: ICMP echo reply, id 28039, 
seq 1, length 64
23:31:40.478253 IP 62.147.184.98  88.191.122.173: ICMP echo request, id 28039, 
seq 2, length 64
23:31:40.478300 IP 88.191.122.173  62.147.184.98: ICMP echo reply, id 28039, 
seq 2, length 64

Un tcpdump ARP dans le Dom0 donne par exemple:

23:35:47.264189 ARP, Request who-has 88.191.221.39 tell 88.191.122.1, length 46
23:35:48.056003 ARP, Reply 88.191.221.39 is-at c8:0a:a9:03:35:bf, length 28
(Le Dom0 indique bien que pour l'IP du DomU, c'est l'adresse MAC du Dom0
qu'il faut contacter)

La table de routage du DomU est triviale:

Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
88.191.221.0*   255.255.255.0   U 0  00 eth0
default *   0.0.0.0 U 0  00 eth0

L'IP forwarding du Dom0 est bien en place:

root@srv06:~# cat /proc/sys/net/ipv4/ip_forward
1

Je ne sais plus où regarder. Si une âme généreuse peut ne serait-ce que
m'aiguiller un peu, j'avoue que ça m'aiderai pas mal :)

Merci d'avoir lu jusque là.




Bonjour,

ton dom0 est en mode bridge ou en mode routed ?

---

Guillaume

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4f21f899.5050...@gwilhom.fr

HS résolu Re: réseau static routage vers passerelle non automatique

[Raphaël POITEVIN]

Bonjour,
Le 13/04/11, David Dumortierd.dumort...@free.fr a écrit :
 gateway

Merci, voilà qui est parfait. J'avais pourtant lu le tutoriel (trop
rapidement), mais comme dans les quelques cours de réseau que j'ai eu,
on prononçait mal l'anglais en disant gate away, j'ai toujours pensé
cette combinaison de ces deux mots, au lieu de penser gate way.

Raphaël

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
http://lists.debian.org/BANLkTi
pv3eoht9ypyebjljnzmehf...@mail.gmail.com

Re: réseau static routage vers passerelle non automatique

[Pierre Meurisse]

Bonjour,

On Wed, Apr 13, 2011 at 01:42:05PM +0200, Raphaël POITEVIN wrote:
...
   adress 192.168.100.6

address

Cordialement.

-- 
Pierre Meurisse

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20110414084327.GA3957@asusqueeze.bureau.maison

réseau static routage vers passerelle non automatique

[Raphaël POITEVIN]

Bonjour,

Sur un ordinateur squeeze qui servira de serveur, j'ai configuré le
réseau en static. Tout à l'air de fonctionner, sauf que le routage
vers la passerelle n'est pas dans la table de routage. La solution
trouvée est de mettre la comande route add au démarrage, dans le
rc.local par exemple. Mais à mon sens ce n'est pas très catholique.

Quelquu'n a-t-il une idée sur le fait que la table de routage ne définisse
pas le routage de n'importe quelle adresse vers la passerelle ?

Voici globalement mon fichier /etc/network/interfaces
allow-hotplug eth0
iface eth0 inet static
  adress 192.168.100.6
  netmask 255.25.255.0
  gateaway 192.168.100.155
  broadcast 192.168.100.255
  dns-domain mon domaine
  dns-search mon domaine
  dns-nameservers 192.168.100.5

Bien cordialement,
-- 
Raphaël POITEVIN

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktink5r0ukyb5pg22cmrq1x71skl...@mail.gmail.com

Re: réseau static routage vers passerelle non automatique

[David Dumortier]

Bonjour,

Le mer. avril 13 2011 � 01:42:05 +0200, Raphaël POITEVIN dit :
 Bonjour,
 
 Sur un ordinateur squeeze qui servira de serveur, j'ai configuré le
 réseau en static. Tout à l'air de fonctionner, sauf que le routage
 vers la passerelle n'est pas dans la table de routage. La solution
 trouvée est de mettre la comande route add au démarrage, dans le
 rc.local par exemple. Mais à mon sens ce n'est pas très catholique.
 
 Quelquu'n a-t-il une idée sur le fait que la table de routage ne définisse
 pas le routage de n'importe quelle adresse vers la passerelle ?
 
 Voici globalement mon fichier /etc/network/interfaces
 allow-hotplug eth0
 iface eth0 inet static
   adress 192.168.100.6
   netmask 255.25.255.0
   gateaway 192.168.100.155

gateway

   broadcast 192.168.100.255
   dns-domain mon domaine
   dns-search mon domaine
   dns-nameservers 192.168.100.5
 
 Bien cordialement,

De même

 -- 
 Raphaël POITEVIN

-- 
David Dumortier

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20110413115430.gd28...@nowhere.eden

routage statique sous debian

[Tahar BEN ACHOUR]

Bonjour à tous,

Je vais changer une machine redhat par une machine debian, sur cette machine 
j'ai deux cartes réseaux avec deux routes différentes, la route par défaut 
d'une part et deux routes statiques sur la seconde carte pour lesquelles je 
voudrais qu'elles chargent même en redémarrant la machine.


Sous redhat, il fallait créer un fichier dans 
/etc/sysconfig/network-scripts/route-ethX

et mettre dedans des infos de la sorte 

more /etc/sysconfig/network-scripts/route-eth0 
193.95.92.0/24 via 193.95.93.1
41.224.255.158 via 193.95.93.1


Comment faire sous Debian ? est ce que les routes statiques sont ajoutée dans 
/etc/network/interfaces ?

Merci pour votre aide





--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/463048.98950...@web26304.mail.ukl.yahoo.com

RE: routage statique sous debian

[Frédéric PARIS]

Il suffit simplement de rajouter à la fin de ton fichier 
/etc/network/interfaces (pour reprendre ton exemple) :

# Routes statiques
up route add -net 193.95.92.0 netmask 255.255.255.0 gw 193.95.93.1
up route add default gw 193.95.93.1 




-Message d'origine-
De : Tahar BEN ACHOUR [mailto:tahar...@yahoo.fr] 
Envoyé : mardi 22 juin 2010 11:16
À : DEBIAN
Objet : routage statique sous debian

Bonjour à tous,

Je vais changer une machine redhat par une machine debian, sur cette machine 
j'ai deux cartes réseaux avec deux routes différentes, la route par défaut 
d'une part et deux routes statiques sur la seconde carte pour lesquelles je 
voudrais qu'elles chargent même en redémarrant la machine.


Sous redhat, il fallait créer un fichier dans 
/etc/sysconfig/network-scripts/route-ethX

et mettre dedans des infos de la sorte 

more /etc/sysconfig/network-scripts/route-eth0 
193.95.92.0/24 via 193.95.93.1
41.224.255.158 via 193.95.93.1


Comment faire sous Debian ? est ce que les routes statiques sont ajoutée dans 
/etc/network/interfaces ?

Merci pour votre aide



  

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/463048.98950...@web26304.mail.ukl.yahoo.com

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
http://lists.debian.org/40af361de242e947a20ea39f5c3a679ea5a...@voimsg01.antemeta.net

Re : routage statique sous debian

[Tahar BEN ACHOUR]

 Il suffit simplement de rajouter à la fin de ton fichier 
 /etc/network/interfaces 
 (pour reprendre ton exemple) :

# Routes statiques
up route add -net 
 193.95.92.0 netmask 255.255.255.0 gw 193.95.93.1
up route add default gw 
 193.95.93.1 


Merci beaucoup pour ton aide.





--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/615301.22196...@web26305.mail.ukl.yahoo.com

Re: routage statique sous debian

[Jean-Michel OLTRA]

Bonjour,


Le mardi 22 juin 2010, Frédéric PARIS a écrit...


 Il suffit simplement de rajouter à la fin de ton fichier 
 /etc/network/interfaces (pour reprendre ton exemple) :

 # Routes statiques
 up route add -net 193.95.92.0 netmask 255.255.255.0 gw 193.95.93.1
 up route add default gw 193.95.93.1 

Pourquoi ne pas utiliser les possibilités de /etc/network/if-pre-up.d/,
ou (if-up.d/), plutôt que de charger le fichier interfaces ?

-- 
jm

A.E.L. Sarl (R.C.S CASTRES 490843240)
http://www.spidboutic.fr



-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20100622093242.gb14...@espinasse

Re : routage statique sous debian

[Tahar BEN ACHOUR]

 

Bonjour,
Bonjour

Le mardi 22 juin 2010, Frédéric PARIS a 
 écrit...


 Il suffit simplement de rajouter à la fin de ton 
 fichier /etc/network/interfaces (pour reprendre ton exemple) :

 # 
 Routes statiques
 up route add -net 193.95.92.0 netmask 255.255.255.0 gw 
 193.95.93.1
 up route add default gw 193.95.93.1 

Pourquoi ne pas 
 utiliser les possibilités de /etc/network/if-pre-up.d/,
ou (if-up.d/), plutôt 
 que de charger le fichier interfaces ?

Comment configurer /etc/network/if-pre-up.d  ? je mets un fichier texte avec ma 
route dedans ? 

Merci 





--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/334642.24770...@web26303.mail.ukl.yahoo.com

Re: routage statique sous debian

[Stephane Bortzmeyer]

On Tue, Jun 22, 2010 at 10:34:40AM +,
 Tahar BEN ACHOUR tahar...@yahoo.fr wrote 
 a message of 18 lines which said:

  up route add -net 193.95.92.0 netmask 255.255.255.0 gw 
  193.95.93.1
  up route add default gw 193.95.93.1 

 Comment configurer /etc/network/if-pre-up.d ?  je mets un fichier
 texte avec ma route dedans ?

Ah non, ce sont des scripts shell donc, par exemple :

% cat /etc/network/if-pre-up.d/ma-route.sh
#!/bin/sh

route add default gw 193.95.93.1 

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20100622115848.ga2...@sources.org

Re: routage statique sous debian

[Frédéric Boiteux]

Le Tue, 22 Jun 2010 11:32:42 +0200,
Jean-Michel OLTRA jm.oltra.antis...@espinasse.net a écrit :

 
 Bonjour,
 
 
 Le mardi 22 juin 2010, Frédéric PARIS a écrit...
 
 
  Il suffit simplement de rajouter à la fin de ton
  fichier /etc/network/interfaces (pour reprendre ton exemple) :
 
  # Routes statiques
  up route add -net 193.95.92.0 netmask 255.255.255.0 gw 193.95.93.1
  up route add default gw 193.95.93.1 
 
 Pourquoi ne pas utiliser les possibilités
 de /etc/network/if-pre-up.d/, ou (if-up.d/), plutôt que de charger le
 fichier interfaces ?

Ce sera plus propre de le mettre dans le fichier « interfaces », pour
la *bonne* interface, plutôt que dans un script
de /etc/network/ip-pre-up.d, qui lui sera lancé pour chaque interface
montée, ce qui risque de rajouter des routes sur de mauvaises
interfaces (genre « lo », « wlan0 », etc.)

Fred.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20100622141656.244e8...@prem1s.lanvoc

Re: routage statique sous debian

[Jean-Michel OLTRA]

Bonjour,


Le mardi 22 juin 2010, Frédéric Boiteux a écrit...


  Pourquoi ne pas utiliser les possibilités
  de /etc/network/if-pre-up.d/, ou (if-up.d/), plutôt que de charger le
  fichier interfaces ?

 Ce sera plus propre de le mettre dans le fichier « interfaces », pour
 la *bonne* interface, plutôt que dans un script
 de /etc/network/ip-pre-up.d, qui lui sera lancé pour chaque interface
 montée, ce qui risque de rajouter des routes sur de mauvaises
 interfaces (genre « lo », « wlan0 », etc.)

Que nenni ! J'utilise une structure case...esac pour tester l'interface

case ${LOGICAL} in

iface1)
faire les trucs sur iface1
;;

*)
;;
esac

man interfaces pour les variables accessibles dans ces scripts
executables.

Et, par ailleurs, je ne suis pas bien sûr qu'une extension en .sh soit
permise là dedans. Je n'en mets pas, et il y a peut-être une raison…mais
je ne me rappelle plus si j'ai testé avec extension.

-- 
jm

A.E.L. Sarl (R.C.S CASTRES 490843240)
http://www.spidboutic.fr



-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20100622124940.gd14...@espinasse

Re: routage statique sous debian

[Frédéric Boiteux]

Le Tue, 22 Jun 2010 14:49:40 +0200,
Jean-Michel OLTRA jm.oltra.antis...@espinasse.net a écrit :


 Que nenni ! J'utilise une structure case...esac pour tester
 l'interface
 

Ok, mais je ne vois pas l'intérêt de remplacer une ligne dans le bon
fichier pour la remplacer par un script de 10 lignes moins visible…

  Chacun ses goûts
Fred.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20100622145232.49d25...@prem1s.lanvoc

Re: routage statique sous debian

[Pascal Hambourg]

Jean-Michel OLTRA a écrit :
 
 Pourquoi ne pas utiliser les possibilités
 de /etc/network/if-pre-up.d/, ou (if-up.d/), plutôt que de charger le
 fichier interfaces ?
 
 Ce sera plus propre de le mettre dans le fichier « interfaces », pour
 la *bonne* interface, plutôt que dans un script
 de /etc/network/ip-pre-up.d, qui lui sera lancé pour chaque interface
 montée, ce qui risque de rajouter des routes sur de mauvaises
 interfaces (genre « lo », « wlan0 », etc.)

Je suis bien d'accord. Ces scripts ont vocation à être génériques ou
spécifiques à un type d'interface (pare-feu, resolvconf, bridge,
VLAN...) et non spécifiques à une interface donnée.

 Que nenni ! J'utilise une structure case...esac pour tester l'interface

C'est bien ce qu'écrivait Frédéric : ça complique puisqu'il faut
rajouter un test et c'est moins lisible puisqu'il faut fouiller dans les
répertoires if-*.d/ en plus du fichier interfaces. Aucun intérêt.

 Et, par ailleurs, je ne suis pas bien sûr qu'une extension en .sh soit
 permise là dedans. Je n'en mets pas, et il y a peut-être une raison mais
 je ne me rappelle plus si j'ai testé avec extension.

Peut-être à cause des restriction de run-parts par l'intermédiaire
duquel ces scripts sont exécutés si je ne m'abuse.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4c20c962.2030...@plouf.fr.eu.org

Re: Pb cohabitation Routage / Bridge avec VirtualBox OSE

[Pascal Hambourg]

Salut,

Pierre a écrit :
 
 Sur une Debian, je fais du routage entre 2 interfaces réseau d'une part 
 (192.168.101.0  192.168.55.0), et d'autre part le serveur abrite 
 VirtualBox OSE pour faire tourner une VM Windows (XP), qui doit être 
 dans le réseau (donc pas de NAT); j'utilise donc la solution du bridge.
 Le problème, c'est que dès que je monte le bridge, je perds le routage.
 Concrètement, j'ai un client 192.168.55.10 qui pingue le 192.168.101.200 
 (routeur), le routage entre les 2 interfaces du serveur 
 (192.168.55.1(eth1)  192.168.101.25 (eth0)) se fait donc bien.
 Dès que j'associe le bridge à eth0 (ou eth1), le ping ne passe plus...

Une interface associée à un pont ne doit pas avoir de configuration IP,
donc pas d'adresse IP ni de route (sauf dans un cas très particulier
appelé pont-routeur avec utilisation de la table broute d'ebtables,
qui est différent de ce que tu veux faire). Seul le pont peut en avoir.
En gros les interfaces d'un pont disparaissent. Donc si par exemple on
veut ponter eth0 dans br0, alors br0 doit remplacer eth0 pour tout ce
qui concerne la configuration IP.

L'explication est que même si une interface pontée peut toujours émettre
des paquets pour son propre compte, tout paquet reçu par elle est
intercepté et vu comme reçu par le pont et non par l'interface.
Résultat, les réponses aux requêtes ARP n'arrivent pas sur la bonne
interface et la résolution ARP ne peut plus aboutir, toute route
associée à cette interface devient défectueuse.

 allow-hotplug eth0
 iface eth0 inet dhcp

A supprimer puisque eth0 va être pontée.

 # Interface pour le réseau local
 allow-hotplug eth1
 iface eth1 inet static
address 192.168.55.1
netmask 255.255.255.0
broadcast 192.168.55.255
network 192.168.55.0
gateway 192.168.55.1

- Pas d'option gateway sur une interface qui n'est pas connectée à un
routeur.
- Une machine ne peut pas être sa propre passerelle (une passerelle est
un next hop, et une machine ne peut évidemment pas être son propre
next hop).
- Une seule passerelle par défaut active sur une machine, quel que soit
le nombre d'interfaces actives (à moins de savoir exactement ce qu'on fait).

 auto br0
 iface br0 inet dhcp
 bridge_ports eth0

Je rajouterais une option bridge_fd pour régler le délai d'ouverture du
pont à une valeur plus basse que la valeur par défaut de 30 seconde,
afin d'éviter un time-out du client DHCP.

A noter que l'association d'une autre interface dans le pont pourrait
modifier l'adresse MAC de celui-ci (par défaut un pont prend la plus
petite des adresses MAC des ses interfaces), ce qui pourrait perturber
le fonctionnement du DHCP.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Pb cohabitation Routage / Bridge avec VirtualBox OSE

[Pierre]

Bonjour à tous,

Sur une Debian, je fais du routage entre 2 interfaces réseau d'une part 
(192.168.101.0  192.168.55.0), et d'autre part le serveur abrite 
VirtualBox OSE pour faire tourner une VM Windows (XP), qui doit être 
dans le réseau (donc pas de NAT); j'utilise donc la solution du bridge.

Le problème, c'est que dès que je monte le bridge, je perds le routage.
Concrètement, j'ai un client 192.168.55.10 qui pingue le 192.168.101.200 
(routeur), le routage entre les 2 interfaces du serveur 
(192.168.55.1(eth1)  192.168.101.25 (eth0)) se fait donc bien.

Dès que j'associe le bridge à eth0 (ou eth1), le ping ne passe plus...
J'ai essayé de retourner le pb dans tous les sens... (entre autres en 
regardant de plus près les commandes brctl). Là je ne sais plus (Bon! je 
ne suis pas non plus un crack!!).

Si vous avez des idées, elles seraient plus que bienvenues...

Merci d'avance,

Ci-joint /etc/network/interfaces :
auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet dhcp

# Interface pour le réseau local
allow-hotplug eth1
iface eth1 inet static
  address 192.168.55.1
  netmask 255.255.255.0
  broadcast 192.168.55.255
  network 192.168.55.0
  gateway 192.168.55.1

auto br0
iface br0 inet dhcp
bridge_ports eth0


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: Pb de routage/DHCP

[Pierre]

Merci pour cette réponse.
J'ai bien répercuté la modif, mais sans succès.
Mais  ip route list me donne bien default via 192.168.1.254 dev eth0.

Du PC Windows, je parviens à pinguer:
 - l'interface 192.168.50.1 (eth0 du Serveur Debian)
 - l'interface 192.168.1.4 (eth1 du Serveur Debian)
donc le routage semble fonctionner...
mais pas 192.168.1.254 (interface réseau du routeur) ???

Sinon faut-il vraiment passer par le NAT, est-ce compliqué à faire ?

Merci d'avance pour vos lumières, parce que là, je suis dans la pénombre...


 Pierre a écrit :
 Bonjour à tous,
 Bonjour
 [...]
 subnet 192.168.50.0 netmask 255.255.255.0 {
   range 192.168.50.10 192.168.50.50;
   option routers 192.168.1.254;
 Faux. option routers 192.168.50.1

   option broadcast-address 192.168.50.255;
   authoritative;
 }

 sur ton routeur local (ta Debian) tu dois avoir

 #$ ip route list

 ...
 default via 192.168.1.254 dev eth0

 Tes clients du réseau 192.168.50.x passent par la passerelle
 192.168.50.1 -interface eth1- qui elle voit que le paquet n'est pas
 pour elle et l'envoi vers le 192.168.1.254 via l'interface eth0
 --
 Daniel

 --
 Lisez la FAQ de la liste avant de poser une question :
 http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
 ``spam'' dans vos champs From et Reply-To:

 Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
 vers debian-user-french-requ...@lists.debian.org
 En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org






-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: Pb de routage/DHCP

[Daniel Huhardeaux]

Bonjour

Pierre a écrit :

Merci pour cette réponse.
J'ai bien répercuté la modif, mais sans succès.
Mais  ip route list me donne bien default via 192.168.1.254 dev eth0.

Du PC Windows, je parviens à pinguer:
 - l'interface 192.168.50.1 (eth0 du Serveur Debian)
 - l'interface 192.168.1.4 (eth1 du Serveur Debian)
donc le routage semble fonctionner...
mais pas 192.168.1.254 (interface réseau du routeur) ???

Sinon faut-il vraiment passer par le NAT, est-ce compliqué à faire ?

Merci d'avance pour vos lumières, parce que là, je suis dans la pénombre...
  

/sbin/iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Auparavant activer le forward:

echo 1  /proc/sys/net/ipv4/ip_forward
echo 1  /proc/sys/net/ipv4/ip_dynaddr

--
Daniel

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

routage interne selon (sous-) domaine demandé [ était : Re: haproxy 1.3.15.2 : en mode transparent pour garder ip visiteur]

[Grégory Bulot]

Suite aux différentes réponses sur haproxy, je formule ma demande
différemment :

sois plusieurs domaines ayant des sous domaine

- toto.com : www.toto.com, blog.toto.com, (liste non finie)
- titi.com : www.titi.com, joomla.titi.com, boutique.titi.com (liste
non finie)

- J'ai une seule ip publique (adsl)
- J'ai un routeur (ipcop), avec squid en proxy actif
- dans mon lan j'ai 1 serveur (tank) apache en prod avec des
virtualhosts
- dans mon lan j'ai 1 serveur (dozer, en openvz) qui recevra une
partie des sites ci-dessus (dans un premier temps) aussi en virtualhost
apache (je sais pas encore si je bouge un domaine entier, ou seulement
du www, ou boutique ou ...

actuellement haproxy (qui est dans un vps de dozer) répond au besoin
apparent ci-dessus, a part l'ip du client qui est substituée par l'ip de
haproxy

existe-t-il une solution (clef-en-main-pour-les-gros-fainéants ou
proche).

Je souhaiterais mettre de côté le mod-proxy apache dans
les virtualhost concerné : 
proxypass /suiteUrl/ http://192.168.1.205/
proxypassreverse /suiteUrl/ http://192.168.1.205/

 parceque !

slowloris, mais pas que !

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: routage interne selon (sous-) domaine demandé [ était : Re: haproxy 1.3.15.2 : en mode tran sparent pour garder ip visiteur]

[Daniel Huhardeaux]

Grégory Bulot a écrit :

Suite aux différentes réponses sur haproxy, je formule ma demande
différemment :
  

[...]

aptitude install pound

--
Daniel

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: Pb de routage/DHCP

[Stephane Bortzmeyer]

On Sat, Nov 28, 2009 at 11:58:47AM +0100,
 Alex Perso a...@rendour.org wrote 
 a message of 38 lines which said:

 Fait des ping en utilisant les ips (exemple ip des dns de ton fai)
 plutot que les noms.

Et, comme c'est un problème de routage, il faut plutôt utiliser
traceroute que ping.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: Pb de routage/DHCP

[Stephane Bortzmeyer]

On Sat, Nov 28, 2009 at 11:49:40AM +0100,
 Pierre ph...@laposte.net wrote 
 a message of 72 lines which said:

 Je dois relier un réseau 192.168.50.0 (local) à un réseau
 192.168.1.0 (vers routeur opérateur).

Comme indiqué par Alex Perso, ces adresses étant des adresses privées,
il faudra probablement activer la traduction d'adresses sur le routeur
:-(

 demande donc s'il s'agit d'un problème DHCP (passerelle?) ou d'un
 problème DNS (Résolution de nom?), ou les deux...

Ni l'un, ni l'autre, c'est un problème de routage IP.

 geo.localIN SOA
 servgeo.geo.local. admg...@geo.local. (

Mauvaise idée d'utiliser .local 
http://www.bortzmeyer.org/pourquoi-le-tld-local-n-est-pas-une-bonne-idee.html.
 

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: routage interne selon (sous-) domaine demandé [ était : Re: haproxy 1.3.15.2 : en mode transparent pour garder ip visiteur]

[Grégory Bulot]

Daniel Huhardeaux no-s...@tootai.net à écrit le Sun, 29 Nov 2009
16:53:31 +0100
 Grégory Bulot a écrit :
  Suite aux différentes réponses sur haproxy, je formule ma demande
  différemment :

 [...]
 
 aptitude install pound

A la lecture de http://packages.debian.org/lenny/pound c'est alléchant !
pourquoi ne pas me l'avoir avant que je pose la question :-D


en lisant http://www.apsis.ch/pound/ visiblement la demande est
sensible pour la gestion des sous domaines, car il y a un paragraphe
dédié, mais l'auteur précise que ce n'est pas le travail de pound, mais
que ce produit en est capable

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Pb de routage/DHCP

[Pierre]

Bonjour à tous,

Je dois relier un réseau 192.168.50.0 (local) à un réseau 192.168.1.0 
(vers routeur opérateur).
J'utilise donc un serveur Debian qui doit remplir les fonctions de 
routeur, seveur DNS et DHCP, et qui comprend 2 cartes réseau :
 - eth1 : 192.168.50.1 qui est reliée sur un switch sur lequel se 
trouvent des clients Windows
 - eth0 : 192.168.1.1 qui est reliée au routeur de l'opérateur 
(192.168.1.254)
J'ai bien effectué le 'echo 1 /proc/net/ip_v4/forward', et quand je 
fais un cat, je récupère bien un '1'.

J'ai bien spécifié 'Interfaces=eth1' dans /etc/default/dhcp3-server.
Le problème c'est que les clients DHCP n'accèddent pas à Internet. Je me 
demande donc s'il s'agit d'un problème DHCP (passerelle?) ou d'un 
problème DNS (Résolution de nom?), ou les deux...


Bon! faut dire que je ne suis pas trop sûr de moi, c'est la première 
fois que je fais un routage sur un serveur Linux.

Quelqu'un aurait-il une idée ?
Merci d'avance. Merci vraiment.


A toutes fins utiles, je vous joins les fichiers de config :

 /etc/resolv.conf:
nameserver 192.168.1.254

 /var/cache/bind9/geo.local.zone
$ORIGIN .
$TTL 86400  ; 1 day
geo.localIN SOA  servgeo.geo.local. admg...@geo.local. (
20091  ; serial
3600   ; refresh (1 hour)
300; retry (5 minutes)
2592000; expire (4 weeks 2 days)
86400  ; minimum (1 day)
)
NS  servgeo.geo.local.
MX  10 servgeo.geo.local.
$ORIGIN geo.local.
$TTL 43200  ; 12 hours
dns CNAME   servgeo
servgeo A   192.168.50.1
routeur A   192.168.1.254

 /etc/dhcp3/dhcp.conf
# Options générales
option domain-name geo.local;
option domain-name-servers servgeo.geo.local;
option ntp-servers servgeo.geo.local;
option subnet-mask 255.255.255.0;

# Bail mini
default-lease-time 86400;
log-facility local7;

subnet 192.168.50.0 netmask 255.255.255.0 {
  range 192.168.50.10 192.168.50.50;
  option routers 192.168.1.254;
  option broadcast-address 192.168.50.255;
  authoritative;
}

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org