Projet

Général

Profil

Anomalie #1373

Impossible d'accéder aux machines du local via le VPN

Ajouté par Frédéric Couchet il y a plus de 10 ans. Mis à jour il y a plus de 3 ans.

Statut:
Fermé
Priorité:
Élevée
Assigné à:
Catégorie:
-
Version cible:
Début:
07/10/2013
Echéance:
% réalisé:

0%

Temps estimé:
Difficulté:
2 Facile

Description

Je souhaitais accéder aux machines du local April/Easter-Eggs via le VPN. Je monte le VPN mais ensuite les pings vers opium et scopolamine ne répondent pas et pour ssh j'obtiens :

ssh
ssh: connect to host 192.168.3.1 port 22: Connection timed out

Historique

#1

Mis à jour par Loïc Dachary il y a plus de 10 ans

  • Version cible changé de Octobre 2013 à Backlog
#2

Mis à jour par François Poulain il y a plus de 7 ans

  • Description mis à jour (diff)

A priori c'est toujours d'actu. Testé depuis dns, bastion et virola.

#3

Mis à jour par François Poulain il y a plus de 7 ans

A priori c'est juste un petit soucis de routage. Opium est bel et bien accessible depuis le cluster via le VPN, mais sous l'adresse 172.16.0.253, comme indiqué ici : https://admin.april.org/dokuwiki/doku.php?id=sysadm:vpn

Pour adresser le réseau interne, il faut définir la route :

# route add -net 192.168.3.0 netmask 255.255.255.0 gw 172.16.0.253

Et ça passe (tests faits sur la machine bots).

# ping 192.168.3.1
PING 192.168.3.1 (192.168.3.1) 56(84) bytes of data.
64 bytes from 192.168.3.1: icmp_seq=1 ttl=64 time=30.0 ms
# ping 192.168.3.4
PING 192.168.3.4 (192.168.3.4) 56(84) bytes of data.
64 bytes from 192.168.3.4: icmp_seq=1 ttl=63 time=31.2 ms

Question : comment définir cette route au démarrage du VPN ?

#4

Mis à jour par François Poulain il y a plus de 7 ans

Ha beh en fait cette question est répondue dans la doc :

Il est donc nécessaire d'ajouter des routes pour passer par opium pour accéder au local et vice-versa. Sur galanga:

/etc/network/interfaces

    auto br0
    iface br0 inet static
            address 172.16.0.254
            netmask 255.255.255.0
            bridge_ports none
            bridge_maxwait 0
            bridge_stp off
            bridge_fd 0
            post-up route add -net 192.168.3.0/24 gw 172.16.0.253

Le soucis c'est que ça n'a été fait visiblement que sur Galanga, et que j'ai testé le bug depuis d'autres machines. De fait, sur Galanga la config fonctionne.

#5

Mis à jour par Benjamin Drieu il y a plus de 7 ans

Je n'ai pas constaté qu'il était utile d'accéder au VPN via le cluster, donc n'ai pas déployé cette route (contrairement à galanga qui en a besoin). Quel est le besoin qui t'amène à le faire ?

#6

Mis à jour par François Poulain il y a plus de 7 ans

  • Statut changé de Nouveau à Fermé

Quel est le besoin qui t'amène à le faire ?

Aucun a priori. J'essaie juste de fermer des tickets.

Je m'étais mépris en pensant qu'il y avait un soucis au niveau du VPN, car la route manquait sur les machines depuis lesquelles j'ai fait un test. Vu que a posteriori le VPN fonctionne et que, pour la route, ce n'est pas un bug mais une feature, je pense qu'on peut fermer ce bug.

#7

Mis à jour par Christian P. Momon il y a plus de 3 ans

  • Assigné à mis à François Poulain

Formats disponibles : Atom PDF