OpenVPN : could not access PID file

Bonjour à tous,

C’est encore moi et mes misères…

Depuis hier, tous mes postes VPN ne fonctionnent plus visiblement. Certains utilisateurs avaient bien les écran verts du client VPN (l’icône de diagnostic !) sans pouvoir se connecter aux lecteurs réseaux du serveur. sans chercher à comprendre, je reboot le serveur et demande de réessayer. Là, une marée de plaintes a surgi en disant que plus rien ne fonctionnait. En effet, la commande “service openvpn status” me donne :

service openvpn status could not access PID file for VPN 'client' ... failed! VPN 'server' is not running ... failed!

Bien sûr, j’ai cherché sur internet mais je n’ai rien trouvé de probant, à croire que je suis le seul à avoir reçu un tel message d’erreur.

J’imagine que la solution est simple, mais je ne suis pas capable de la trouver…

Merci par avance de votre aide.

Simple, visiblement le serveur n’arrive pas à se lancer. Que donne le syslog après avoir essayé? Que donne
$ pidof openvpn
et

ifconfig -a

Salut,

pidof openvpn -> rien

ifconfig -a

eth0      Link encap:Ethernet  HWaddr d0:67:e5:ea:b2:9f
          inet adr:192.168.1.51  Bcast:192.168.1.255  Masque:255.255.255.0
          adr inet6: fe80::d267:e5ff:feea:b29f/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1000364 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1237364 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          RX bytes:515956964 (492.0 MiB)  TX bytes:1428717472 (1.3 GiB)
          Interruption:16

lo        Link encap:Boucle locale
          inet adr:127.0.0.1  Masque:255.0.0.0
          adr inet6: ::1/128 Scope:Hôte
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:563 errors:0 dropped:0 overruns:0 frame:0
          TX packets:563 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          RX bytes:44846 (43.7 KiB)  TX bytes:44846 (43.7 KiB)

pan0      Link encap:Ethernet  HWaddr 2a:9b:54:c2:68:27
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Quant aux logs, les voici au démarrage :

Wed Jun 12 09:01:33 2013 OpenVPN 2.1.3 i486-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [MH] [PF_INET6] [eurephia] built on Feb 20 2012
Wed Jun 12 09:01:33 2013 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Wed Jun 12 09:01:33 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Wed Jun 12 09:01:33 2013 Diffie-Hellman initialized with 1024 bit key
Wed Jun 12 09:01:33 2013 /usr/bin/openssl-vulnkey -q -b 1024 -m <modulus omitted>
Wed Jun 12 09:01:33 2013 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
Wed Jun 12 09:01:33 2013 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jun 12 09:01:33 2013 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jun 12 09:01:33 2013 TLS-Auth MTU parms [ L:1560 D:168 EF:68 EB:0 ET:0 EL:0 ]
Wed Jun 12 09:01:33 2013 Socket Buffers: R=[87380->131072] S=[16384->131072]
Wed Jun 12 09:01:33 2013 ROUTE default_gateway=192.168.1.1
Wed Jun 12 09:01:33 2013 TUN/TAP device tun0 opened
Wed Jun 12 09:01:33 2013 TUN/TAP TX queue length set to 100
Wed Jun 12 09:01:33 2013 /sbin/ifconfig tun0 10.8.0.1 pointopoint 10.8.0.2 mtu 1500
Wed Jun 12 09:01:33 2013 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2
Wed Jun 12 09:01:33 2013 Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Jun 12 07:01:33 2013 chroot to '/etc/openvpn/jail' and cd to '/' succeeded
Wed Jun 12 07:01:33 2013 GID set to nogroup
Wed Jun 12 07:01:33 2013 UID set to nobody
Wed Jun 12 07:01:33 2013 Listening for incoming TCP connection on [undef]
Wed Jun 12 07:01:33 2013 TCPv4_SERVER link local (bound): [undef]
Wed Jun 12 07:01:33 2013 TCPv4_SERVER link remote: [undef]
Wed Jun 12 07:01:33 2013 MULTI: multi_init called, r=256 v=256
Wed Jun 12 07:01:33 2013 IFCONFIG POOL: base=10.8.0.4 size=62
Wed Jun 12 07:01:33 2013 MULTI: TCP INIT maxclients=1024 maxevents=1028
Wed Jun 12 07:01:33 2013 Initialization Sequence Completed

Hum, et juste après ça il n’y a pas de processus openvpn qui tourne?

Si, il y a l’air d’en exister un :

ps aux | grep openvpn
nobody    6595  0.0  0.0   4712  1768 ?        Ss   09:01   0:00 /usr/sbin/openvpn --writepid /var/run/openvpn.server.pid --daemon ovpn-server --cd /etc/openvpn --config /etc/openvpn/server.conf

Par contre, toujours les failed :

service openvpn status
could not access PID file for VPN 'client' ... failed!
VPN 'server' is not running ... failed!

Sans rire, je comprends pas grand chose.

L’étonnant est que ifconfig -a ne montre aucune interface. Que donne un netstat -tupl

Rien sur le vpn apparemment :

netstat -tupl
Connexions Internet actives (seulement serveurs)
Proto Recv-Q Send-Q Adresse locale          Adresse distante        Etat        PID/Program name
tcp        0      0 megadeth:mysql          *:*                     LISTEN      2739/mysqld
tcp        0      0 *:svn                   *:*                     LISTEN      1784/svnserve
tcp        0      0 *:sunrpc                *:*                     LISTEN      982/portmap
tcp        0      0 *:41427                 *:*                     LISTEN      -
tcp        0      0 *:44147                 *:*                     LISTEN      995/rpc.statd
tcp        0      0 megadeth:domain         *:*                     LISTEN      1435/named
tcp        0      0 *:ftp                   *:*                     LISTEN      2269/vsftpd
tcp        0      0 localhost:domain        *:*                     LISTEN      1435/named
tcp        0      0 *:ssh                   *:*                     LISTEN      1399/sshd
tcp        0      0 localhost:ipp           *:*                     LISTEN      1998/cupsd
tcp        0      0 localhost:smtp          *:*                     LISTEN      2344/exim4
tcp        0      0 localhost:953           *:*                     LISTEN      1431/lwresd
tcp        0      0 *:nfs                   *:*                     LISTEN      -
tcp        0      0 *:44613                 *:*                     LISTEN      1563/rpc.mountd
tcp        0      0 *:swat                  *:*                     LISTEN      1354/inetd
tcp6       0      0 [::]:8009               [::]:*                  LISTEN      2302/java
tcp6       0      0 [::]:netbios-ssn        [::]:*                  LISTEN      2318/smbd
tcp6       0      0 [::]:http-alt           [::]:*                  LISTEN      2302/java
tcp6       0      0 [::]:www                [::]:*                  LISTEN      1809/apache2
tcp6       0      0 [::]:domain             [::]:*                  LISTEN      1435/named
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN      1399/sshd
tcp6       0      0 ip6-localhost:ipp       [::]:*                  LISTEN      1998/cupsd
tcp6       0      0 ip6-localhost:smtp      [::]:*                  LISTEN      2344/exim4
tcp6       0      0 ip6-localhost:953       [::]:*                  LISTEN      1431/lwresd
tcp6       0      0 [::]:microsoft-ds       [::]:*                  LISTEN      2318/smbd
tcp6       0      0 localhost:8005          [::]:*                  LISTEN      2302/java
udp        0      0 megadeth:domain         *:*                                 1435/named
udp        0      0 localhost:domain        *:*                                 1435/named
udp        0      0 *:bootpc                *:*                                 1826/dhclient
udp        0      0 *:49613                 *:*                                 995/rpc.statd
udp        0      0 *:40423                 *:*                                 -
udp        0      0 *:mdns                  *:*                                 1876/avahi-daemon:
udp        0      0 *:747                   *:*                                 995/rpc.statd
udp        0      0 *:42348                 *:*                                 1876/avahi-daemon:
udp        0      0 *:51182                 *:*                                 1563/rpc.mountd
udp        0      0 *:sunrpc                *:*                                 982/portmap
udp        0      0 *:ipp                   *:*                                 1998/cupsd
udp        0      0 *:nfs                   *:*                                 -
udp        0      0 192.168.1.25:netbios-ns *:*                                 2298/nmbd
udp        0      0 megadeth:netbios-ns     *:*                                 2298/nmbd
udp        0      0 *:netbios-ns            *:*                                 2298/nmbd
udp        0      0 192.168.1.2:netbios-dgm *:*                                 2298/nmbd
udp        0      0 megadeth:netbios-dgm    *:*                                 2298/nmbd
udp        0      0 *:netbios-dgm           *:*                                 2298/nmbd
udp        0      0 localhost:921           *:*                                 1431/lwresd
udp6       0      0 [::]:domain             [::]:*                              1435/named
udp6       0      0 [::]:mdns               [::]:*                              1876/avahi-daemon:
udp6       0      0 [::]:53770              [::]:*                              1876/avahi-daemon:

Groumf, si le processus openvpn existe encore, (avec le pid 6595), que donne

lsof -p 6595 | grep -v /lib

Tu dois voir un truc genre

cerbere:/home/francois# lsof -p 3131 | grep -v /lib COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME openvpn 3131 root cwd DIR 3,5 4096 293498 /etc/openvpn openvpn 3131 root rtd DIR 3,5 4096 2 / openvpn 3131 root txt REG 3,5 478068 219531 /usr/sbin/openvpn openvpn 3131 root 0u CHR 1,3 563 /dev/null openvpn 3131 root 1u CHR 1,3 563 /dev/null openvpn 3131 root 2u CHR 1,3 563 /dev/null openvpn 3131 root 3w REG 3,6 166 2097158 /var/run/openvpn.test.status openvpn 3131 root 4u IPv4 5367 UDP *:openvpn openvpn 3131 root 5u CHR 10,200 2506 /dev/net/tun cerbere:/home/francois#

Ce qui est marrant c’est :

ps aux | grep openvpn
root      8634  0.0  0.0   3324   840 pts/0    S+   09:19   0:00 grep openvpn

Ce qui signifie que le process ne tourne pas, or :

service openvpn status
could not access PID file for VPN 'client' ... failed!
VPN 'server' is not running ... failed!

Je peux vous garantir que j’ai rien touché hier.

Je pense que pendant la phase de démarrage, y’a bien le process qui se lance et qui test mais au bout d’un moment il s’arrête. Du coup je tente un restart du bousin.

service openvpn restart
Stopping virtual private network daemon:kill: 258: No such process

 server.
Starting virtual private network daemon: client server.

Dans les 10 secondes :

service openvpn status
could not access PID file for VPN 'client' ... failed!
VPN 'server' is running.

Puis :

ps aux | grep openvpn nobody 8704 0.0 0.0 4632 1128 ? Ss 09:22 0:00 /usr/sbin/openvpn --writepid /var/run/openvpn.server.pid --daemon ovpn-server --cd /etc/openvpn --config /etc/openvpn/server.conf

En attendant 20 min, retour à la classique :

/var/www/envisol/rapports# service openvpn status
could not access PID file for VPN 'client' ... failed!
VPN 'server' is not running ... failed!

Edit : du coup, ta commande ne me donne rien quand il est sur failed !

En revanche, au start ça me donne :

lsof -p 9041 | grep -v /lib
COMMAND  PID   USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
openvpn 9041 nobody  cwd    DIR    8,1     4096 45932606 /etc/openvpn/jail
openvpn 9041 nobody  rtd    DIR    8,1     4096 45932606 /etc/openvpn/jail
openvpn 9041 nobody  txt    REG    8,1   515044 50689504 /usr/sbin/openvpn
openvpn 9041 nobody    0u   CHR    1,3      0t0      580 /dev/null
openvpn 9041 nobody    1w   REG    8,1 46745653 50324198 /var/log/openvpn.log
openvpn 9041 nobody    2w   REG    8,1 46745653 50324198 /var/log/openvpn.log
openvpn 9041 nobody    3w   REG    8,1      232 45932608 /etc/openvpn/openvpn-status.log
openvpn 9041 nobody    4u  IPv4  55838      0t0      TCP *:https (LISTEN)
openvpn 9041 nobody    5u   CHR 10,200      0t0     2525 /dev/net/tun
openvpn 9041 nobody    6u  0000    0,9        0      578 anon_inode

Que dit /var/log/openvpn.log

Au start :


Fri Jun 14 11:44:42 2013 OpenVPN 2.1.3 i486-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [MH] [PF_INET6] [eurephia] built on Feb 20 2012
Fri Jun 14 11:44:42 2013 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Fri Jun 14 11:44:42 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Jun 14 11:44:42 2013 Diffie-Hellman initialized with 1024 bit key
Fri Jun 14 11:44:42 2013 /usr/bin/openssl-vulnkey -q -b 1024 -m <modulus omitted
Fri Jun 14 11:44:43 2013 Control Channel Authentication: using 'ta.key' as a Ope
Fri Jun 14 11:44:43 2013 Outgoing Control Channel Authentication: Using 160 bit
Fri Jun 14 11:44:43 2013 Incoming Control Channel Authentication: Using 160 bit
Fri Jun 14 11:44:43 2013 TLS-Auth MTU parms [ L:1560 D:168 EF:68 EB:0 ET:0 EL:0
Fri Jun 14 11:44:43 2013 Socket Buffers: R=[87380->131072] S=[16384->131072]
Fri Jun 14 11:44:43 2013 ROUTE default_gateway=192.168.1.1
Fri Jun 14 11:44:43 2013 TUN/TAP device tun0 opened
Fri Jun 14 11:44:43 2013 TUN/TAP TX queue length set to 100
Fri Jun 14 11:44:43 2013 /sbin/ifconfig tun0 10.8.0.1 pointopoint 10.8.0.2 mtu 1
Fri Jun 14 11:44:43 2013 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw
Fri Jun 14 11:44:43 2013 Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:135 ET:
Fri Jun 14 09:44:43 2013 chroot to '/etc/openvpn/jail' and cd to '/' succeeded
Fri Jun 14 09:44:43 2013 GID set to nogroup
Fri Jun 14 09:44:43 2013 UID set to nobody
Fri Jun 14 09:44:43 2013 Listening for incoming TCP connection on [undef]
Fri Jun 14 09:44:43 2013 TCPv4_SERVER link local (bound): [undef]
Fri Jun 14 09:44:43 2013 TCPv4_SERVER link remote: [undef]
Fri Jun 14 09:44:43 2013 MULTI: multi_init called, r=256 v=256
Fri Jun 14 09:44:43 2013 IFCONFIG POOL: base=10.8.0.4 size=62
Fri Jun 14 09:44:43 2013 MULTI: TCP INIT maxclients=1024 maxevents=1028
Fri Jun 14 09:44:43 2013 Initialization Sequence Completed

Sinon, un extrait :

Thu Jun 13 09:18:35 2013 MULTI: multi_create_instance called
Thu Jun 13 09:18:35 2013 Re-using SSL/TLS context
Thu Jun 13 09:18:35 2013 LZO compression initialized
Thu Jun 13 09:18:35 2013 Control Channel MTU parms [ L:1560 D:168 EF:68 EB:0 ET:0 EL:0 ]
Thu Jun 13 09:18:35 2013 Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Jun 13 09:18:35 2013 Local Options hash (VER=V4): '9915e4a2'
Thu Jun 13 09:18:35 2013 Expected Remote Options hash (VER=V4): '2f2c6498'
Thu Jun 13 09:18:35 2013 TCP connection established with [AF_INET]90.23.87.98:3697
Thu Jun 13 09:18:35 2013 TCPv4_SERVER link local: [undef]
Thu Jun 13 09:18:35 2013 TCPv4_SERVER link remote: [AF_INET]90.23.87.98:3697
Thu Jun 13 09:18:35 2013 90.23.87.98:3697 TLS: Initial packet from [AF_INET]90.23.87.98:3697, sid=53a46420 5d5e4b83
Thu Jun 13 09:18:37 2013 90.23.87.98:3697 CRL: cannot read: crl.pem: No such file or directory (errno=2)
Thu Jun 13 09:18:37 2013 90.23.87.98:3697 Exiting
Thu Jun 13 09:18:37 2013 90.23.87.98:3697 /sbin/route del -net 10.8.0.0 netmask 255.255.255.0
Thu Jun 13 09:18:37 2013 90.23.87.98:3697 ERROR: Linux route delete command failed: could not execute external program
Thu Jun 13 09:18:37 2013 90.23.87.98:3697 Closing TUN/TAP interface
Thu Jun 13 09:18:37 2013 90.23.87.98:3697 /sbin/ifconfig tun0 0.0.0.0
Thu Jun 13 09:18:37 2013 90.23.87.98:3697 Linux ip addr del failed: could not execute external program

Et ça tourne en boucle

Il ne peut lire le certificat

[quote]Thu Jun 13 09:18:37 2013 90.23.87.98:3697 CRL: cannot read: crl.pem: No such file or directory (errno=2)
[/quote]

Où as tu mis ce fichier, regarde ses droits (et le souci avec le chroot)

HUm ouais je vois, ça doit encore être un souci de droits…

Il est ici :

find / -name "crl.pem" /etc/openvpn/crl.pem /etc/openvpn/easy-rsa/keys/crl.pem

Avec :

-rw-r--r--  1 root root  503 30 mai   10:51 crl.pem #/etc/openvpn/
-rw-r--r--  1 root root  503  2 mars   2012 crl.pem #/etc/openvpn/easy-rsa/keys/

Edit : j’ai essayé de mettre en 755 ces deux fichiers, on dirait que le VPN ne coupe plus.

Note que je crois que c’est la liste des certificalts révoqués donc ça ne devrait pas gêner. Bon, on persiste, il y a

Thu Jun 13 09:18:37 2013 90.23.87.98:3697 /sbin/route del -net 10.8.0.0 netmask 255.255.255.0 Thu Jun 13 09:18:37 2013 90.23.87.98:3697 ERROR: Linux route delete command failed: could not execute external program Thu Jun 13 09:18:37 2013 90.23.87.98:3697 Closing TUN/TAP interface

Il ne peut exécuter ce programme (/sbin/route) à cause du chroot je pense… As tu modifié la configuration? Si tu exécutes des scripts, vérifies le «sheebang» de ces scripts. Je pense que comme openvpn est éxécuté sous nobody.nogroup, il ne peut éxécuter /sbin/route. Essaye de voir en exécutant openvpn sous root. Il faut que l’utilisateur exécutant openvpn puisse modifier les routes du système je pense.

Ok, alors j’ai rien compris… Exécuter OpenVPN sous root, pour le starter & autres tu veux dire ? Mêmes soucis.

Je n’ai pas touché la configuration, vraiment. Ca tournait bien pour mes users distants jusqu’à ce que je redémarre la machine.

Au début, il fait

Fri Jun 14 11:44:43 2013 /sbin/ifconfig tun0 10.8.0.1 pointopoint 10.8.0.2 mtu 1 Fri Jun 14 11:44:43 2013 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw Fri Jun 14 11:44:43 2013 Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:135 ET: Fri Jun 14 09:44:43 2013 chroot to '/etc/openvpn/jail' and cd to '/' succeeded Fri Jun 14 09:44:43 2013 GID set to nogroup Fri Jun 14 09:44:43 2013 UID set to nobody
La commande /sbin/route est effectué sous root, puis il fait un chroot et se met comme appartenant à nobody, nogroup (directive user et group dans le fichgier conf de ton vpn).

Ensuite il fait

Thu Jun 13 09:18:37 2013 90.23.87.98:3697 CRL: cannot read: crl.pem: No such file or directory (errno=2) Thu Jun 13 09:18:37 2013 90.23.87.98:3697 Exiting Thu Jun 13 09:18:37 2013 90.23.87.98:3697 /sbin/route del -net 10.8.0.0 netmask 255.255.255.0 Thu Jun 13 09:18:37 2013 90.23.87.98:3697 ERROR: Linux route delete command failed: could not execute external program Thu Jun 13 09:18:37 2013 90.23.87.98:3697 Closing TUN/TAP interface
C’est là que tout se passe. À cet instant précis il arrête le VPN pour une raison à déterminer.
Il signale qu’il ne trouve pas le fichier crl.pem (qui contient la liste des certificats révoqués). Ça ne devrait pas arrêter le réseau. Puis il affiche Exiting. Il exécute la commande /sbin/route et n’arrive pas à la faire car il n’a plus les droits.
Bon, c’est en gros le scénario.

Souci 1: Lorsqu’il est nobody:nogroup il ne peut plus exécuté la commande route, visiblement c’est gênant. Mais dans le scénario ci dessus, ça n’est sans doute pas la raison de l’arrêt du réseau.

Souci 2: Il n’arrive pas à lire le fichier crl.pem. Cela signifie que tu dois avoir dans ton fichier de configuration une directive
crl-verify crl.pem
Dans ce cas, il faut que cette liste soit accessible par openvpn, essaye de mettre ce fichier dans /etc/openvpn, ça devrait le contenter.

La raison pour laquelle il s’arrête n’est pas claire. Quelles sont les actions que tu as faites avant que les pbms apparaissent.

Salut,

Alors après vérification, mon crl.pem est bien dans /etc/openvpn, je vois pas le problème. Effectivement, j’ai bien une directive crl-verify crl.pem dans mon /etc/openvpn/server.conf.

Normalement, rien n’a été fait sur ma machine, du moins pas de ma main pour une fois. La seule chose que j’ai faite c’est un reboot du serveur. Depuis, rien ne va plus.

Je ne sais pas si tu te souviens, mais auparavant (y’a quelques mois déjà), j’avais fait un léger chmod -R 444 / … Mais je crois que tu m’avais donné les bons droits, ce qui a fait que OpenVPN n’a jamais véritablement déconné. Mais depuis ce reboot, brrrrr.

L’autre chose significative que j’ai pu faire, à la limite, ce sont des MàJ Debian…

Voilà voilà…

Edit : il s’avère que le “failed” de “VPN ‘server’ is not running … failed!” n’apparait que quand un client essaie de se connecter, y’a pas un laps de temps.

Quels sont les droits du fichier crl.pem??

A l’origine 644, j’ai mis 777 pour le test ici.

Rappel : il y est deux fois.
/etc/openvpn
/etc/openvpn/easy-rsa/keys

Edit : Et, au pire, si je réinstalle openVPN je vais devoir me faire **** à refaire ma config ? Si non, ça réglerait pas le problème ?

Je me permets de faire un up, je suis toujours bloqué et rien n’a pu avancer de mon côté…

Merci encore.