@r00t @DomiP

La pointe de l’iroute de Teltonika était en fait la dernière pièce manquante.

Un grand merci à vous pour vos astuces et conseils ! Sans eux, je ne serais jamais arrivé aussi loin. 👍👍👍

Maintenant, je dois faire un peu de réglage…

Il semble que le routeur LTE étouffe tout le trafic passant par le tunnel, ce qui n’est pas vraiment le cas.

LG Fritz

Afficher la langue d’origine (Allemand)

@r00t @DomiP

Alors maintenant, les choses se déroulent presque comme prévu.

J’ai dû commenter quelques commandes push côté serveur afin que le client ne poursuive pas tout le trafic à travers le tunnel.

Maintenant j’ai un dernier problème :

Je n’ai pas encore réussi à rendre persistante la route statique nécessaire.

J’ai trouvé diverses recettes sur Google, mais rien n’y fait ! 😕

Quelqu’un a posé exactement cette question sur le forum DietPi, mais curieusement, il n’a pas obtenu de réponse…. 😵‍💫

Il doit y avoir un moyen

route IP ajouter 192.168.2.0/24 via 10.198.101.2

pour le rendre persistant !

L’un de vous peut-il me donner le conseil le plus important ?

S’il te plaît, ne me laisse pas tomber

LG Fritz

Afficher la langue d’origine (Allemand)

Salut @Frafeffeu86

Désolé pour la réponse tardive.

Eh bien, en utilisant iroute, l’itinéraire est défini dès que le VPN est en cours d’exécution. Ou?

Ensuite, après un redémarrage, il vous suffit de vous assurer que le tunnel est automatiquement prêt - ni mon Pi ni moi ne sommes au régime, donc je dois deviner un peu maintenant, mais je dirais que ça devrait en fait aller bien maintenant.

La route est-elle terminée après le redémarrage du Pi ? Le routeur essaie-t-il automatiquement de se reconnecter au VPN ?

LG

r00t

Afficher la langue d’origine (Allemand)

4b 65 69 6e 65 20 4d 61 63 68 74 20 64 65 72 20 6c 65 67 61 63 79 20 49 50 21

@r00t

Donc, ce que j’ai trouvé, c’est qu’il a besoin à la fois de l’entrée iroute sur le serveur et de la route statique sur le Pi pour que cela fonctionne.

Le tunnel est reconstruit sans problème après un redémarrage (sans fissures au plafond 😉), mais le fonctionnement symétrique ne fonctionne à nouveau qu’après avoir gratté à nouveau le tracé statique. Cela signifie que je cherche toujours un moyen de rendre l’itinéraire persistant sur DietPi.

Mais maintenant, j’ai découvert un autre problème :

Depuis le réseau du serveur, j’ai une connexion au routeur LTE et je peux m’y connecter, etc.

J’ai ensuite naïvement supposé que j’aurais alors accès à l’ensemble du sous-réseau du routeur LTE - jusqu’à ce que je le teste 😕. Les PING arrivent sur l’appareil dans le réseau client (vérifiés avec WireShark), mais rien n’est renvoyé 😒.

J’ai signalé ce fait au support Teltonika, nous verrons si quelque chose se passe.

Ou avez-vous encore une idée géniale ?

LG Fritz

Afficher la langue d’origine (Allemand)

@r00t @DomiP

Le problème avec le PING a été résolu. Il s’agissait d’un problème de configuration du pare-feu. Heureusement, je l’ai compris moi-même 😳…..

En revanche, des conseils pertinents sur les routes statiques persistantes sur un DietPi sont toujours les bienvenus.

LG Fritz

Afficher la langue d’origine (Allemand)

Salut @Frafeffeu86

En revanche, des conseils pertinents sur les routes statiques persistantes sur un DietPi sont toujours les bienvenus.

Alors un de mes Pis doit être au régime, je vous le dirai dès que j’en saurai plus.

LG

r00t

Afficher la langue d’origine (Allemand)

4b 65 69 6e 65 20 4d 61 63 68 74 20 64 65 72 20 6c 65 67 61 63 79 20 49 50 21

Salut @Frafeffeu86

J’ai encore appris quelque chose, DietPi est un Pi au régime, ou une Debian bien nourrie - selon le point de vue 😄

Voici comment cela fonctionne pour moi (remplacez l’adresse via bien sûr) :

Fichier /etc/network/interfaces

# Emplacement : /etc/network/interfaces
# Veuillez modifier les paramètres réseau via : dietpi-config
# Ou créez vos propres drop-ins dans : /etc/network/interfaces.d/

# Déposez les configurations
source interfaces.d/*

#Ethernet
autoriser le branchement à chaud eth0
iface eth0 inet DHCP
adresse 192.168.0.100
masque de réseau 255.255.255.0
passerelle 192.168.0.1
#serveurs de noms DNS 9.9.9.9 149.112.112.112
la route IP vers le haut ajoute 192.168.2.0/24 via 10.20.10.2
la route IP vers le bas supprime 192.168.2.0/24 via 10.20.10.2

#Wi-Fi
#allow-hotplug wlan0
iface wlan0 inet DHCP
adresse 192.168.0.100
masque de réseau 255.255.255.0
passerelle 192.168.0.1
#serveurs de noms DNS 9.9.9.9 149.112.112.112
mise hors tension sans fil
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

Vous pouvez le faire en utilisant systemctl restart networking. Si vous êtes courageux, via SSH, sinon connectez le pi directement à un moniteur et un clavier. Cela peut prendre un certain temps avant que le Pi soit à nouveau en ligne, mais il devrait être de retour au plus tard après 30 secondes.

Avec _systemctl status networkin_g et journalctl -xefu networking, vous pouvez dépanner en cas de problème. Ne désespérez pas, des générations d’étudiants en informatique ont désespéré de ce dossier 😉

Si vous utilisez le WiFi, la config doit bien entendu être sous wlan0.

LG

r00t

Afficher la langue d’origine (Allemand)

4b 65 69 6e 65 20 4d 61 63 68 74 20 64 65 72 20 6c 65 67 61 63 79 20 49 50 21

J’ai déjà essayé cette entrée, mais cela n’a pas fonctionné pour moi et cela ne fonctionne toujours pas. Après un redémarrage, la route a disparu 😣

L’état du réseau systemctl après le redémarrage affiche ce qui suit :

root@DietPi : ~# mise en réseau du statut systemctl
Quantity networking.service - Augmenter les interfaces réseau
Chargé : chargé (/lib/systemd/system/networking.service ; activé ; prédéfini : activé)
Actif : actif (sorti) depuis le jeu. 2023-09-14 22:11:06 CEST ; il y a 1min 1s
Documents : man:interfaces(5)
Processus : 309 ExecStart=/sbin/ifup -a –read-environment (code=exited, status=0/SUCCESS)
Processus : 374 ExecStart=/bin/sh -c if [ -f /run/network/restart-hotplug ]; puis /sbin/ifup -a –read-environment –allow=hotplug; fi (code=sorti, statut=0/SUCCÈS)
PID principal : 374 (code=sorti, statut=0/SUCCÈS)
CPU : 265 ms

14 septembre 22:11:05 DietPi systemd[1] : Démarrage de networking.service - Augmenter les interfaces réseau…
14 septembre 22:11:06 DietPi systemd[1] : Terminé networking.service - Augmenter les interfaces réseau.
[root@DietPi:~#](mailto:root@DietPi:~)

Pourquoi toujours moi??? 😥

Afficher la langue d’origine (Allemand)

Salut @Frafeffeu86

oh bien sûr - c’est une interface différente. aaégalement - puisque openvpn gère l’interface tun0, nous devons laisser openvpn le faire.

1. Remettez /etc/network/interfaces à son état d’origine.

2. dans /etc/openvpn/server.conf :

itinéraire 192.168.2.0 255.255.255.0 10.198.101.2

ajouter.

3. Redémarrez le serveur openvpn avec systemctl restart openvpn.

4. On croise les doigts 😉

LG

r00t

Afficher la langue d’origine (Allemand)

4b 65 69 6e 65 20 4d 61 63 68 74 20 64 65 72 20 6c 65 67 61 63 79 20 49 50 21

@r00t 👌👌👌👍👍👍🕺📣🥳🎉

Youpi !! Ça marche! Tu es un génie !

Merci beaucoup pour votre aide !

Une dernière question : Où se trouvent les paramètres d’adresse du port Ethernet ?

Apparemment, il ne se soucie pas des entrées dans /etc/network/interfaces…

LG Fritz

Afficher la langue d’origine (Allemand)
  • r00t a répondu à cette contribution.

    Salut Frafeffeu86

    Cela n’a pas d’importance – il est sur DHCP par défaut, les adresses ci-dessous sont destinées à servir de « solution de secours » en cas de problème avec DHCP.

    DietPi vous propose même un tutu pour cela 😉

    dietpi-config

    7 : Options réseau : Adaptateurs > Ethernet : Disponible | [Activé] | Connecté

    Définissez ensuite le mode sur [STATIC], ajustez l’adresse et le GW, puis cliquez sur Appliquer.

    r00t_0-1694762343675.png

    LG

    r00t

    Afficher la langue d’origine (Allemand)

    4b 65 69 6e 65 20 4d 61 63 68 74 20 64 65 72 20 6c 65 67 61 63 79 20 49 50 21