# Partage de connexion sim900 + vpn **URL:** \ **Category:** Support Debian\ **Created:** [Janvier 1, 2022, 7:44 UTC](https://www.debian-fr.org/t/partage-de-connexion-sim900-vpn/85911 "2022-01-01T19:44:43Z")\ **Posts on this page:** 16\ **Page:** 2
**Author:** ![AnonymousCoward](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@AnonymousCoward](https://www.debian-fr.org/u/AnonymousCoward)\ **Post date:** [Janvier 30, 2022, 9:02 UTC](https://www.debian-fr.org/t/partage-de-connexion-sim900-vpn/85911/21 "2022-01-30T21:02:14Z")
C’est déjà ça. Est-ce que tu peux nous (re)donner les informations suivantes sur la OrangePi distante ? Les interfaces réseau : ```nohighlight ip link ls ``` Les adresses IPv4 configurées : ```nohighlight ip -4 addr ls ``` Les routes IPv4 configurées : ```nohighlight ip -4 route ls ``` Les règles de « routage avancé », on ne sait jamais : ```nohighlight ip -4 rule ls ``` Les règles iptables actuelles pour les tables filter, nat et mangle : ```nohighlight sudo iptables --line-numbers -nvx -t filter -L sudo iptables --line-numbers -nvx -t nat -L sudo iptables --line-numbers -nvx -t mangle -L ``` Si ça se trouve, il y a du SNAT sur la OrangePi distante comme il y en avait sur le Synology. – AnonymousCoward ---
**Author:** ![Cortexx06](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/e95f7d/32.png) [@Cortexx06](https://www.debian-fr.org/u/Cortexx06)\ **Post date:** [Janvier 30, 2022, 9:25 UTC](https://www.debian-fr.org/t/partage-de-connexion-sim900-vpn/85911/22 "2022-01-30T21:25:08Z")
_Voila les informations demandées :_ **`ip link ls` :** ```nohighlight 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 02:42:4d:99:f5:de brd ff:ff:ff:ff:ff:ff 3: wlan0: mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000 link/ether 12:42:4d:99:f5:de brd ff:ff:ff:ff:ff:ff 4: ppp0: mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 3 link/ppp 5: tun0: mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 100 link/none ``` **`ip -4 addr ls`** ```nohighlight 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc mq state UP group default qlen 1000 inet 10.10.10.1/24 brd 10.10.10.255 scope global eth0 valid_lft forever preferred_lft forever 4: ppp0: mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 3 inet 10.29.237.236 peer 192.200.1.21/32 scope global ppp0 valid_lft forever preferred_lft forever 5: tun0: mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100 inet 192.168.2.6 peer 192.168.2.5/32 scope gl ``` **ip -4 route ls** ```nohighlight default via 192.168.2.5 dev tun0 10.10.10.0/24 dev eth0 proto kernel scope link src 10.10.10.1 **123.123.123.123** dev ppp0 scope link **(j'ai modifié car c'est mon ip réel)** 169.254.0.0/16 dev eth0 scope link metric 1000 192.168.1.0/24 via 192.168.2.5 dev tun0 192.168.2.0/24 via 192.168.2.5 dev tun0 192.168.2.1 via 192.168.2.5 dev tun0 192.168.2.5 dev tun0 proto kernel scope link src 192.168.2.6 192.200.1.21 dev ppp0 proto kernel scope link src 10.29.237.236 ``` **`ip -4 rule ls`** ```nohighlight 0: from all lookup local 32766: from all lookup main 32767: from all lookup default ``` **`sudo iptables --line-numbers -nvx -t filter -L`** ```nohighlight Chain INPUT (policy ACCEPT 639 packets, 145362 bytes) num pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 3098 packets, 599700 bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT all -- wlan0 eth0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 2 0 0 ACCEPT all -- eth0 wlan0 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 386 packets, 58955 bytes) num pkts bytes target prot opt in out source destination ``` **`sudo iptables --line-numbers -nvx -t nat -L`** ```nohighlight Chain PREROUTING (policy ACCEPT 639 packets, 63774 bytes) num pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 41 packets, 14829 bytes) num pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 73 packets, 5434 bytes) num pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 MASQUERADE all -- * eth0 10.8.0.0/24 0.0.0.0/0 /* openvpn-nat-rule */ 2 0 0 MASQUERADE all -- * wlan0 0.0.0.0/0 0.0.0.0/0 3 256 26664 MASQUERADE all -- * tun0 0.0.0.0/0 0.0.0.0/0 4 331 22156 MASQUERADE all -- * ppp0 0.0.0.0/0 0.0.0.0/0 ``` **`sudo iptables --line-numbers -nvx -t mangle -L`** ```nohighlight Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination ``` ---
**Author:** ![AnonymousCoward](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@AnonymousCoward](https://www.debian-fr.org/u/AnonymousCoward)\ **Post date:** [Janvier 31, 2022, 9:58 UTC](https://www.debian-fr.org/t/partage-de-connexion-sim900-vpn/85911/23 "2022-01-31T09:58:14Z")
Il y a en effet une règle iptables similaire à celle sur le Synology. Si la OrangePi distante est la passerelle / gateway / le routeur par défaut pour le LAN distant, il faut que tu exécutes **3 fois** la commande ci-dessous, la même que précédemment : ```nohighlight sudo iptables -t nat -D POSTROUTING 1 ``` Cela supprimera les 3 premières règles de la chaîne POSTROUTING de la table nat. Ensuite, si tu est satisfait des modifications et que tu as installé le paquet [netfilter-persistent](https://packages.debian.org/buster/netfilter-persistent) comme suggéré par Almtesh, tu peux sauvegarder avec : ```nohighlight sudo netfilter-persistent save ``` – AnonymousCoward ---
**Author:** ![Cortexx06](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/e95f7d/32.png) [@Cortexx06](https://www.debian-fr.org/u/Cortexx06)\ **Post date:** [Janvier 31, 2022, 4:21 UTC](https://www.debian-fr.org/t/partage-de-connexion-sim900-vpn/85911/24 "2022-01-31T16:21:46Z")
Bonjour, alors j’ai essayé mais cela ne fonctionne pas, j’arrive à atteindre 192.168.2.6(orangepi a travers le vpn) mais pas le 10.10.10.1 (orange pi client mais son réseau Ethernet) Cependant en enlevant les règles iptables je perd le partage de connexion sur l’Orangepi entre le 2g et l’ethernet. Le but étant de me servir du orange pi client pour fournir un reseau distant, j’ai besoin de cette fonction. Aprés j’espere que je n’abuse pas de ton temps mais j’ai l’impression de touché au but 😛 je pense que peut etre le NAS synology, vue que a priori si j’ai bien compris c’est a lui que l’on demande ou est le 10.10.10.1, il ne doit pas être en mesure de cherché le eth0 du orangepi. peut être qu’il lui manque une info ? ---
**Author:** ![AnonymousCoward](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@AnonymousCoward](https://www.debian-fr.org/u/AnonymousCoward)\ **Post date:** [Février 1, 2022, 9:28 UTC](https://www.debian-fr.org/t/partage-de-connexion-sim900-vpn/85911/25 "2022-02-01T09:28:24Z")
En fait, la machine de départ ainsi que chaque machine située sur le chemin de la communication doivent toutes connaître la route pour trouver l’adresse IP de destination. Il faut bien évidemment que la même chose soit vraie concernant le trajet retour si l’on veut avoir une réponse. Et je pense que sur ce dernier problème, le Synology ne connaît pas la route vers 10.10.10.0/24 (ou 10.10.10.\*) . Ce que tu peux faire, c’est ajouter cette route à la main sur le Syno : ```nohighlight sudo ip -4 route add 10.10.10.0/24 via 192.168.2.6 ``` Hélas, cette route ne va pas tenir éternellement. Il faudra la remettre en place à chaque reboot du Synology. – AnonymousCoward ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Février 1, 2022, 12:36 UTC](https://www.debian-fr.org/t/partage-de-connexion-sim900-vpn/85911/26 "2022-02-01T12:36:35Z")
Juste au cas où il est tout à fait possible sur DSM (le système de Synology) d’ajouter une route statique : #### Pour configurer votre routage statique : 1. Accédez à **Panneau de configuration** \> **Réseau**. 2. Sous **Route statique** , cliquez sur **Créer**. 3. Dans le **Réseau de destination** , entrez l’adresse IP de votre destination. 4. Dans le **Masque de sous-réseau** , entrez le masque de sous-réseau de votre destination. 5. Dans **Passerelle** , entrez l’adresse de passerelle de votre destination. 6. Dans **Interface** , sélectionnez l’interface de votre destination. 7. Cliquez sur **OK**. #### Pour voir le tableau de routage IP : 1. Accédez à **Panneau de configuration** \> **Réseau**. 2. Sous **Route statique** , cliquez sur **Tableau de routage IP**. 3. Sélectionnez une interface réseau pour voir son tableau de routage IP à depuis la liste déroulant supérieure gauche. ---
**Author:** ![AnonymousCoward](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@AnonymousCoward](https://www.debian-fr.org/u/AnonymousCoward)\ **Post date:** [Février 1, 2022, 4:59 UTC](https://www.debian-fr.org/t/partage-de-connexion-sim900-vpn/85911/27 "2022-02-01T16:59:05Z")
D’ailleurs, si OpenVPN sur le Synology fonctionne en mode serveur, est-ce qu’il ne va pas bloquer les paquets envoyés par le Synology à destination du LAN 10.10.10.0/24 ? – AnonymousCoward ---
**Author:** ![Cortexx06](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/e95f7d/32.png) [@Cortexx06](https://www.debian-fr.org/u/Cortexx06)\ **Post date:** [Février 8, 2022, 2:46 UTC](https://www.debian-fr.org/t/partage-de-connexion-sim900-vpn/85911/28 "2022-02-08T14:46:45Z")
Bon alors déjà merci à tous, J’ai finalement réussi il y a beaucoup de paramétrage à faire finalement. Puis il resté une iptable avec l’ancienne ip du vpn qui bloqué aussi… Maintenant il me reste juste a trouvé comment faire pour que le vpn client ce connecte tout seul, car jusqu’a maintenant impossible 🙂 ---
**Author:** ![AnonymousCoward](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@AnonymousCoward](https://www.debian-fr.org/u/AnonymousCoward)\ **Post date:** [Février 8, 2022, 5:45 UTC](https://www.debian-fr.org/t/partage-de-connexion-sim900-vpn/85911/29 "2022-02-08T17:45:09Z")
Pour que OpenVpn se lance au démarrage : - avoir le fichier de configuration dans le répertoire `/etc/openvpn` , se terminant par `.conf` . Par exemple, `trumuche.conf` . - éditer le fichier /etc/default/openvpn et modifier la ligne pour avoir : ```nohighlight AUTOSTART="all" ``` (lire les commentaires dans le fichier pour comprendre) - recharger la configuration du service openvpn avec : ```nohighlight sudo systemctl daemon-reload ``` Arrivé là, ce devrait être bon. Si tu as besoin de voir l’état d’une connexion VPN ou de la redémarrer : ```nohighlight sudo systemctl status openvpn@trucmuche ``` Tu feras un petit résumé de ce qui a été fait ? Si jamais quelqu’un rencontre le même besoin. – AnonymousCoward ---
**Author:** ![Cortexx06](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/e95f7d/32.png) [@Cortexx06](https://www.debian-fr.org/u/Cortexx06)\ **Post date:** [Février 10, 2022, 4:04 UTC](https://www.debian-fr.org/t/partage-de-connexion-sim900-vpn/85911/30 "2022-02-10T16:04:46Z")
Bien sure je vais tout résumé j’espère que cela pourra aidé, enfaite pour le lancement automatique, cela ne marche pas même avec ce que tu m’a dit, j’avais déjà essayer, je pense qu’il y a un soucis car pour lancer mon client je dois utilisé la commande : ```nohighlight openvpn --config /etc/openvpn/openvpn.conf --comp-lzo ``` je pense que c’est la commande `--comp-lzo` qui bloque le lancement automatique, car il ne l’exécute pas nativement. j’ai essayé de placer cette commande dans un script qui ce lance au début mais cela ne fonctionne pas non plus… ---
**Author:** ![AnonymousCoward](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@AnonymousCoward](https://www.debian-fr.org/u/AnonymousCoward)\ **Post date:** [Février 19, 2022, 5:37 UTC](https://www.debian-fr.org/t/partage-de-connexion-sim900-vpn/85911/31 "2022-02-19T17:37:59Z")
> [@Cortexx06](#): > > je dois utilisé la commande : > > ```plaintext > openvpn --config /etc/openvpn/openvpn.conf --comp-lzo > > ``` Tu peux essayer d’ajouter une ligne comme ci-dessous au fichier de configuration de OpenVPN sur ta OrangePi pour voir si cela démarre : ```plaintext comp-lzo yes ``` Ensuite, tentes de démarrer la connexion avec, dans le cas d’un fichier nommé `openvpn.conf` : ```shell sudo systemctl start openvpn@openvpn ``` Et une dizaine de secondes plus tard : ```shell sudo journalctl --full --no-pager --unit=openvpn@openvpn ``` Tu peux bien évidemment censurer les éventuels éléments confidentiels tels qu’une adresse IP. – AnonymousCoward ---
**Author:** ![Cortexx06](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/e95f7d/32.png) [@Cortexx06](https://www.debian-fr.org/u/Cortexx06)\ **Post date:** [Février 21, 2022, 5:20 UTC](https://www.debian-fr.org/t/partage-de-connexion-sim900-vpn/85911/32 "2022-02-21T17:20:32Z")
Merci, enfaite openvpn ne se lancer tout simplement pas au démarrage… lol Bon par contre depuis quelque jours plus rien ne marche … pourtant j’ai rien changé, il y a 2 3 jours je fait un test en réel aucun problème et la plus moyen, des que le vpn ce connecte sur le orangepi client je perd la connexion ce truc va me rendre fou Enfaite j’ai remarqué que la connexion tun0 me donne en ip 192.168.2.6 masque 255.255.255.0 destination 192.168.2.6 et c’est le dernier qui me dérange car il devrait être 192.168.2.1 je sais que cela ce configure dans le server au niveaux du /openvpn/ccd mais rien ne change quand je modifie… ---
**Author:** ![AnonymousCoward](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@AnonymousCoward](https://www.debian-fr.org/u/AnonymousCoward)\ **Post date:** [Février 21, 2022, 5:39 UTC](https://www.debian-fr.org/t/partage-de-connexion-sim900-vpn/85911/33 "2022-02-21T17:39:20Z")
Ce qui se configure dans le sous-répertoire ccd **sur le serveur VPN** , c’est la configuration du / des sous-réseau(x) accessible(s) derrière chaque **client du VPN**. Notamment la directive / option `iroute` . Pour bien voir là où cela peut coincer, il nous faudrait les fichiers de configuration d’OpenVPN coté serveur puis côté client. Y compris le sous-répertoire ccd . Il est bien évidemment possible de censurer les éléments sensibles. Et si tu veux nous montrer le problème de routage, tu peux utiliser la commande : ```auto ip -4 route ls ``` Mais oui, il est tout à fait possible que cet ultime problème vienne d’une mauvaise configuration du routage dans un fichier de configuration. Ce ne serait ni la première fois ni la dernière. – AnonymousCoward ---
**Author:** ![Cortexx06](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/e95f7d/32.png) [@Cortexx06](https://www.debian-fr.org/u/Cortexx06)\ **Post date:** [Février 25, 2022, 8:34 UTC](https://www.debian-fr.org/t/partage-de-connexion-sim900-vpn/85911/34 "2022-02-25T20:34:40Z")
Bon à priori tout fonctionne… Donc pour « recapepete » coté orange pi : il y a une carte Sim900 une alim 5v avec indicateur de tension branché sur une alim 12v 2A un convertisseur ttl \>usb un carte sim free mobile le fonctionnement est le suivant : le orange pi démarre se Connecte à la 2g (le sim900 ne gère que la 2g mais pour mon projet cela suffit) pour ce faire il exécute un script qui lance le fichier RNET dans le dossier /etc/ppp/peers : > #imis/internet is the apn for idea connection > connect « /usr/sbin/chat -v -f /etc/chatscripts/gprs -T free » > > #communication port: > /dev/ttyUSB0 > > #Baudrate > 115200 > > #Assumes that your IP address is allocated dynamically by the ISP. > noipdefault > > #Try to get the name server addresses from the ISP. > #usepeerdns > > #Use this connection as the default route to the internet. > defaultroute > > #Makes PPPD « dial again » when the connection is lost. > persist > > #Do not ask the remote to authenticate. > noauth > > #No hardware flow control on the serial link with GSM Modem > nocrtscts > > #No modem control lines with GSM Modem > local Ensuite il ce Connecte via openvpn : > rappel commande pour lancer au démarrage > update-rc.d openvpn enable > mon fichier client : > dev tun > tls-client > topology subnet > comp-lzo yes > remote Ip-de-ma-box port > > #The « float » tells OpenVPN to accept authenticated packets from any address, > #not only the address which was specified in the --remote option. > #This is useful when you are connecting to a peer which holds a dynamic address > #such as a dial-in user or DHCP client. > #(Please refer to the manual of OpenVPN for more information.) > > #float > > #If redirect-gateway is enabled, the client will redirect it’s > #default network gateway through the VPN. > #It means the VPN connection will firstly connect to the VPN Server > #and then to the internet. > #(Please refer to the manual of OpenVPN for more information.) > > redirect-gateway > > #dhcp-option DNS: To set primary domain name server address. > #Repeat this option to set secondary DNS server addresses. > > dhcp-option DNS 8.8.8.8 > > pull > > proto udp > script-security 2 > > ca /etc/openvpn/ca.crt > > reneg-sec 0 > > auth-user-pass /etc/openvpn/pass au niveaux des IPTABLES : > root@orangepizero:~# iptables --line-numbers -nvx -t nat -L POSTROUTING > Chain POSTROUTING (policy ACCEPT 1 packets, 48 bytes) > num pkts bytes target prot opt in out source destination > 1 0 0 MASQUERADE all – \* eth0 192.168.2.0/24 0.0.0.0/0 /\* openvpn-nat-rule \*/ > 2 732 108223 MASQUERADE all – \* wlan0 0.0.0.0/0 0.0.0.0/0 > 3 995 103985 MASQUERADE all – \* tun0 0.0.0.0/0 0.0.0.0/0 > 4 0 0 MASQUERADE all – \* ppp0 0.0.0.0/0 0.0.0.0/0 Voila pour la partie orange pi ---
**Author:** ![Cortexx06](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/e95f7d/32.png) [@Cortexx06](https://www.debian-fr.org/u/Cortexx06)\ **Post date:** [Février 25, 2022, 8:40 UTC](https://www.debian-fr.org/t/partage-de-connexion-sim900-vpn/85911/35 "2022-02-25T20:40:30Z")
Concernant Le Nas synology : server.conf : > push « route 192.168.1.0 255.255.255.0 » > push « route 192.168.2.0 255.255.255.0 » > dev tun > topology subnet > client-to-client > client-config-dir ccd > > comp-lzo > route 10.10.10.0 255.255.255.0 192.168.2.6 > push « route 10.10.10.0 255.255.255.0 » > le reste c’est d’origine ccd : > ifconfig-push 192.168.2.6 255.255.255.0 > push « route 192.168.1.0 255.255.255.0 192.168.2.1 » > iroute 10.10.10.0 255.255.255.0 il faut aussi modifié la ligne dans : /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf: > overwriteccfiles=false car sinon le fichier ccd est effacé. concernant les route sur synology : > ip -4 route add 10.10.10.0/24 via 192.168.2.1 dev tun0 pour les iptables : > iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o tun0 -j MASQUERADE ---
**Author:** ![AnonymousCoward](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@AnonymousCoward](https://www.debian-fr.org/u/AnonymousCoward)\ **Post date:** [Février 26, 2022, 10:58 UTC](https://www.debian-fr.org/t/partage-de-connexion-sim900-vpn/85911/36 "2022-02-26T10:58:51Z")
Il y a beaucoup trop de « masquerade » (c’est à dire du SNAT) à mon goût. Ceci dit, si cela fonctionne c’est le principal. Par contre, est-ce que tu pourrais modifier ton post pour encadrer le texte en commençant par ```text puis en terminant par : ``` Cela rend les choses bien plus faciles à lire. Eventuellement, rempacer `text` par `shell` , `python` , `html` etc suivant le type de texte. – AnonymousCoward [Page précédente](https://www.debian-fr.org/t/partage-de-connexion-sim900-vpn/85911.md?page=1)