Merci pour la commande magique ;)
Alors je peux voir qu'un utilisateur venant d'internet qui se connecte sur l'IP publique de la Box Fibre (B) sur le port 3000 arrive bien dans le conteneur du serveur souhaité (A112) puisque dans ce conteneur le port en question s'active bien sur tcpdump.
Le problème c'est qu'il se heurte à un beau "Le délais d'attente a été dépassé"
Depuis les conteneurs côté 4G/CGNAT (A112) je vois que l'accès internet ne se fait pas au travers du VPN, et je demande s'il est possible d'avoir l'entrée qui arrive de la fibre (B) et la sortie qui passe par le CGNAT (A). L'utilisateur extérieur ne doit sûrement pas faire le lien entre les 2.
Je n'arrive pas non plus à utiliser l'internet Fibre (B) depuis le côté CGNAT (A1, A11 et A112) quand le tunnel VPN est établi.
Si j'active le push "redirect-gateway def1" sur la configuration du serveur VPN je n'ai d'ailleurs plus du tout d'internet côté CGNAT.
Je suppose qu'il me manque encore des choses dans ma configuration et veut bien un peu d'aide ou des pistes à creuser.
J'ai essayé pas mal de chose mais pour beaucoup je ne sais pas exactement ce que je fais et il me reste beaucoup de questions:
Est qu'il faut que je fasse un MASQUERADE ailleurs que sur le serveur openVPN (B11)? (Les hôtes LXC des serveurs ont apparemment déjà un "MASQUERADE" sur tout ce qui n'est pas respectivement en 10.0.3.0 et 10.0.4.0)
Est -ce qu'il faut que je passe net.ipv4.ip_forward=1 ailleurs que sur le conteneur serveur openVPN (B11) ? (Apparemment déjà le cas par défaut sur le routeur A1)
Est-ce que sur le conteneur serveur openVPN (B11) il faut que le DNAT du port 3000 soit vers le routeur (A1) ou directement vers l'hôte serveur (A11) ou le conteneur (A112)? (Cela semble fonctionner avec l'hôte serveur (A11))
Sur la configuration du serveur openVPN (B11):
Faut il activer le push "redirect-gateway def1"? Si oui comment faire pour ne pas perdre l'accès internet côté client?
Est-ce qu'il est possible de faire des chemins différents entre l'entrée et la sortie? Du genre l'usager extérieur se connecte par la box fibre (B) mais le serveur répond par la box 4G CGNAT (A)? (Pour gagner en rapidité si cela ne complique pas)
Est-ce que j'ai besoin de créer manuellement les routes (avec ip route ccc.ccc.ccc.0/24 via ddd.ddd.ddd.ddd dev xxx) lorsque la config réseau (fichier interfaces ou eth0.network) défini déjà une passerelle par défaut avec ce réseau ddd.ddd.ddd.ddd?
Comment faire pour que la sortie vers internet côté CGNAT (A1, A11 et A112) passe par la box côté fibre (B)?
Je pense que je vais rester sur le routeur en client openVPN, si j'ai bien compris comme ça côté gauche je n'aurai pas à toucher à la config des conteneurs ou du serveur?
Je pourrai activer / désactiver la solution de secours sur le routeur de façon transparente.
J'ai fait une page de synthèse des configs réseau, est-ce qu'il y a quelque-chose qui m'échappe ou que je ne fais pas comme il faut?
qui est ce réseau 10.8.0.0/24 c'est ton réseau VPN ?
Oui c'est le tunnel VPN si j'ai bien compris (10.8.0.1 pour l'ip de tun0 côté serveur openVPN).
dans ton 1), précise le sens de ton flux pour être sur
Pour cette règle iptable mise en place sur le serveur openVPN en 10.0.4.17 ?
sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j MASQUERADE Je l'enlève et je la remets avec soit 10.8.0.1 soit 10.8.0.2 (ou 3 selon le client VPN) c'est ça?
j'imagine que tu as déjà aussi un MASQUERADE pour que ton 10.0.4.17 puisse aller sur internet via lxcbr0, derrière l'IP 192.168.1.6
Absolument pas XD. Par contre je pense que c'est automatique tel qu'est créé le conteneur. (Je vois que le conteneur serveur openVPN a en route par défaut l'hôte du serveur temporaire: 10.0.4.1). Et il a bien déjà accès internet.
Par forcément en lien, mais après réflexion cela ne me gêne pas que le côté CGNAT / gauche continue d’accéder à internet directement par la box 4G CGNAT. Ce sera plus rapide que de passer par le tunnel VPN.
j'ai donc retiré cette ligne de la configuration du serveur openVPN :
push "redirect-gateway def1 bypass-dhcp" > coté serveur VPN pour accéder au 192.168.11.0/24 via le client VPN
ip r a 192.168.11.0/24 via 10.8.0.x (IPClientVPN)
Alors curieusement si je mets seulement cette route côté serveur VPN cela ne suffit pas pour pouvoir 'pinguer' le client VPN depuis le serveur openVPN. Il faut que j'ajoute une
iroute subnetducient 255.255.255.0 dans /etc/openvpn/ccd/nomduclient sur le serveur VPN.
coté client VPN pour lui préciser comment accéder à 10.0.4.x/24, c'est un openWRT, cherche dans les menus le routage static pour lui dire que pour joindre 10.0.4.0/24 il faut passer par l'IP du serveur VPN (mais en principe ton client VPN doit déjà avoir une route par défaut qui envoie tout dans le VPN)
Dans la conf du serveur openVPN j'ai ajouté un
push "route 10.0.4.0 255.255.255.0" Pour que la route soit automatiquement créée sur le client. Cela à l'air de fonctionner parce que depuis le client VPN je peux pinguer le conteneur serveur openVPN en 10.0.4.17 et même le serveur temporaire en 10.0.4.1.
Sur le salon matrix auto-hébergement certains m'ont conseillés de mettre le client VPN plutôt sur un conteneur du serveur initial (celui qui a tous les services et que j'aimerais faire fonctionner derrière la 4G/CGNAT). Cela change un peut l'orientation mais le principe reste le même je pense.
J'ai refais les croquis, je passerais de ça:
à ca:
Est ce que ce sera plus simple ou il vaut mieux rester avec le routeur en client VPN?
Une fois que j'arrive à pinguer dans les deux sens comment est-ce que je fais pour que les requêtes des clients qui arrivent par internet côté fibre/droit arrivent bien jusqu'aux conteneurs des serveurs de services côté 4G/CGNAT/gauche?
J'ai tenté de faire une redirection de port entre le serveur OpenVPN et le client VNP puis entre le client VPN et l'hôte du serveur (côté gauche 4G/CGNAT).
J'ai tenté de faire une redirection de port entre le serveur OpenVPN et le l'hôte du serveur (côté gauche 4G/CGNAT) directement.
J'ai tenté de faire une redirection de port entre le serveur OpenVPN et les conteneurs des serveurs de services côté 4G/CGNAT/gauche encore plus directement.
Mais jusque là si j'arrive à voir certains trafics passer jusqu'au client VPN avec tcpdump, je n'arrive pas à obtenir la page du service depuis l'extérieur.
Merci beaucoup pour ces réponses. Ne travaillant pas dans l'informatique, j'essaye de traduire cela en faisant des recherches.. Est-ce qu'il est possible d'avoir un peu de détail/confirmation ci-après ?
Chez le voisin:
1°)
Sur le conteneur serveur OpenVPN j'avais fait cela:
sudo nano /etc/sysctl.conf
avec ajout de:
net.ipv4.ip_forward=1
Puis cette règle iptable:
sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j MASQUERADE
Est-ce qu'il faut faire quelque chose de plus?
2°)
Sur dernier croquis j'avais indiqué tous les ports routés, j'espère qu'il y a tout.
En résumé c'était : Sur box fibre du voisin : ports routés vers IP du serveur temporaire
Sur serveur temporaire : port routés vers conteneur du serveur OpenVPN
Et là je ne sais pas comment faire le reste du routage. Je suppose qu'il y a des règles à mettre dans le conteneur serveur OpenVPN
2.1°)
Donc c'est une commande en dehors d'iptables pour ajouter une route?
Du coup si j'ai bien compris de l'ip du conteneur serveur OpenVPN (côté voisin) vers le routeur OpenWRT client OpenVPN (côté chez moi)? du coup cela? :
ip r a 192.168.11.1/24 via 10.0.4.17 dev eth0
2.2°)
Donc là je mets simplement en place dans le conteneur serveur OpenVPN le routage des ports vers le routeur OpenWRT de l'autre côté?
Comme ceci?:
iptables -t nat -A PREROUTING -p tcp --dport 3001 -j DNAT --to-destination 192.168.11.1
iptables -t nat -A PREROUTING -p tcp --dport 3002 -j DNAT --to-destination 192.168.11.1
iptables -t nat -A PREROUTING -p tcp --dport 3xxx -j DNAT --to-destination 192.168.11.1
Est-ce que grâce au VPN il aura bien accès au réseau 192.168.11.x de chez moi?
Ensuite°)
Comment faire pour que le côté chez moi (gauche) utilise le VPN pour accéder à l'internet? Le point 1°) suffit?
J'ai trouvé vraiment improbable que ma banque me demande le mot de passe de mon espace client pour valider un paiement (après le code temporaire par sms). En cherchant des informations sur l'url appelée par l'iframe je suis arrivé ici et cela m'a rassuré et permis de terminer mon paiement.
Je trouve ça tellement absurde… Est-ce qu'il existe un moyen de signaler / dénoncer (en ayant une chance d'arriver jusqu'aux personnes compétentes dans ces banques) cette pratique contre-productive afin de vite abandonner cette bêtise?
Du coup sur le routeur 1.52 j'ai ajouté la route statique suivante:
- Interface : Wan
- Target : 192.168.11.5
- IPv4-Netmask : 255.255.255.0
- IPv4-Gateway : 192.168.1.51
Dans le doute j'ai aussi ajouté sur la box la "table de routage" suivante:
- Destination : 192.168.11.5
- Masque de sous réseau : 255.255.255.0
- Passerelle : 192.168.1.51
Mais depuis un client sur le routeur 1.51 je n'ai toujours pas accès au serveur 192.168.11.5
Bon je tentais d'écouter le journal avec les permissions insuffisantes donc forcément je n'avais rien. Depuis j'ai vu le warning suivant
NO EXPLICIT LISTENER ADDRESS(ES) ARE CONFIGURED
J'ai du coup ajouté à mon fichier de config turnserver.conf:
listening-ip=0.0.0.0
listening-ip=xxx.xxx.xxx.xxx#Ip publique
listening-ip=192.168.1.1
listening-ip=192.168.1.51
listening-ip=192.168.11.5
listening-ip=10.0.3.5
listening-ip=10.0.3.4
Bon je pense que 0.0.0.0 aurait suffit, mais je voulais pas passer à côté de quelque-chose.
Depuis le log est très bavard et les warnings suivants tournent en boucle:
0: : Trying to bind fd 49 to <xxx.xxx.xxx.xxx:3478>: errno=99
0: : Cannot bind DTLS/UDP listener socket to addr xxx.xxx.xxx.xxx:3478
0: : Trying to bind DTLS/UDP listener socket to addr xxx.xxx.xxx.xxx:3478, again...
bind: Cannot assign requested address
Cannot bind local socket to addr: Cannot assign requested address En effectuant quelques recherches cela ressemble à un port déjà utilisé, mais là je ne vois pas le conteneur est dédié à coturn et ne contient pas grand chose d'autre.
Lorsque j'arrête le service coturn ss -plntu ne renvoie rien
Lorsque je le relance ss -plntu renvoie:
C'est ce que j'ai réalisé en écrivant la réponse :)
Du coup comment faire cela?
Quels mots clefs (français ou anglais) chercher pour trouver de la doc là dessus?
En attendant d'en apprendre un peu plus, je vais continuer tous mes essais à partir de clients hors réseau interne à partir de l'IP publique.
Pour les autres points as-tu des pistes/idées/commentaires?
Pour le serveur coturn en regardant les ports écoutés, je me rends compte que le 3479 l'est aussi, du coup je vais l'ajouter dans la box/routeur/iptable et voir si le journal syslog s'active lorsque je tente un appel (je suis passé en "verbose" dans le fichier de config de coturn).
Les 3 routeurs openwrt (1.51, 1.52 et 1.53) ont pour passerelle l'IP de la box FAI : 192.168.1.1 => Ainsi tous les clients de ces 3 routeurs ont accès à internet et peuvent communiquer à mon autre serveur connecté en RJ à la BOX en 192.168.1.3
Dans la BOX FAI je route les ports que je veux rendre accessibles depuis l'extérieur vers la machine concernée:
Pour le premier serveur directement l'ip 192.168.1.3.
Pour le nouveau serveur derrière le routeur je redirige vers l'ip du routeur 192.168.1.51 puis dans le routeur vers l'IP du serveur 192.168.11.5 et enfin dans le serveur vers l'IP du conteneur lxc : 10.0.3.4 par exemple.
A noter que sur la box le menu de configuration sur lequel je paramètre cela est "reseau v4 > NAT > Redirection de ports"
Alors que dans les routeurs openwrt c'est le menu "Network > Firewall > port forwards" et non le menu "Network > Firewall > NAT rules" et du coup je ne comprends pas bien la différence.
Je pensais que comme par exemple sur la Box le port 8008 est routé vers le routeur openwrt 1.51, quand le routeur 1.52 reçoit une demande depuis son réseau à destination de 192.168.11.4:8008, il l'envoie à sa passerelle donc la box. Et la box devrait activer sa redirection comme quand cela vient de l'extérieur, mais ce n'est peut-être pas le cas? En fait cela semble logique que non puisque la box ne connaît pas l'IP 192.168.11.5… Aurait-il aurait fallu que je paramètre le serveur en 192.168.1.51 sur le client du réseau local? En revanche lorsque je mets l'IP publique comme serveur sur le client du routeur 1.52 je crois que cela fonctionne.
Il y a peut-être des choses que je devrais apprendre sur les réseaux, routage ou j'y suis presque?
L'idée d'avoir un fail2ban dans chaque conteneur dédié à celui-ci me plaît parce que c'est quand on conçoit un conteneur qu'on sait le mieux comment le protéger.
Niveau optimisation avec autant des services qui tournent cela ne génère pas trop d'écriture disque et/ou de consommation de ressource?
Il n'y a pas d'intérêt à mettre le fail2ban global qui coupe les accès dans un conteneur séparé?
Alors pour l'instant je suis en configuration par défaut sur LXC (donc veth et lxcbr0) mais j'avoue que je ne comprends pas encore les différentes possibilités et avantages/inconvénients.
Sur l'hôte LXC je fais un
iptables -t nat -A PREROUTING -i $NomDeMonInterface -p tcp --dport $MonNumDePort -j DNAT --to-destination 10.0.3.$NumDuContainer
Je ne sais pas trop ce que cela fait exactement mis à part que je peux rediriger le port voulu depuis l'IP hôte vers le conteneur voulu.
J'ai mis à jour le croquis sur le premier post pour faire apparaître les numéros de port.
Pas intéressant de mettre Fail2Ban dans un des conteneurs pour faciliter les sauvegardes / mise à jour / backup / transportabilité ?
Je le voyais dans l'autre sens avec toutes les données gérés par les conteneurs stockées dans les conteneurs :
- Séparation par fonction y compris des données
- Facilité de dupliquer / sauvegarder le conteneur avec les données (par exemple avant de faire une maj). Un seul ensemble fonctionnel à lui tout seul.
- Possibilité de changer le conteneur de serveur avec les données en un rien de temps
- Plus tard je voulais mettre un deuxième serveur de secours qui prendrait le relais en cas de coupure du principal (lieu, alimentation et connexion différente) avec synchronisation des conteneurs avec données
Mais ce n'est effectivement pas forcément le meilleurs des choix.
Tu procèdes comme cela sur ton serveur?
Du coup fail2ban dans son conteneur mais avec accès à tous les répertoires partagés des autres conteneurs?
Et fail2ban viens directement écrire dans les règles IP du de l'hôte pour bannir les IP?
Sur le conteneur serveur:
J'ai installé apt-cacher-ng,
Dans le fichier config j'ai dé-commenté la ligne du port pour le changer en 9999
J'ai activé apt-cacher-ng au redémarrage : systemctl enable apt-cacher-ng
J'ai installé squid-deb-proxy-client
Puis redémarré le conteneur
Sur l'hote LXC:
j'ai rooté le port 9999 vers le conteneur serveur
Sur le premier conteneur client
J'ai installé squid-deb-proxy-client
Puis redémarré le conteneur
J'ai lancé l'installation d'un paquet
=> Vitesse ADSL
Sur le deuxieme conteneur client
J'ai installé squid-deb-proxy-client
Puis redémarré le conteneur
J'ai lancé l'installation du même paquet
=> Toujours Vitesse ADSL :/
J'ai dû rater quelque-chose, je vais lire un peu la doc.
Merci, mais l’inconvénient (pour mon cas) si je ne dis pas de bêtises, c'est qu'apt-miror fait une copie intégrale (ou alors nécessite une configuration manuelle pour choisir un par un les dépôts ce que je ne souhaite pas faire)
Ok, chouette merci, ce paquet fonctionne même sans proxy squid du coup?
Pour info ma configuration (en cours de définition) devrait ressembler à cela: https://i.imgur.com/lv2aWES.png
Penses tu que cela soit nécessaire dans ce cas?
J’envisage même de faire pointer le serveur debian qui héberge LXC et les conteneurs sur apt-cacher présent dans un de ses conteneurs. Possible?
[^] # Re: le plus simple
Posté par ROUGEXIII . En réponse au message Auto-hébergement derrière CGNAT et OpenVPN avec connexion internet d'un tiers. Évalué à 1 (+0/-0). Dernière modification le 22 mai 2025 à 11:45.
.9. Est-ce que le fait que les deux box (A) et (B) soient toutes deux en 192.168.1.0 peut poser problème?
[^] # Re: le plus simple
Posté par ROUGEXIII . En réponse au message Auto-hébergement derrière CGNAT et OpenVPN avec connexion internet d'un tiers. Évalué à 1 (+0/-0).
Merci pour la commande magique ;)
Alors je peux voir qu'un utilisateur venant d'internet qui se connecte sur l'IP publique de la Box Fibre (B) sur le port 3000 arrive bien dans le conteneur du serveur souhaité (A112) puisque dans ce conteneur le port en question s'active bien sur tcpdump.
Le problème c'est qu'il se heurte à un beau "Le délais d'attente a été dépassé"
Depuis les conteneurs côté 4G/CGNAT (A112) je vois que l'accès internet ne se fait pas au travers du VPN, et je demande s'il est possible d'avoir l'entrée qui arrive de la fibre (B) et la sortie qui passe par le CGNAT (A). L'utilisateur extérieur ne doit sûrement pas faire le lien entre les 2.
Je n'arrive pas non plus à utiliser l'internet Fibre (B) depuis le côté CGNAT (A1, A11 et A112) quand le tunnel VPN est établi.
Si j'active le push "redirect-gateway def1" sur la configuration du serveur VPN je n'ai d'ailleurs plus du tout d'internet côté CGNAT.
Je suppose qu'il me manque encore des choses dans ma configuration et veut bien un peu d'aide ou des pistes à creuser.
J'ai essayé pas mal de chose mais pour beaucoup je ne sais pas exactement ce que je fais et il me reste beaucoup de questions:
Est qu'il faut que je fasse un MASQUERADE ailleurs que sur le serveur openVPN (B11)? (Les hôtes LXC des serveurs ont apparemment déjà un "MASQUERADE" sur tout ce qui n'est pas respectivement en 10.0.3.0 et 10.0.4.0)
Est -ce qu'il faut que je passe net.ipv4.ip_forward=1 ailleurs que sur le conteneur serveur openVPN (B11) ? (Apparemment déjà le cas par défaut sur le routeur A1)
Est-ce que sur le conteneur serveur openVPN (B11) il faut que le DNAT du port 3000 soit vers le routeur (A1) ou directement vers l'hôte serveur (A11) ou le conteneur (A112)? (Cela semble fonctionner avec l'hôte serveur (A11))
Sur la configuration du serveur openVPN (B11):
J'ai essayé de suivre cette page https://openwrt.org/docs/guide-user/services/vpn/openvpn/client-luci pour la config de du routeur (A1) en client openVPN. Est-ce qu'il y a d'autres choses à faire sur ce routeur (A1) comme:
Est-ce qu'il est possible de faire des chemins différents entre l'entrée et la sortie? Du genre l'usager extérieur se connecte par la box fibre (B) mais le serveur répond par la box 4G CGNAT (A)? (Pour gagner en rapidité si cela ne complique pas)
Est-ce que j'ai besoin de créer manuellement les routes (avec ip route ccc.ccc.ccc.0/24 via ddd.ddd.ddd.ddd dev xxx) lorsque la config réseau (fichier interfaces ou eth0.network) défini déjà une passerelle par défaut avec ce réseau ddd.ddd.ddd.ddd?
Comment faire pour que la sortie vers internet côté CGNAT (A1, A11 et A112) passe par la box côté fibre (B)?
[^] # Re: le plus simple
Posté par ROUGEXIII . En réponse au message Auto-hébergement derrière CGNAT et OpenVPN avec connexion internet d'un tiers. Évalué à 1 (+0/-0).
Je pense que je vais rester sur le routeur en client openVPN, si j'ai bien compris comme ça côté gauche je n'aurai pas à toucher à la config des conteneurs ou du serveur?
Je pourrai activer / désactiver la solution de secours sur le routeur de façon transparente.
J'ai fait une page de synthèse des configs réseau, est-ce qu'il y a quelque-chose qui m'échappe ou que je ne fais pas comme il faut?
[^] # Re: le plus simple
Posté par ROUGEXIII . En réponse au message Auto-hébergement derrière CGNAT et OpenVPN avec connexion internet d'un tiers. Évalué à 1 (+0/-0).
Bonjour,
Merci pour le suivi :)
Oui c'est le tunnel VPN si j'ai bien compris (10.8.0.1 pour l'ip de tun0 côté serveur openVPN).
Pour cette règle iptable mise en place sur le serveur openVPN en 10.0.4.17 ?
Je l'enlève et je la remets avec soit 10.8.0.1 soit 10.8.0.2 (ou 3 selon le client VPN) c'est ça?sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j MASQUERADE
Absolument pas XD. Par contre je pense que c'est automatique tel qu'est créé le conteneur. (Je vois que le conteneur serveur openVPN a en route par défaut l'hôte du serveur temporaire: 10.0.4.1). Et il a bien déjà accès internet.
Par forcément en lien, mais après réflexion cela ne me gêne pas que le côté CGNAT / gauche continue d’accéder à internet directement par la box 4G CGNAT. Ce sera plus rapide que de passer par le tunnel VPN.
j'ai donc retiré cette ligne de la configuration du serveur openVPN :
> coté serveur VPN pour accéder au 192.168.11.0/24 via le client VPNpush "redirect-gateway def1 bypass-dhcp"
ip r a 192.168.11.0/24 via 10.8.0.x (IPClientVPN)
Alors curieusement si je mets seulement cette route côté serveur VPN cela ne suffit pas pour pouvoir 'pinguer' le client VPN depuis le serveur openVPN. Il faut que j'ajoute une
dans /etc/openvpn/ccd/nomduclient sur le serveur VPN.iroute subnetducient 255.255.255.0
Dans la conf du serveur openVPN j'ai ajouté un
Pour que la route soit automatiquement créée sur le client. Cela à l'air de fonctionner parce que depuis le client VPN je peux pinguer le conteneur serveur openVPN en 10.0.4.17 et même le serveur temporaire en 10.0.4.1.push "route 10.0.4.0 255.255.255.0"
Sur le salon matrix auto-hébergement certains m'ont conseillés de mettre le client VPN plutôt sur un conteneur du serveur initial (celui qui a tous les services et que j'aimerais faire fonctionner derrière la 4G/CGNAT). Cela change un peut l'orientation mais le principe reste le même je pense.
J'ai refais les croquis, je passerais de ça:
à ca:
Est ce que ce sera plus simple ou il vaut mieux rester avec le routeur en client VPN?
Une fois que j'arrive à pinguer dans les deux sens comment est-ce que je fais pour que les requêtes des clients qui arrivent par internet côté fibre/droit arrivent bien jusqu'aux conteneurs des serveurs de services côté 4G/CGNAT/gauche?
J'ai tenté de faire une redirection de port entre le serveur OpenVPN et le client VNP puis entre le client VPN et l'hôte du serveur (côté gauche 4G/CGNAT).
J'ai tenté de faire une redirection de port entre le serveur OpenVPN et le l'hôte du serveur (côté gauche 4G/CGNAT) directement.
J'ai tenté de faire une redirection de port entre le serveur OpenVPN et les conteneurs des serveurs de services côté 4G/CGNAT/gauche encore plus directement.
Mais jusque là si j'arrive à voir certains trafics passer jusqu'au client VPN avec tcpdump, je n'arrive pas à obtenir la page du service depuis l'extérieur.
[^] # Re: le plus simple
Posté par ROUGEXIII . En réponse au message Auto-hébergement derrière CGNAT et OpenVPN avec connexion internet d'un tiers. Évalué à 1 (+0/-0).
Bonjour,
Merci beaucoup pour ces réponses. Ne travaillant pas dans l'informatique, j'essaye de traduire cela en faisant des recherches.. Est-ce qu'il est possible d'avoir un peu de détail/confirmation ci-après ?
Chez le voisin:
1°)
Sur le conteneur serveur OpenVPN j'avais fait cela:
sudo nano /etc/sysctl.conf
avec ajout de:
net.ipv4.ip_forward=1
Puis cette règle iptable:
sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j MASQUERADE
Est-ce qu'il faut faire quelque chose de plus?
2°)
Sur dernier croquis j'avais indiqué tous les ports routés, j'espère qu'il y a tout.
En résumé c'était : Sur box fibre du voisin : ports routés vers IP du serveur temporaire
Sur serveur temporaire : port routés vers conteneur du serveur OpenVPN
Et là je ne sais pas comment faire le reste du routage. Je suppose qu'il y a des règles à mettre dans le conteneur serveur OpenVPN
2.1°)
Donc c'est une commande en dehors d'iptables pour ajouter une route?
Du coup si j'ai bien compris de l'ip du conteneur serveur OpenVPN (côté voisin) vers le routeur OpenWRT client OpenVPN (côté chez moi)? du coup cela? :
ip r a 192.168.11.1/24 via 10.0.4.17 dev eth0
2.2°)
Donc là je mets simplement en place dans le conteneur serveur OpenVPN le routage des ports vers le routeur OpenWRT de l'autre côté?
Comme ceci?:
iptables -t nat -A PREROUTING -p tcp --dport 3001 -j DNAT --to-destination 192.168.11.1
iptables -t nat -A PREROUTING -p tcp --dport 3002 -j DNAT --to-destination 192.168.11.1
iptables -t nat -A PREROUTING -p tcp --dport 3xxx -j DNAT --to-destination 192.168.11.1
Est-ce que grâce au VPN il aura bien accès au réseau 192.168.11.x de chez moi?
Ensuite°)
Comment faire pour que le côté chez moi (gauche) utilise le VPN pour accéder à l'internet? Le point 1°) suffit?
# Merci d'avoir ouvert ce billet!
Posté par ROUGEXIII . En réponse au journal Ils sont devenu fous. Évalué à 4.
Merci d'avoir ouvert ce billet!
J'ai trouvé vraiment improbable que ma banque me demande le mot de passe de mon espace client pour valider un paiement (après le code temporaire par sms). En cherchant des informations sur l'url appelée par l'iframe je suis arrivé ici et cela m'a rassuré et permis de terminer mon paiement.
Je trouve ça tellement absurde… Est-ce qu'il existe un moyen de signaler / dénoncer (en ayant une chance d'arriver jusqu'aux personnes compétentes dans ces banques) cette pratique contre-productive afin de vite abandonner cette bêtise?
[^] # Re: deja ... les routes
Posté par ROUGEXIII . En réponse au message AutoHebergement matrix synapse pour remplacer whatsapp. Évalué à 1.
D'accord,
Du coup sur le routeur 1.52 j'ai ajouté la route statique suivante:
- Interface : Wan
- Target : 192.168.11.5
- IPv4-Netmask : 255.255.255.0
- IPv4-Gateway : 192.168.1.51
Dans le doute j'ai aussi ajouté sur la box la "table de routage" suivante:
- Destination : 192.168.11.5
- Masque de sous réseau : 255.255.255.0
- Passerelle : 192.168.1.51
Mais depuis un client sur le routeur 1.51 je n'ai toujours pas accès au serveur 192.168.11.5
[^] # Re: deja ... les routes
Posté par ROUGEXIII . En réponse au message AutoHebergement matrix synapse pour remplacer whatsapp. Évalué à 1.
Je suis tombé sur ça
Du coup j'ai l'impression que sur mon serveur le "PREPROUTING" avec iptable est insuffisant. Mais là c'est bien au delà de mes capacités…
[^] # Re: deja ... les routes
Posté par ROUGEXIII . En réponse au message AutoHebergement matrix synapse pour remplacer whatsapp. Évalué à 1.
Bon effectivement si je ne mets que le seul :
listening-ip=0.0.0.0
Je n'ai plus l'erreur…
(dommage qu'on ne puisse plus modifier ses commentaires après 5 minutes :/)
[^] # Re: deja ... les routes
Posté par ROUGEXIII . En réponse au message AutoHebergement matrix synapse pour remplacer whatsapp. Évalué à 1. Dernière modification le 03 octobre 2022 à 11:02.
Je viens de faire un petit pas je pense:
Bon je tentais d'écouter le journal avec les permissions insuffisantes donc forcément je n'avais rien. Depuis j'ai vu le warning suivant
NO EXPLICIT LISTENER ADDRESS(ES) ARE CONFIGURED
J'ai du coup ajouté à mon fichier de config turnserver.conf:
listening-ip=0.0.0.0
listening-ip=xxx.xxx.xxx.xxx#Ip publique
listening-ip=192.168.1.1
listening-ip=192.168.1.51
listening-ip=192.168.11.5
listening-ip=10.0.3.5
listening-ip=10.0.3.4
Bon je pense que 0.0.0.0 aurait suffit, mais je voulais pas passer à côté de quelque-chose.
Depuis le log est très bavard et les warnings suivants tournent en boucle:
En effectuant quelques recherches cela ressemble à un port déjà utilisé, mais là je ne vois pas le conteneur est dédié à coturn et ne contient pas grand chose d'autre.0: : Trying to bind fd 49 to <xxx.xxx.xxx.xxx:3478>: errno=99
0: : Cannot bind DTLS/UDP listener socket to addr xxx.xxx.xxx.xxx:3478
0: : Trying to bind DTLS/UDP listener socket to addr xxx.xxx.xxx.xxx:3478, again...
bind: Cannot assign requested address
Cannot bind local socket to addr: Cannot assign requested address
Lorsque j'arrête le service coturn ss -plntu ne renvoie rien
Lorsque je le relance ss -plntu renvoie:
Est-ce que ma configuration le force à ouvrir plusieurs fois le même port?
[^] # Re: deja ... les routes
Posté par ROUGEXIII . En réponse au message AutoHebergement matrix synapse pour remplacer whatsapp. Évalué à 1.
C'est ce que j'ai réalisé en écrivant la réponse :)
Du coup comment faire cela?
Quels mots clefs (français ou anglais) chercher pour trouver de la doc là dessus?
En attendant d'en apprendre un peu plus, je vais continuer tous mes essais à partir de clients hors réseau interne à partir de l'IP publique.
Pour les autres points as-tu des pistes/idées/commentaires?
Pour le serveur coturn en regardant les ports écoutés, je me rends compte que le 3479 l'est aussi, du coup je vais l'ajouter dans la box/routeur/iptable et voir si le journal syslog s'active lorsque je tente un appel (je suis passé en "verbose" dans le fichier de config de coturn).
[^] # Re: Salon Matrix
Posté par ROUGEXIII . En réponse au message AutoHebergement matrix synapse pour remplacer whatsapp. Évalué à 1.
Bonjour merci pour l'info :)
Quel est la plage horaire qu'il est préférable d'utiliser pour demander de l'aide? Le soir entre 19h et 20h?
[^] # Re: deja ... les routes
Posté par ROUGEXIII . En réponse au message AutoHebergement matrix synapse pour remplacer whatsapp. Évalué à 1.
Bonjour, Merci pour le premier retour :)
Les 3 routeurs openwrt (1.51, 1.52 et 1.53) ont pour passerelle l'IP de la box FAI : 192.168.1.1 => Ainsi tous les clients de ces 3 routeurs ont accès à internet et peuvent communiquer à mon autre serveur connecté en RJ à la BOX en 192.168.1.3
Dans la BOX FAI je route les ports que je veux rendre accessibles depuis l'extérieur vers la machine concernée:
Pour le premier serveur directement l'ip 192.168.1.3.
Pour le nouveau serveur derrière le routeur je redirige vers l'ip du routeur 192.168.1.51 puis dans le routeur vers l'IP du serveur 192.168.11.5 et enfin dans le serveur vers l'IP du conteneur lxc : 10.0.3.4 par exemple.
A noter que sur la box le menu de configuration sur lequel je paramètre cela est "reseau v4 > NAT > Redirection de ports"
Alors que dans les routeurs openwrt c'est le menu "Network > Firewall > port forwards" et non le menu "Network > Firewall > NAT rules" et du coup je ne comprends pas bien la différence.
Je pensais que comme par exemple sur la Box le port 8008 est routé vers le routeur openwrt 1.51, quand le routeur 1.52 reçoit une demande depuis son réseau à destination de 192.168.11.4:8008, il l'envoie à sa passerelle donc la box. Et la box devrait activer sa redirection comme quand cela vient de l'extérieur, mais ce n'est peut-être pas le cas? En fait cela semble logique que non puisque la box ne connaît pas l'IP 192.168.11.5… Aurait-il aurait fallu que je paramètre le serveur en 192.168.1.51 sur le client du réseau local? En revanche lorsque je mets l'IP publique comme serveur sur le client du routeur 1.52 je crois que cela fonctionne.
Il y a peut-être des choses que je devrais apprendre sur les réseaux, routage ou j'y suis presque?
[^] # Re: Fail2ban
Posté par ROUGEXIII . En réponse au message Sécuriser un serveur basé sur des conteneurs sous LXC avec fail2ban : Meilleures pratiques?. Évalué à 2. Dernière modification le 08 janvier 2022 à 15:34.
Cela devrait te plaire ;)
[^] # Re: fail2ban sur le host + rsyslog guests->host
Posté par ROUGEXIII . En réponse au message Sécuriser un serveur basé sur des conteneurs sous LXC avec fail2ban : Meilleures pratiques?. Évalué à 1.
Bonjour,
Merci pour ce retour complet!
La séparation en sous-réseaux c'est pour isoler les conteneurs qui n'ont pas à communiquer entres eux?
L'interface dummy cela sert à quoi? (Je n'en suis pas très loin dans mes lectures, j'essaye de comprendre cela pour l'instant : https://madovi.xyz/doku.php?id=services:virtu:tuto:lxc_tuto1)
L'idée d'avoir un fail2ban dans chaque conteneur dédié à celui-ci me plaît parce que c'est quand on conçoit un conteneur qu'on sait le mieux comment le protéger.
Niveau optimisation avec autant des services qui tournent cela ne génère pas trop d'écriture disque et/ou de consommation de ressource?
Il n'y a pas d'intérêt à mettre le fail2ban global qui coupe les accès dans un conteneur séparé?
[^] # Re: ca depend de ton reseau
Posté par ROUGEXIII . En réponse au message Sécuriser un serveur basé sur des conteneurs sous LXC avec fail2ban : Meilleures pratiques?. Évalué à 1. Dernière modification le 07 janvier 2022 à 18:37.
Bonjour, merci pour le retour
Alors pour l'instant je suis en configuration par défaut sur LXC (donc veth et lxcbr0) mais j'avoue que je ne comprends pas encore les différentes possibilités et avantages/inconvénients.
Sur l'hôte LXC je fais un
iptables -t nat -A PREROUTING -i $NomDeMonInterface -p tcp --dport $MonNumDePort -j DNAT --to-destination 10.0.3.$NumDuContainer
Je ne sais pas trop ce que cela fait exactement mis à part que je peux rediriger le port voulu depuis l'IP hôte vers le conteneur voulu.
J'ai mis à jour le croquis sur le premier post pour faire apparaître les numéros de port.
Pas intéressant de mettre Fail2Ban dans un des conteneurs pour faciliter les sauvegardes / mise à jour / backup / transportabilité ?
[^] # Re: Fail2ban
Posté par ROUGEXIII . En réponse au message Sécuriser un serveur basé sur des conteneurs sous LXC avec fail2ban : Meilleures pratiques?. Évalué à 1.
Bonjour, merci pour le retour,
Je n'avais pas pensé à rsyslog! Mais oui!
Je vais regarder comment ça se met en place concrètement.
Je comprends pas trop le lien avec reverse proxy ou ssh mais je vais lire la doc :)
[^] # Re: [HS]
Posté par ROUGEXIII . En réponse au message Sécuriser un serveur basé sur des conteneurs sous LXC avec fail2ban : Meilleures pratiques?. Évalué à 2.
Bonjour,
Tout simplement avec LibreOffice - Draw avec quelques png glanées sur le web :)
[^] # Re: importer un sous répertoire de l'hote dans le container
Posté par ROUGEXIII . En réponse au message Sécuriser un serveur basé sur des conteneurs sous LXC avec fail2ban : Meilleures pratiques?. Évalué à 2.
Merci pour ton retour, point de vue intéressant.
Je le voyais dans l'autre sens avec toutes les données gérés par les conteneurs stockées dans les conteneurs :
- Séparation par fonction y compris des données
- Facilité de dupliquer / sauvegarder le conteneur avec les données (par exemple avant de faire une maj). Un seul ensemble fonctionnel à lui tout seul.
- Possibilité de changer le conteneur de serveur avec les données en un rien de temps
- Plus tard je voulais mettre un deuxième serveur de secours qui prendrait le relais en cas de coupure du principal (lieu, alimentation et connexion différente) avec synchronisation des conteneurs avec données
Mais ce n'est effectivement pas forcément le meilleurs des choix.
Tu procèdes comme cela sur ton serveur?
Du coup fail2ban dans son conteneur mais avec accès à tous les répertoires partagés des autres conteneurs?
Et fail2ban viens directement écrire dans les règles IP du de l'hôte pour bannir les IP?
[^] # Re: apt-cacher-ng
Posté par ROUGEXIII . En réponse au message Dépot repository cache/miroir partiel local. Évalué à 1. Dernière modification le 04 janvier 2022 à 22:52.
Bon je vient d'essayer:
Sur le conteneur serveur:
J'ai installé apt-cacher-ng,
Dans le fichier config j'ai dé-commenté la ligne du port pour le changer en 9999
J'ai activé apt-cacher-ng au redémarrage : systemctl enable apt-cacher-ng
J'ai installé squid-deb-proxy-client
Puis redémarré le conteneur
Sur l'hote LXC:
j'ai rooté le port 9999 vers le conteneur serveur
Sur le premier conteneur client
J'ai installé squid-deb-proxy-client
Puis redémarré le conteneur
J'ai lancé l'installation d'un paquet
=> Vitesse ADSL
Sur le deuxieme conteneur client
J'ai installé squid-deb-proxy-client
Puis redémarré le conteneur
J'ai lancé l'installation du même paquet
=> Toujours Vitesse ADSL :/
J'ai dû rater quelque-chose, je vais lire un peu la doc.
[^] # Re: re: Dépot repository cache/miroir partiel local
Posté par ROUGEXIII . En réponse au message Dépot repository cache/miroir partiel local. Évalué à 2.
Merci :)
Je du coup je vais regarder les différences entre:
apt-cacher-ng / approx / clue polipo
(critère de choix, facilité de mise en place, activité du projet, efficacité)
Si je ne dis pas de bêtise polipo est un proxy en général, il ne fait pas seulement cache de dépôt?
[^] # Re: approx
Posté par ROUGEXIII . En réponse au message Dépot repository cache/miroir partiel local. Évalué à 2.
Merci :)
Je du coup je vais regarder les différences entre:
apt-cacher-ng / approx / clue polipo
(critère de choix, facilité de mise en place, activité du projet, efficacité)
[^] # Re: apt-mirror
Posté par ROUGEXIII . En réponse au message Dépot repository cache/miroir partiel local. Évalué à 2.
Merci, mais l’inconvénient (pour mon cas) si je ne dis pas de bêtises, c'est qu'apt-miror fait une copie intégrale (ou alors nécessite une configuration manuelle pour choisir un par un les dépôts ce que je ne souhaite pas faire)
[^] # Re: apt-cacher-ng
Posté par ROUGEXIII . En réponse au message Dépot repository cache/miroir partiel local. Évalué à 1. Dernière modification le 04 janvier 2022 à 21:22.
Ok, chouette merci, ce paquet fonctionne même sans proxy squid du coup?
Pour info ma configuration (en cours de définition) devrait ressembler à cela: https://i.imgur.com/lv2aWES.png
Penses tu que cela soit nécessaire dans ce cas?
J’envisage même de faire pointer le serveur debian qui héberge LXC et les conteneurs sur apt-cacher présent dans un de ses conteneurs. Possible?
[^] # Re: apt-cacher-ng
Posté par ROUGEXIII . En réponse au message Dépot repository cache/miroir partiel local. Évalué à 1. Dernière modification le 04 janvier 2022 à 21:20.
Super, merci pour ce retour
Par curiosité pourquoi avoir arrêté? Grosse connexion fibre qui a remplacé l'ADSL?