10 idées reçues sur les régions MeshCore

Oscar Bravo
9 juillet 2026
MeshCore

Il y a beaucoup d’incompréhension sur le système de régions, et pour certains vouloir régionaliser c’est vouloir bloquer le trafic. Il en résulte un retard de leur mise en place dans certaines zones, et des difficultés ensuite pour juguler intelligemment le trafic lorsqu’il arrive massivement d’autres pays.

Il faut bien comprendre que le système de régions est avant tout là pour essayer de limiter autant que possible le trafic qui n’a pas vocation à être relayé plus loin que nécessaire. Ainsi ça laisse plus de temps radio pour les messages qui eux ont besoin d’aller plus loin.

Avant d’aller plus loin, tous les répéteurs au moins en version 1.14 peuvent déjà utiliser le système de régions, il n’y a aucun inconvénient à les mettre en place même si votre répéteur n’est pas encore à jour (mais pensez-y quand même, vous allez voir plus loin que ça serait une bonne idée).

Si vous ne l’avez pas déjà fait, aller lire la page sur le sujet. Elle est régulièrement mise à jour pour tenir compte des évolutions de firmwares et des retours d’expérience que nous engrangeons.

Idée reçue n°1 : je laisse mon répéteur avec juste la région « * » comme ça je laisse passer tout le trafic, je ne bride rien.

La région « * » ne veut pas dire « tout le trafic », mais « le trafic non associé à une région ». En informatique l’étoile a tendance à vouloir dire « tout », donc c’est trompeur, le problème est remonté aux développeurs, mais comme ça n’est que « cosmétique » ça n’est malheureusement pas urgent à corriger. Bref, en ne spécifiant pas de région supplémentaire sur votre répéteur au lieu de tout autoriser, vous BLOQUEZ les messages des gens qui veulent réduire l’occupation inutile du réseau lorsque eux utilisent des régions.

Quand moi je décide de taguer mon canal #mes-potes-de-loire-atlantique avec la région « fr-44 » que j’ai sur mes répéteurs, si les autres répéteurs autour de moi en Loire Atlantique n’ont pas cette région de configurée, mais qu’ils ont juste « * », et bien malheureusement les messages ne seront pas relayés. Je vais donc devoir supprimer le tag de cette région sur mon canal et désormais quand j’écrirais à mes amis, le message sera inutilement relayé à toute la France, remontera même en Angleterre… et occupera du temps de réseau pour rien. On le rappelle, chaque répéteur n’a le droit de répéter qu’environ 300 messages par heure. Autant qu’ils soient pertinents à relayer !

Solution : ajouter systématiquement sur vos répéteurs les régions relatives au lieu ou est implanté votre répéteur. Consultez notre générateur de régions si besoin.

Idée reçue n°2 : si je mets des régions sur mon répéteur, ça va empêcher les gens éloignés de se contacter.

Mettre des régions (autorisées) sur un répéteur n’a en pratique AUCUN impact de filtrage par rapport à ne pas en mettre, au contraire. Comme on l’a vu plus haut, « * » s’il est seul, n’autorise que le trafic sans région alors que « * + quelques régions » autorise le trafic sans région + celui tagué avec ces régions. C’est tout.

C’est la configuration des compagnons qui va impacter l’usage de ces régions. Chacun est libre ensuite :

  • De ne pas utiliser de régions s’il s’en fiche totalement, et son trafic sera systématiquement relayé partout où c’est possible. Nous déconseillons fortement cette approche vous vous en doutez.
  • De simplement taguer la région la plus pertinente pour ses messages sur les canaux. Par exemple rien sur Public car il veut que ça aille le plus loin possible, mais fr-56 pour les messages sur les canaux qui n’ont pas vocation à dépasser le Morbihan. C’est une première excellente approche car elle limite une bonne partie du trafic inutile.
  • Taguer systématiquement les canaux. Même Public, afin de limiter intelligemment la portée de ses messages.
  • Définir en plus une région par défaut à son compagnon, typiquement « fr » ainsi ses annonces (adverts) et tentatives de contacts (lors du 1er envoi d’un message direct par exemple) n’iront pas au delà du pays. Si vous habitez loin d’une frontière et/ou que vous n’avez aucune velléité à entrer en contact avec des personnes hors de France, faites-le, vous laisserez ainsi plus de temps d’émission réseau pour les autres. A chaque fois pensez que c’est symétrique : si les Italiens font de même ils n’iront pas occuper inutilement le temps réseau de votre répéteur en France.

Idée reçue n°3 : je suis quasi tout seul dans mon coin, les régions n’ont aucun intérêt.

Aujourd’hui vous êtes peut-être tout seul, isolé au centre de la France et vous rêvez de pouvoir entendre les discussions du maillage anglais ou allemand, donc restreindre quoi que ce soit n’a aucun sens pour vous.

Déjà rappelez-vous l’idée n°1… vous n’allez rien restreindre en mettant en place des régions.

A l’inverse, le jour où vous allez être en contact avec le reste du maillage en place, vous allez instantanément vous prendre l’intégralité des échanges. D’ici quelques semaines ça voudra peut-être dire que via l’ajout d’un seul répéteur bien placé vous pouvez passer de 3 messages par jour à 30 000 si personne ne fait rien et n’a rien anticipé en terme de régions.

Pensez aussi que si vous ne voyez personne autour de vous, c’est peut-être justement parce que eux en taguant systématiquement toutes leurs annonces et messages, … votre répéteur (sans régions configurées) les bloque !

Idée reçue n°4 : tant que les répéteurs sont en dessous des 10% de temps d’émission autorisés il n’y a aucune urgence à s’embêter avec tout ça.

Les répéteurs appliquent ces 10% de la manière suivante : lorsqu’ils émettent, ils mesurent le temps mis par cette émission, et quoi qu’il se passe ils attendent ensuite le temps nécessaire pour s’assurer que ces 10% ne seront jamais dépassés (source). Donc pour chaque message transmis (un peu plus d’une seconde en moyenne), le répéteur va attendre ensuite 9 secondes. Si d’autres messages arrivent entre temps et doivent être répétés, ils seront mis en file d’attente.

Donc à chaque fois que du trafic non nécessaire doit être réémis par votre répéteur, il l’empêche pendant 10 secondes d’acheminer un message légitime. Vous pouvez donc vous retrouver dans des situations ou – même si lissé sur une heure vous êtes en dessous de ces fameux 10% – pour un simple échange local vous deviez attendre plusieurs secondes parce que votre répéteur vient juste de transmettre un autre message sans importances : annonce de répéteur à 2000km de vous, message en langue étrangère qui n’a pas de raison d’être relayé jusqu’à vous, ou même un simple message destiné au canal #une-commune-a-200km-de-chez-vous, canal que personne autour du répéteur n’aura sur ses compagnons. Ensuite seulement il pourra s’occuper de votre message local.

La file d’attente priorise les messages locaux par rapport à ceux venant de plus loin et aux annonces, c’est une bonne chose, mais vous pouvez régulièrement prendre 9 ou 10 secondes de délai si vous tombez au mauvais moment.

Idée reçue n°5 : créer une région pour l’Europe est stupide car le réseau ne peut pas supporter un tel trafic.

Depuis aujourd’hui, nous recommandons l’ajout de la région « eu » sur les répéteurs en plus des autres conseillées auparavant.

Sujet épineux et qui a fait l’objet de nombreuses discussions. Oui, clairement, le réseau LoRa ne peut pas supporter le trafic d’un maillage à l’échelle européenne. Oui créer une région pour l’Europe entière semble idiot car à partir du moment où on l’utilise on va spammer massivement le réseau.

Mais il faut avant tout réfléchir à l’alternative qui se produit si on ne le fait pas : l’adoption du système de régions est ralentie car beaucoup pensent que ça va les empêcher d’échanger avec le pays voisin. Il y a notamment tous les limitrophes (« j’habite en France, je travaille en Suisse » par exemple) qui veulent pouvoir dépasser les frontières et les radio-amateurs qui aiment bien l’idée de pouvoir échanger le plus loin possible. Et comme il n’y a – actuellement – pas de moyen de spécifier plusieurs régions en même temps pour un message envoyé sur un canal, que va-t-il se passer ? De nombreuses personnes refuseront l’usage des régions, et écriront à tout le réseau sans distinction, ce qui peut à terme aller même au delà des frontières de l’Europe.

Le besoin le plus crucial est donc l’incitation à l’usage des régions, quelles qu’elles soient, plutôt que de ne rien faire. Il sera par la suite (ou en cas de crise par exemple) plus facile de supprimer ponctuellement une région trop large sur quelques répéteurs clés surchargés plutôt que de risquer de bloquer tout le monde si personne n’a pris l’habitude d’utiliser les régions.

Globalement ça ne change rien, si ce n’est qu’on sépare le trafic qui initialement n’avait pas de région et qui était mélangé entre « rien de paramétré » et « moi là j’ai envie d’aller loin » vers un trafic clairement identifié Europe, avec l’espoir que cette région soit utilisée en connaissance de cause, ce qui laisse donc de meilleures possibilités pour venir bloquer le « rien de paramétré qui vient de loin ».

C’est d’ailleurs l’ajout d’une fonctionnalité géniale dans la version 1.16 des firmwares qui vient appuyer cette suggestion de créer la région Europe : on peut désormais bloquer le trafic « sans région qui vient de plus de X sauts ». La commande set flood.max.unscoped 5 appliquée sur un répéteur lui permet par exemple de laisser passer le trafic « local » (jusqu’à 5 sauts) pour nos amis autour de nous qui commencent tout juste à découvrir MeshCore et qui n’ont pas encore appris toutes les subtilités des régions à pouvoir malgré tout échanger. Par contre le trafic sans intérêt qui provient de loin par des gens qui n’ont rien paramétré sera bloqué.
A l’inverse si quelqu’un choisit explicitement de taguer un message avec la région « eu » on peut supposer qu’il a compris ce qu’il faisait et qu’il a bien besoin de cette région très large pour essayer d’acheminer son message qui ne passerait pas avec une région plus petite.

Il faut juste que chacun comprenne qu’il ne faut pas définir « eu » comme région par défaut pour tout, ni pour son répéteur, ni son compagnon, ni sur tous ses canaux.

L’avenir nous dira si les utilisateurs seront suffisamment disciplinés pour ne pas faire n’importe quoi, et peut-être que d’ici là nous aurons d’autres solutions techniques pour écrire au delà des frontières et éviter cette région Europe.

Idée reçue n°6 : vu qu’on peut désormais bloquer les messages venant de loin, plus besoin de se prendre la tête avec tout ce bazar de régions.

Avec la commande vue au dessus (set flood.max.unscoped) on peut en effet facilement bloquer le trafic provenant de plus de X sauts sans passer par le système de régions. Malheureusement ça ne dit rien la pertinence des messages en question ni de leur géolocalisation, leur langue…

Prenons un exemple concret : Vous êtes proches de la côte ouest de la France, sur un endroit plat, et 5-6 sauts c’est en moyenne ce qu’il faut pour couvrir correctement votre commune et chaque commune limitrophe. Peut-être que ça suffit, que vous n’avez pas besoin de contacts plus éloignés.

Sauf que par exemple, en 2 sauts vous rejoignez un répéteur placé sur la façade océanique, que le 3è vous emmène à Lorient, le 4è dans le Finistère et le 5è en Angleterre. Ne pensez pas qu’il s’agisse d’un cas isolé. Nous avons régulièrement des liens directs entre un répéteur d’une petite montagne des Pyrénées Atlantiques (Ursuya) et Lorient en direct !

Certes avec un niveau de sauts « unscoped » à un seuil faible, le trafic généré, même provenant de géographiquement loin ne sera pas très élevé. Par contre à l’inverse vous vous coupez (et empêchez les autres utilisateurs) de la possibilité d’aller plus loin pour du trafic potentiellement intéressant. Par exemple avec 5 sauts vous n’aurez probablement pas une couverture au niveau de votre département entier. Hors en situation de crise, ou pour joindre de la famille un peu éloignée, c’est dommage de se priver (et de priver les autres) de ces possibilités alors que les outils techniques existent pour le faire.

Idée reçue n°7 : les messages directs ne sont pas impactés par les régions

Malheureusement si. Le premier échange, qui passe forcément par la « recherche » du chemin pour rejoindre le destinataire est un message de type flood (vers tout le réseau). Il est donc impacté par le système de régions. Si vous avez mis en place une région par défaut « fr » sur votre compagnon et que les répéteurs autour de vous n’ont pas cette région, ça ne fonctionnera pas. Il est donc impératif que les répéteurs intègrent ces régions.

Techniquement si vous connaissez les identifiants des répéteurs par lesquels le message doit passer, que vous les rentrez à la main, vous pouvez échanger même au delà des frontières, sans vous préoccuper des régions. Mais en pratique, ça va être assez compliqué, notamment pour les échanges longue distance.

Idée reçue n°8 : Public c’est trop cool pour rencontrer des gens !

Public c’est le canal par défaut sur tous les compagnons, donc c’est forcément par là que que tout le monde commence. Problème, c’est aussi là qu’on trouve justement les messages de tous ceux qui débutent, qui postent « test » à longueur de journée et qui n’ont pas réglé de régions. C’est donc un peu le tout venant, en toutes langues, où les communications sont asymétriques et partielles (classiquement : vous recevez une partie seulement des messages donc la discussion est incompréhensible, vos réponses ne sont pas entendues).

Nous recommandons donc la création d’un canal dédié pour la France. Historiquement nous recommandons #france, que vous taguez alors avec la région « fr ». Le sud-est de la France utilise également #fr. Chacun fait comme il veut, rien ne vous empêche de rejoindre les deux et de voir où est-ce qu’il y a le plus de trafic.

Idée reçue n°9 : Si on ne veut pas supporter les messages des pays étrangers, il suffit de supprimer le canal Public et de discuter sur #france.

A titre individuel, supprimer le canal Public est en effet une bonne idée pour ne pas subir le trafic souvent sans queue ni tête venant de partout. L’asymétrie des liens (notamment lors des épisodes de propagation ionosphérique) a tendance en effet à faire qu’on ne reçoit que la moitié d’une discussion entre des personnes très loin. Le canal Public devenant incohérent, avec des centaines de messages par jour, autant le supprimer et se recentrer sur des canaux plus locaux.

Malheureusement, supprimer le canal de votre compagnon ne supprime pas le trafic au niveau des répéteurs, qui continuent donc à relayer des messages qui ne servent plus à rien s’il n’y a plus de compagnons autour pour les recevoir.

C’est pour ça qu’il est impératif de prendre le problème à la racine et de faire en sorte que les répéteurs ne répètent que le trafic pertinent.

Idée reçue n°10 : Gaulix veut imposer SA vision franco-française du réseau, avec SES paramètres, sans prendre en compte les besoins individuels ni ce que font les autres pays.

Tout à fait ! Nous préparons même un coup d’état pour 2028 afin de prendre le contrôle de l’intégralité des réseaux de communication, mais chut ça reste entre nous 🤪 MOUHAHA

Plus sérieusement, je pense que si vous avez lu les 9 points précédents vous avez maintenant compris que c’est absolument l’inverse. Notre idée première est de donner des recommandations (que chacun est libre de suivre ou nous) afin de guider ceux et celles qui ne savent pas trop ce qu’il faut faire ni pourquoi. Notre but est de permettre à chacun de profiter au mieux d’un réseau stable, durable dans le temps, qui permette à la fois d’aller le plus loin possible ET d’assurer une couverture plus locale sans faille. Et pour ça il faut des directives. Si personne ne le fait on aura alors le reproche inverse : « chacun fait son truc dans son coin, il n’y a aucune cohérence, on ne peut pas envoyer un message à 30km parce qu’ils ont des réglages différents…

Alors nous testons, nous échangeons justement avec les autres pays, étudions leurs pratiques, leurs résultats, récupérons leurs et nos retours d’expérience, conseils, et nous faisons des recommandations. Ces recommandations ne sont pas figées dans le marbre, elles évoluent au fil des nouveautés des firmwares et de la progression du réseau sur le territoire français et celui de nos voisins.

Alors quelles sont les actions concrètes ?

  1. ajoutez vraiment les régions sur tous vos répéteurs. Rappelez-vous, ça n’a aucun impact négatif, au contraire.
  2. définissez la région « fr » comme région par défaut sur vos répéteurs
  3. définissez la région « fr » comme région par défaut sur vos compagnons
  4. taguez tous vos canaux avec la région la plus pertinente. Pas besoin de mettre « fr » pour les messages sur #macommune. Pour le canal Public, à vous de voir, mais dans la majorité des cas « fr » devrait largement suffire, sauf si vous voulez être entendus hors de nos frontières (par des gens qui ne lisent probablement pas le français… adaptez donc vos messages).
  5. Mettez à jour vos répéteurs en version au moins 1.16 et ajoutez en ligne de commande set flood.max.unscoped 5 Vous êtes libres d’adapter ce 5 bien entendu, ainsi vous conserverez les messages des gens autour de vous qui n’ont pas encore réglé de région (et vous pourrez leur expliquer qu’il faut le faire, notamment sur Public au début) tout en bloquant les messages de personnes au loin qui n’ont pas explicitement demandé à avoir une telle portée pour leurs messages.
  6. Essayez de migrer vos conversations de Public vers des canaux plus pertinents, typiquement #france pour commencer, mais aussi des canaux plus locaux, tagués avec des régions plus petites.
  7. Rester impliqué sur ce sujet, en venant voir les retours et recommandations que nous faisons sur ce site, en mettant également à jour vos répéteurs car MeshCore évolue encore régulièrement sur ce point.

Il reste encore des points non abordés, des questions en suspend, mais c’est déjà un gros morceau, et le principal est là pour l’instant. Donc… à suivre…

How to re-install your TOS?

Instruction

Applicable model: All TNAS models

If you wish to re-install the TOS system, or your TNAS encounters a failure and needs to reinstall TOS, please refer to the following guidelines:

Method 1: If your TOS system is still working

1. Log in to TOS and go to TOS Desktop> Control Panel> General Settings> Update and Restore> Backup and Restore;

2. Tick « Backup system configuration » to back up your system configuration;

3. Go to TOS Desktop> Control Panel> General Settings> Update and Restore> Restore to Factory Default;

4. Tick « Restore to factory default », and then click « Apply »; your system will be erased, but the data on the hard drives will not be deleted;
5. Refresh the browser page, and follow guide on the page to install a new TOS;
6. If the page refresh fails, please use TNAS PC to search for your TNAS device; Then select the device and click « Login »; Follow the web page to install the new TOS;
7. After the system installation is complete, log in to TOS and go to TOS desktop> Control Panel> General Settings> Update and Restore> Backup and Restore to restore your backed up system configuration.

Note: After installation-restart-setting the account password, if it prompts to initialize the raid, please do not continue and contact our support team.

Method 2: If your TOS system encounters a malfunction and cannot work properly

1. Turn off your TNAS device;
2. Remove all hard drives;
3. Turn on your TNAS;
4. Wait about two minutes, after the network light is on, insert your hard drives;
5. Use TNAS PC to search for your TNAS device;
6. Select the device and click « Login »; Follow the instructions on the web page to install the new TOS system.

Note: Reinstalling the system normally will not delete the data on your hard drives, BUT to prevent accidents,it is recommanded to backup your data before reinstalling. If you have any questions when operating the above steps, please contact us in time.
Note: After installation-restart-setting the account password, if it prompts to initialize the raid, please do not continue and contact our support team.

Chaine OBS Studio + PortsDown DATV QO-100

Test en cours de « streaming » via OBS Studio vers script FFmpeg pour encodage SR 250 + DVBS2 et enfin envoie de ce dernier après traitement via UDP sur le Raspberry Portsdown. 

le Portsdown télécommandé en émission sur 437 MHZ et reçu sur le MINITIOUNE à SR de 250 en DVBS2. 

Reste plus qu’a raccorder le LIMESDR mini à la chaîne des amplificateurs + Parabole pour monter en DATV sur le satellite QO-100

Mais avant toute chose finir de réaliser le PA de 70 Watts ….. 

 

  • – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Qu’est ce qu’un reverse-proxy ?

La sécurisation des serveurs Web représente un challenge de taille pour les administrateurs réseaux. En effet, toutes les actions effectuées en ligne tels que l’utilisation d’internet et l’envoi d’emails passent obligatoirement par le réseau public. De ce fait, une simple connexion à internet suffit à rendre ces systèmes vulnérables aux logiciels malveillants.. C’est la raison pour laquelle, un composant réseau appelé reverse-proxy (proxy inverse) est utilisé.

Qu’est ce qu’un reverse-proxy ?

Pour vous résumer, le reverse-proxy est un intermédiaire de communication réseau recevant des requêtes afin de les transmettre à l’ordinateur cible. Lorsque l’on parle de réseau d’entreprise, on parle souvent de reverse-proxy car ce système est largement utilisé afin de fournir un accès sécurisé et contrôlable par les utilisateurs.

Un serveur proxy a pour fonction de canaliser toutes les requêtes du réseau interne pour les transmettre sur le serveur. De plus, et afin d’économiser de la bande passante, les serveurs proxy sont généralement configurés afin de pouvoir mettre en cache les données fréquemment demandées, ce qui limite le nombre de requêtes utilisées pour les afficher.

Alors qu’un Forward-proxy protège les appareils clients des mauvaises influences du réseau public, un reverse proxy opère exactement dans le sens contraire. En effet, ce système sert de sécurité supplémentaire et protège les serveurs Web.

Fonctionnement d’un reverse-proxy

Protégé par un parefeu, les serveurs reverse-proxy se trouve en général dans un réseau interne. Il s’agit de la seule connexion entre internet et le réseau privé. Toutes les requêtes passent par ce réseau avant d’être transférées au systèmes ciblés. Voyez ci-dessous les différentes applications d’un serveur reverse-proxy:

  • Anonymisation: Le reverse-proxy intercepte toutes les requêtes avant de les transmettre au système ciblé.
  • Encodage et protection: Le reverse-proxy propose l’installation de systèmes de contrôle comme un antivirus afin de filtrer les paquets reçus et renforcer la protections des serveurs.
  • Répartition de charge: Il permet la mise en place d’un répartiteur de charge, en anglais load-balancing. Ce système empêche la surcharge d’un système. En cas de panne d’un serveur, ce système va redistribuer les requêtes entrantes sur d’autres serveurs disponibles.
  • Caching: Il permet d’accélérer la vitesse du service grâce à son système de mise en cache.
  • Compression: un serveur reverse-proxy peut aussi compresser les données entrantes et sortantes. Ce type de serveur est souvent utilisé en combinaison avec Apache et nginx.

Comment configurer Apache comme Reverse-proxy ?

Il est possible d’installer un serveur reverse-proxy sur un serveur Apache. En effet, Apache dispose de modules d’extension permettant d’installer la fonction proxy. Ce dernier peut être installer rapidement grâce à quelques lignes de codes. Ci-dessous, le guide va vous expliquer comment installer un reverse-proxy sur un système d’exploitation Ubuntu comprenant un serveur Apache.

Installer le module proxy d’Apache

Afin de pouvoir utiliser un serveur Apache comme reverse-proxy, il vous faudra le module mod_proxy. Ce module permettra d’améliorer de façon considérable les fonctionnalités de bases, mais peut aussi être accentué par diverses extensions complémentaires:

  • mod_proxy_http: dispose de toutes les fonctionnalités pour les requêtes HTTP et HTTPS.
  • mod_proxy_ftp: nécessaire afin de disposer des fonctions de proxy pour les requêtes FTP.
  • mod_proxy_connect: dispose des fonctionnalités proxy pour le tunnel SSL.
  • mod_cache, mod_disk_cache et mod_mem_cache: installe les fonctions de cache afin de stocker le contenu sur la mémoire cache de votre serveur Apache.
  • mod_proxy_html: active la réécriture des liens
  • mod_headers: permet la modification des entêtes HTTP
  • mod_deflate: permet la compression

Afin de pouvoir tout installer, la ligne de commande est la suivante:

$ sudo apt-get install libapache2-mod-proxy-html

Comment activer les modules requis ?

Vous pouvez activer les modules requis d’Apache en utilisant la commande a2enmod.  Si vous désirez désactiver un module actif, il vous suffira d’utiliser la commande a2dismod. Afin de charger les modulesmod_prox et mod_proxy_http, tapez les commandes suivantes:

$ sudo a2enmod proxy
$ sudo a2enmod proxy_http

Une fois les modules activés, il est nécessaire de redémarrer le serveur Apache:

$ sudo apache2 reload

Comment créer le fichier de configuration ?

Afin que le serveur reverse-proxy accepte les requêtes et puissent les transmettre aux bons serveurs sur votre réseau, il faut désactiver le fichier de configuration 000-default.conf se trouvant dans le répertoire /etc/apache2/sites-enabled et le remplacer par un fichier hôte virtuel comme example.conf. Il est préférable de créer un fichier hôte pour chaque serveur cible. Chaque fichier hôte doit avoir sa propre adresse ip:

<VirtualHost *:80>
ServerName domaine.td
ServerAlias www.domaine.td
ProxyRequests Off
ProxyPass / http://123.456.7.89/
ProxyPassReverse / http://123.456.7.89/
</VirtualHost>

Les instructions pour le fonctionnement de la fonction proxy sont définies par la commande <VirtualHost>. Dans le fichier, vous y trouverez les commandes suivantes:

  • ServerName: Cette commande défini le nom du premier serveur sur internet. Sur l’exemple ci-dessus, le serveur Apache est programmé pour accepter toutes les requêtes du domaine “domaine.td“.
  • ProxyPass: Cette commande défini l’adresse cible pour la redirection.
  • ProxyPassReverse: Cette balise va réécrire l’en-tête des réponses du serveur pour qu’elles puissent être en accord avec le serveur proxy.

L’exemple ci-dessus dispose aussi de deux autres commandes qui sont les suivantes:

  • ServerAlias: cette commande va permettre d’autoriser un nom différent pour le serveur cible.
  • ProxyRequest: Cette commande va permettre de refuser l’utilisation du serveur Apache comme un proxy-forward.

Si vous avez bien défini les règles, il vous suffit d’activer la configuration par le biais du terminal de commande:

$ sudo a2ensite example.conf

Conclusion

Vous êtes désormais  en mesure de savoir ce qu’est un serveur Reverse-proxy et faire la différence entre un serveur reverse-proxy et un proxy-forward.

Routeur Hamnet sur OrangePi 0 / Linux 

Source : Routeur Hamnet sur OrangePi 0 / Linux | F5NLG – SvxLink –

 

 

La configuration choisie est internet via le wifi , accès au réseau Hamnet sur le Xspotnik ou spotnik , Internet (et VPN) via le Wifi , sortie routeur sur la RJ45 ! d’autres solutions existen…

1er Partie le VPN et la route pour le réseau 44 :

Pré requis , obtenir les informations pour le réseau Hamnet auprès de F6CNB ou F1TZV.

  • adresse IP routeur    : 44.168.X.Y
  • adresse IP gateway   : 44.168.X.Z
  • nom d’utilisateur      : f4xxx-routeur
  • mot de passe              : SuperMotDePasseHyperComplique
  • serveur pptp              : hamnet.fr

1/ étape ajouter le vpn pptp

apt-get install pptp-linux 

2/ le fichier VPN HAMNET à créer

mcedit /etc/ppp/peers/HAMNET

pty "pptp hamnet.fr --nolaunchpppd --nobuffer --timeout 10"
  name f4xxx-router
  persist
  holdoff 30
  mtu 1400
  maxfail 0
  remotename pptp
  require-mppe-128
  refuse-eap
  nobsdcomp
  nodeflate
  file /etc/ppp/options.pptp
  ipparam HAMNE

3/ modifier le fichier /etc/ppp/chap-secret

mcedit /etc/ppp/chap-secret

# Secrets for authentication using CHAP
# client                    server                                    secret                                          IP addresses

f4xxx-router           pptp           SuperMotDePasseHyperComplique                           *

4/ tester que ça fonctionne :

pon HAMNET

en cas de soucis : pon HAMNET debug dump logfd 2 nodetach qui donne le log a l’écran.

tapez ifconfig : vous devez avoir une interface ppp0 monté avec les adresses 44.168.X.Y et 44.168.X.Z

5/ on arrête le vpn :

poff HAMNET 

6/ rajouter une route dans /etc/ppp/ip-up

mcedit /etc/ppp/ip-up

#!/bin/sh
#
# This script is run by the pppd after the link is established.
# It uses run-parts to run scripts in /etc/ppp/ip-up.d, so to add routes,
# set IP address, run the mailq etc. you should create script(s) there.
#
# Be aware that other packages may include /etc/ppp/ip-up.d scripts (named
# after that package), so choose local script names with that in mind.
#
# This script is called with the following arguments:
# Arg Name Example
# $1 Interface name ppp0
# $2 The tty ttyS1
# $3 The link speed 38400
# $4 Local IP number 12.34.56.78
# $5 Peer IP number 12.34.56.99
# $6 Optional « ipparam » value foo

# The environment is cleared before executing this script
# so the path must be reset
PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin
export PATH

# These variables are for the use of the scripts run by run-parts
PPP_IFACE= »$1″
PPP_TTY= »$2″
PPP_SPEED= »$3″
PPP_LOCAL= »$4″
PPP_REMOTE= »$5″
PPP_IPPARAM= »$6″
export PPP_IFACE PPP_TTY PPP_SPEED PPP_LOCAL PPP_REMOTE PPP_IPPARAM

route add -net 44.0.0.0 netmask 255.0.0.0 dev ppp0

# as an additional convenience, $PPP_TTYNAME is set to the tty name,
# stripped of /dev/ (if present) for easier matching.
PPP_TTYNAME=`/usr/bin/basename « $2″`
export PPP_TTYNAME

# If /var/log/ppp-ipupdown.log exists use it for logging.
if [ -e /var/log/ppp-ipupdown.log ]; then
exec > /var/log/ppp-ipupdown.log 2>&1
echo $0 $@
echo
fi

# This script can be used to override the .d files supplied by other packages.
if [ -x /etc/ppp/ip-up.local ]; then
exec /etc/ppp/ip-up.local « $@ »
fi

run-parts /etc/ppp/ip-up.d \
–arg= »$1″ –arg= »$2″ –arg= »$3″ –arg= »$4″ –arg= »$5″ –arg= »$6″

# if pon was called with the « quick » argument, stop pppd
if [ -e /var/run/ppp-quick ]; then
rm /var/run/ppp-quick
wait
kill $PPPD_PID
fi

7/ et enfin supprimer la route dans /etc/ppp/ip-down

mcedit /etc/ppp/ip-down

#!/bin/sh
#
# This script is run by the pppd _after_ the link is brought down.
# It uses run-parts to run scripts in /etc/ppp/ip-down.d, so to delete
# routes, unset IP addresses etc. you should create script(s) there.
#
# Be aware that other packages may include /etc/ppp/ip-down.d scripts (named
# after that package), so choose local script names with that in mind.
#
# This script is called with the following arguments:
# Arg Name Example
# $1 Interface name ppp0
# $2 The tty ttyS1
# $3 The link speed 38400
# $4 Local IP number 12.34.56.78
# $5 Peer IP number 12.34.56.99
# $6 Optional « ipparam » value foo

# The environment is cleared before executing this script
# so the path must be reset
PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin
export PATH

# These variables are for the use of the scripts run by run-parts
PPP_IFACE= »$1″
PPP_TTY= »$2″
PPP_SPEED= »$3″
PPP_LOCAL= »$4″
PPP_REMOTE= »$5″
PPP_IPPARAM= »$6″
export PPP_IFACE PPP_TTY PPP_SPEED PPP_LOCAL PPP_REMOTE PPP_IPPARAM

route del -net 44.0.0.0 netmask 255.0.0.0 dev ppp0

# as an additional convenience, $PPP_TTYNAME is set to the tty name,
# stripped of /dev/ (if present) for easier matching.
PPP_TTYNAME=`/usr/bin/basename « $2″`
export PPP_TTYNAME

# If /var/log/ppp-ipupdown.log exists use it for logging.
if [ -e /var/log/ppp-ipupdown.log ]; then
exec >> /var/log/ppp-ipupdown.log 2>&1
echo $0 $@
echo
fi

# This script can be used to override the .d files supplied by other packages.
if [ -x /etc/ppp/ip-down.local ]; then
exec /etc/ppp/ip-down.local « $@ »
fi

run-parts /etc/ppp/ip-down.d \
–arg= »$1″ –arg= »$2″ –arg= »$3″ –arg= »$4″ –arg= »$5″ –arg= »$6″

Le VPN est fonctionnel a ce stade , si vous ne souhaiter pas utiliser le réseau Hamnet sur une autre machine la configuration s’arrête la .

pon HAMNET lance le VPN sur Hamnet

poff HAMNET arrete le VPN sur Hamnet.

2eme Partie le DHCP , le NAT , le firewall , et la configuration de l’interface RJ45 eth0

apt-get install isc-dhcp-server

on configure le DHCP sur l’interface eth0

mcedit  /etc/dhcp/dhcpd.conf

authoritative;
option domain-name "Hamnet";
subnet 192.168.44.0 netmask 255.255.255.0 {
range 192.168.44.2 192.168.44.254;
option routers 192.168.44.1;
option domain-name-servers 8.8.8.8, 8.8.4.4; }

on va configurer 2 scripts dans /root pour le démarrage , le firewall , et l’arrêt .

mcedit /root/hamnet_on

#!/bin/bash
  #
  pon HAMNET
  # on active le routage 
  sh -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'

# on configure l'interface RJ45 en 192.168.44.1
  ifconfig eth0 192.168.44.1 netmask 255.255.255.0

# on lance le dhcpcd
  service isc-dhcp-server start

# on applique les règles de Firewall et masqueradd
  iptables --insert OUTPUT 1 --source 0.0.0.0/0.0.0.0 --destination 44.0.0.0/8 --jump ACCEPT --out-interface ppp0
  iptables --insert INPUT 1 --source 44.0.0.0/8 --destination 0.0.0.0/0.0.0.0 --jump ACCEPT --in-interface ppp0
  iptables --insert FORWARD 1 --source 0.0.0.0/0.0.0.0 --destination 44.0.0.0/8 --jump ACCEPT --out-interface ppp0
  iptables --insert FORWARD 1 --source 44.0.0.0/8 --destination 0.0.0.0/0.0.0.0 --jump ACCEPT

  iptables --table nat --append POSTROUTING --out-interface ppp0 --jump MASQUERADE
  iptables --append FORWARD --protocol tcp --tcp-flags SYN,RST SYN --jump TCPMSS --clamp-mss-to-pmtu

on rends le fichier  exécutable : chmod +x hamnet_on

on édite le fichier hamnet_off

mcedit /root/hamnet_off

  #!/bin/bash
  #
  # on arrête le Firewall
  iptables -F
  # on arrête le DHCP
  service isc-dhcp-server stop
  # on arrête le VPN
  poff HAMNET

on rends le fichier exécutable : chmod +x hamnet_off

on lance le vpn ./hamnet_on et on test dans midori par exemple sur le xspotnik ici le site hamnet de f5ktr.

Source : Routeur Hamnet sur OrangePi 0 / Linux | F5NLG – SvxLink –