tofu a écrit 16 commentaires

  • # Confusion

    Posté par  . En réponse à la dépêche Sortie de Bokeh 7.10. Évalué à 3.

    A ne pas confondre avec la librairie Python !

  • [^] # Re: regles de NAT sur les machines CLIENT-X

    Posté par  . En réponse au message Entrelacement de réseaux et VPN. Évalué à 1.

    J'ai donc testé la solution 1 qui me parait être la plus simple.

    Pour les tests j'ai remplacé l'IPBX par un Debian et j'ai donc ces adresses :
    - Server {tun0=10.64.0.1}
    - CLIENT-1 {tun0=10.64.0.100; eth0=192.168.138.16}
    - IPBX {eth0=192.168.138.12}

    L'IP 192.168.138.12 (IPBX) est translatée en 10.64.0.200.

    J'ai utilisé l'option client-nat d'OpenVPN pour pousser sur CLIENT-X la conf de NAT ci-dessous:

    ifconfig-push 10.64.0.100 255.255.255.0

    iroute 10.64.0.100
    iroute 10.64.0.200

    push "client-nat dnat 10.64.0.200 255.255.255.255 192.168.138.12"
    push "client-nat snat 10.64.0.1 255.255.255.255 192.168.138.16"
    push "client-nat snat 192.168.138.12 255.255.255.255 10.64.0.200"
    push "client-nat dnat 192.168.138.16 255.255.255.255 10.64.0.1"

    Avec cette configuration quand je lance un ping 10.64.0.200 depuis 10.64.0.1 (Server) :

    Server

    root@debian-supervisor:/etc/openvpn# ping 10.64.0.200
    PING 10.64.0.200 (10.64.0.200) 56(84) bytes of data.
    C
    --- 10.64.0.200 ping statistics ---
    4 packets transmitted, 0 received, 100% packet loss, time 3024ms

    CLIENT-1 (tcpdump)

    12:55:50.623757 IP 192.168.138.16 > 192.168.138.12: ICMP echo request, id 4212, seq 2, length 64
    12:55:50.623904 IP 192.168.138.12 > 192.168.138.16: ICMP echo reply, id 4212, seq 2, length 64
    12:55:51.631236 IP 192.168.138.16 > 192.168.138.12: ICMP echo request, id 4212, seq 3, length 64
    12:55:51.631406 IP 192.168.138.12 > 192.168.138.16: ICMP echo reply, id 4212, seq 3, length 64
    12:55:52.639972 IP 192.168.138.16 > 192.168.138.12: ICMP echo request, id 4212, seq 4, length 64
    12:55:52.640122 IP 192.168.138.12 > 192.168.138.16: ICMP echo reply, id 4212, seq 4, length 64

    IPBX (tcpdump)

    12:55:43.350550 IP 192.168.138.16 > 192.168.138.12: ICMP echo request, id 4212, seq 1, length 64
    12:55:43.350596 IP 192.168.138.12 > 192.168.138.16: ICMP echo reply, id 4212, seq 1, length 64
    12:55:44.359319 IP 192.168.138.16 > 192.168.138.12: ICMP echo request, id 4212, seq 2, length 64
    12:55:44.359354 IP 192.168.138.12 > 192.168.138.16: ICMP echo reply, id 4212, seq 2, length 64
    12:55:45.366772 IP 192.168.138.16 > 192.168.138.12: ICMP echo request, id 4212, seq 3, length 64
    12:55:45.366800 IP 192.168.138.12 > 192.168.138.16: ICMP echo reply, id 4212, seq 3, length 64
    12:55:46.375518 IP 192.168.138.16 > 192.168.138.12: ICMP echo request, id 4212, seq 4, length 64
    12:55:46.375549 IP 192.168.138.12 > 192.168.138.16: ICMP echo reply, id 4212, seq 4, length 64

    Donc en résumé on dirait qu'il manque quelque chose sur CLIENT-1 au niveau de la NAT pour translater 192.168.138.16 en 10.64.0.1 ?

    J'ai un peu du mal avec la NAT ^

  • [^] # Re: regles de NAT sur les machines CLIENT-X

    Posté par  . En réponse au message Entrelacement de réseaux et VPN. Évalué à 1.

    j'imagine que les machines CLIENT-X sont des machines à toi, que tu met chez le client pour permettre la telemaintenance des equipements.

    Exactement.

    donc sur l'equipement CLIENT-1, tu met un NAT qui convertit
    10.1.0.y en 192.168.0.y (en entrée des flux qui arrivent sur le VPN : DNAT)
    et 192.168.0.y en 10.1.0.y (en sortie des flux qui sortent sur le VPN : SNAT)

    J'avais réussi avec quelques lignes d'iptables sur CLIENT-X à convertir 10.1.0.y en 192.168.0.y, les paquets allaient jusqu'à l'IPBX mais ne revenaient pas.

    Je ne sais pas s'il est possible de faire une translation sans toucher à la configuration de l'IPBX ?

  • [^] # Re: NAT

    Posté par  . En réponse au message Entrelacement de réseaux et VPN. Évalué à 1.

    Titre de l'image

    Donc le but est de se connecter à Server pour avoir accès à tous nos équipements chez le client grâce à l'équipement Linux qui sert de point d'entrée.
    On peut imaginer Server dans un VPS chez un hébergeur type DigitalOcean.

    Ici je n'ai représenté qu'un seul client pour ne pas compliquer le schéma mais c'est grossièrement la même chose chez les autres clients.

    Donc on peut avoir différent type d'équipements.

  • [^] # Re: NAT

    Posté par  . En réponse au message Entrelacement de réseaux et VPN. Évalué à 1.

    Je veux avoir une connexion sur les équipements de nos clients. Donc il y a du SSH, du telnet, des protocoles proprios Avaya pour les configurations et du debug, du tftp, du SNMP etc.. Donc c'est pour ça que la redirection par port est trop complexe dans ce cas.

  • [^] # Re: SSH ?

    Posté par  . En réponse au message Entrelacement de réseaux et VPN. Évalué à 1. Dernière modification le 21/07/16 à 15:11.

    Non plus ! Ou peut etre pour les versions serveur mais ce n'est pas le cas ici.

  • [^] # Re: NAT

    Posté par  . En réponse au message Entrelacement de réseaux et VPN. Évalué à 1.

    Je venais de lire ce lien mais effectivement on peut faire mieux :P J'ai fini par comprendre que c'était tout simplement un bridge..

    Le schéma plus complet est le suivant:

    Titre de l'image

    PS: FW est le firewall du client.

    L'équipement CLIENTX n'est donc pas directement connecté à l'IPBX. Ce qui, sauf si je dis une bétise, ne fonctionne pas.

  • [^] # Re: NAT

    Posté par  . En réponse au message Entrelacement de réseaux et VPN. Évalué à 1. Dernière modification le 21/07/16 à 14:05.

    Effectivement ce serrait une idée si il n'y avait qu'un seul équipement. Parfois il peut y avoir plusieurs équipement de nature différente derrière un équipement CLIENTX. Ou peut-etre n'ais-je pas tout compris de ce que tu voulais dire par pont réseau..

  • [^] # Re: Réseau mesh

    Posté par  . En réponse au message Entrelacement de réseaux et VPN. Évalué à 1.

    Ok je vais essayer de creuser un peu plus. Si j'ai bien compris il n'y a rien à installer coté IPBX dans mon cas ?

  • [^] # Re: NAT

    Posté par  . En réponse au message Entrelacement de réseaux et VPN. Évalué à 1.

    Hélas non je ne peux pas c'est du Avaya donc du proprio..

  • [^] # Re: NAT

    Posté par  . En réponse au message Entrelacement de réseaux et VPN. Évalué à 1.

    Pour la partie VPN effectivement les clients ne sont pas isolés! Par contre j'ai pu lire qu'il était possible de translater une plage d'adresse entière. Par exemple 192.168.100.0/24 -> 10.64.100.0/24. J'avais réussi à faire un bout de configuration iptables qui fonctionnait. Les paquets étaient bien envoyés à l'IPBX mais ils n'étaient pas retournées vers l'équipement CLIENTX. Peut etre qu'il manquait un bout de conf sur CLIENTX..

    Car je ne pas utiliser la NAT avec des ports due au fait que les équipements IPBXX ne sont pas simple à configurer et des outils spécifiques sont utilisés. Autant dire que l'on ne peut presque pas toucher la configuration des IPBX.

  • [^] # Re: Réseau mesh

    Posté par  . En réponse au message Entrelacement de réseaux et VPN. Évalué à 1.

    Intéressant, je ne connaissais pas, par contre je ne pense pas que ce soit très adapté à mon cas. De ce que j'ai lu c'est plus pour les clients qui se connectent et déconnectent régulièrement comme des clients wifi ou des téléphones mobiles.

  • [^] # Re: avec ssh

    Posté par  . En réponse au message Proxy SOCKS5: connexion impossible. Évalué à 1.

    En fait non car on a pas besoin d’être sur que les paquets arrivent cela fait perdre du temps pour pas grand choses. Quelques pertes ne sont pas très grave. Il faut privilégier la vitesse donc UDP est souvent choisit.

    Oui je devrais avoir un peu de latence, j'avais environ 150ms avec OpenVPN avec SOCKS je pense que je peux baisser pas mal du fait que seulement le jeu passera par le proxy (et il n'y a peut être pas autant de cryptage ? à vérifier).

  • [^] # Re: avec ssh

    Posté par  . En réponse au message Proxy SOCKS5: connexion impossible. Évalué à 1.

    Les jeux en réseaux. Pourquoi ?

  • [^] # Re: avec ssh

    Posté par  . En réponse au message Proxy SOCKS5: connexion impossible. Évalué à 1.

    Donc l'UDP devrait passer ?

  • [^] # Re: diff entre ta conf et le tuto

    Posté par  . En réponse au message Proxy SOCKS5: connexion impossible. Évalué à 1. Dernière modification le 05/01/14 à 20:05.

    Oui et du coup j'écoute sur 127.0.0.1 et mon adr local: (netstat -natp)
    Connexions Internet actives (serveurs et établies)
    Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name
    tcp 0 0 0.0.0.0:51413 0.0.0.0:* LISTEN -
    tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
    tcp 0 0 127.0.0.1:1080 0.0.0.0:* LISTEN -
    tcp 0 0 192.168.0.26:1080 0.0.0.0:* LISTEN -
    tcp 0 0 0.0.0.0:9091 0.0.0.0:* LISTEN -
    tcp 0 0 192.168.0.26:22 **:41424 ESTABLISHED -
    tcp 0 572 192.168.0.26:22 *
    *:37848 ESTABLISHED -