ilip a écrit 113 commentaires

Ah oui c'est vrai qu'il y a aussi cette méthode qui simplifie vraiment les choses.
A l'époque j'utilisais un serveur OVH kimsufi et c'était pas possible d'avoir plusieurs IP.
Mais là comme c'est un serveur de la gamme OVH dédié, c'est peut être jouable, je vais regarder

Le "NAT reflection" semble être adapté à cette problématique

https://docs.netgate.com/pfsense/en/latest/book/nat/nat-reflection.html

C'est pas très pratique car je dois dupliquer les règles NAT du WAN sur le LAN mais ça semble fonctionner

Bonjour, question un peu hors sujet désolé mais y a t'il un intérêt de mettre un certificat SSL signé dans un serveur mail comme let's encrypt ? J'utilise les certificats auto-signés et ça ne semble pas poser de problème

Le fait est que si je ping une machine du réseau VPN "machine_1.local" et que mon OS cherche à résoudre ce nom avec les DNS de ma connexion Internet (ce qui est le cas), cela échoue.

S'il n'y a pas de d'IP / DNS en WIFI direct, comment le navigateur peut accéder au site ?
Je ne connais pas du tout cette techno

Bonjour,

J'ai essayé cette solution avec avahi-daemon qui supporte le mDNS, mais effectivement cela ne fonctionne pas sur Android, qui est la cible de mon projet.

Voir : https://bugs.chromium.org/p/chromium/issues/detail?id=405925

Ok merci pour l'analyse.
Bonne idée le WIFI Direct mais je ne pense pas que ça puisse marcher pour un site WEB, c'est plutôt utilisé pour des services particulier.
Pour les ZeroConf avec mDNS j'y avais pensé, je suis en train d'essayer de tester.

De manière plus générique, on peut retrouver ce problème dans le cas du VPN :
- Un PC connecté au LAN avec internet
- On se connecte en VPN à un serveur qui à un fourni un DNS pour résoudre les IP des machines mais n'a pas de connectivité Internet
Dans ce cas comment le PC sais avec quel DNS il doit résoudre les domaines (internet VS hostname des machines) ?

Tu as dis avoir besoin que ton serveur soit joignable via un nom de domaine (très probablement pour respecter les vhost d'apache2).

Oui en partie et également pour faire du HTTPS.

DNSChef est un rogue DNS (aussi appelé "serveur DNS menteur"). C'est a dire qu'il te permet de dire (lorsqu'un client DNS l’interroge) que www.tonSite.com se trouve à l'adresse 192.168.42.42 et ce peu importe se que les "vrai" serveur DNS répondraient.
Donc si tu le configure "au dessus" de dnsmasq, quand tes users vont se connecter et taper www.tonSite.com dans leur navigateur, leur machine va joindre ton serveur ou toute autre IP que tu auras indiqué.
Dans ton cas il faut configurer ton wifi pour que tes clients interrogent DNSChef et non dnsmasq.

Je pense que ce n'est pas représentatif de mon problème.
Lorsque j'ai deux connexions :
- Connexion Internet (data ou LAN)
- Connexion Raspberry (avec le WIFI, qui ne donne pas Internet)
Le soucis est que lorsque j’interroge un domaine, le smartphone / PC tente de résoudre le domaine en interrogeant soit le DNS Internet (ce qui fonctionne pour les domaines internet, mais échoue pour le domaine example.local), soit le DNS de la raspberry (qui échoue pour les domaines internet).
Et le comportement aléatoire est due au fait qu'il interroge soit l'un, soit l'autre (mais pas les deux, ou l'un pour mes adresse locales et l'autre pour les adresses internet).

Ce n'est pas se que j'ai observé sur les machines connectées à mon réseau. (on en discute en ce moment ici).

Je viens de tester, si je connecte la data, puis le WIFI (wifi qui ne donne pas de passerelle), j'ai bien accès à Internet.
Par contre je ne peut pas accéder au site example.local (à cause du problème de DNS).

Je ne sais pas si c'est clair ?

J'ai regardé je ne comprend pas bien à quelle problématique répond le tuto que tu as mis en lien, si tu peux détailler le cas d'utilisation.

Une précision par rapport à mon besoin, la solution apportée doit uniquement être coté serveur. Je veux éviter de devoir paramétrer des choses coté smartphone (si la solution existe).

Le WIFI sur lequel je me connecte qui est sur la raspberry ne donne pas d'accès Internet. Donc en théorie Android devrait pouvoir garder sa connectivité Internet par la data.

Ce n'est pas un problème spécifique aux smartphones. Avec un PC je peux reproduire la même problématique :
Le PC est connecté au réseau LAN sur lequel il y'a Internet.
Lorsque je connecte le PC au WIFI de la raspberry, j'ai le même comportement aléatoire lorsque je ping un site Internet ou le site de la raspberry.

Je vais jeter un coup d'oeil à la solution dnschef.

Peut-être hors sujet mais personnellement j'utilise Éclipse CDT pour les projets C/C++, qui créé des Makefiles pour le build, avec détection des toolchains disponible sur le poste. L'interface de configuration du projet pour les librairies est assez bien faite. Le projet est enregistré en .project. Par contre je ne sais pas si c'est utilisable de manière portable.

Problème résolu, effectivement c'était à cause du paramètre "Domain" dans /etc/idmapd.conf.

J'ai également activé le paramètre Verbosity et on voit bien les échanges d'ID user / groupes apparaître dans /var/log/syslog.

Merci pour l'aide

Par défaut idmapd est désactivé :

cat /sys/module/nfs/parameters/nfs4_disable_idmapping : Y

Si je l'active (echo N > /sys/module/nfs/parameters/nfs4_disable_idmapping), j'ai les mêmes problèmes.

J'ai fais un test avec des UID user identiques (voir message précédent), j'ai quand même un soucis de droits.

Pour les options de montage :

Serveur : rw,subtree_check,secure
Client : rw,relatime,vers=4.0,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.2,local_lock=none,addr=192.168.0.7

J'ai déjà essayé les diverses options du NFSv4, sans améliorations. Donc je suis repassé aux options par défaut.

J'utilise QEMU/KVM pour toutes mes VM.

Pour les options de montage je laisse celles par défault :

• Serveur : rw,subtree_check,secure
• Client : rw,relatime,vers=4.0,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.2,local_lock=none,addr=192.168.0.7

Je créé un dossier partagé sur le serveur NFS avec propriétaire "test".

Je le monte coté client.

ls -al ./TEST/ : "drwxrwsrwx+ 2 test test 19 avril 26 17:47 ."

Le propriétaire du dossier est bien "test.

Je créé un fichier à partir du client :
echo test > ./TEST/azerty
ls -al ./TEST/azerty : "-rw-r--r--+ 1 nobody test 5 avril 26 17:47 azerty"

Le fichier créé a pour owner "nobody"

Si je fais sur le client "chown test azerty", j'obtiens (je le fais avec le compte root) :

chown: changing ownership of 'azerty': Operation not permitted

Si je fais le chown à partir du serveur, ça fonctionne.

Donc un problème sur la modification des droits coté client.

J'ai aussi fait un autre test coté client :

echo test > ./querty
chown test ./querty
chgrp test ./querty
ls -al
-rw-r--r-- 1 test test 0 avril 26 17:59 querty
cp -p ./querty ./TEST/
cp: failed to preserve ownership for 'TEST/a': Operation not permitted

Concernant les droits sur le dossier OMV, on a bien le propriétaire "test" sur ce dossier, et j'ai reglé les ACL pour permettre la lecture écriture de "test" dans ce dossier (777).

Ah c'est bon problème réglé :

Mes cartes réseau virtuelles pour pfSense était de type linux virtio, sachant que pfSense est un FreeBSD.
Je suis passé en interfaces Intel e1000, et maintenant le NAT fonctionne.
Pour les VM Linux je suis resté en virtio, il me semble que c'est plus performant.

Merci pour l'aide !

Pour la règle MASQUERADE, il faut spécifier l'interface de sortie, donc vmbr0, et éventuellement la plage IP source. Donc pas de MASQUERADE sur vmbr2.

Pour vmbr2 j'ai des règles DNAT pour la redirection de port :

# garder sur proxmox les trames 22 et 8006 :
iptables -t nat -A PREROUTING -i vmbr0 -p tcp --dport 22 -j ACCEPT
iptables -t nat -A PREROUTING -i vmbr0 -p tcp --dport 8006 -j ACCEPT

# envoyer tout le reste vers pfSense :
iptables -t nat -A PREROUTING -i vmbr0 -j DNAT --to 10.0.0.2

OK merci. J'essai demain

C'est bien ça. Les trames passent par le proxmox sans passer par sa table NAT. La trame est routée directement sur Internet.
Ce qui est étrange c'est que si la connexion SSH est faite depuis le pfSense (10.0.0.2), la trame passe bien par la chaine POSTROUTING du Proxmox, et son adresse source devient l'IP publique du proxmox.
J'ai bien le sysctl ip_forward à 1.

Le pfSense a déjà le MASQUERADE d'activé par défaut (option Firewall / NAT / Outbound / Automatic outbound NAT rule generation (IPsec passthrough included) activée).

Donc je suppose qu'il fonctionne.

on est d'accord que la VM (192.168.0.3/16) a comme passerelle le pfsense (192.168.0.1/16) sur vmbr3 monté sur des cartes dummy dans le proxmox. : C'est ça, par contre les cartes ne sont pas dummy (je ne sais pas ce que c'est) à part le vmbr1 que je n'utilise pas.

puis le pfsense a comme passerelle par defaut le proxmox 10.0.0.1 sur la carte vmbr2 : Oui, je viens de vérifier.

Voici le trafic sur vmbr2 :

SSH depuis pfSense :

root@ns358551:~# tcpdump -n -i vmbr2
listening on vmbr2, link-type EN10MB (Ethernet), capture size 262144 bytes
19:02:40.827455 IP 10.0.0.2.9350 > IP_PUBLIC_SERVER_SSH.22: Flags [S], seq 1956186408, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 2610281 ecr 0], length 0
19:02:40.828257 IP IP_PUBLIC_SERVER_SSH.22 > 10.0.0.2.9350: Flags [S.], seq 246767234, ack 1956186409, win 5792, options [mss 1460,sackOK,TS val 2916747114 ecr 2610281,nop,wscale 6], length 0

SSH depuis la VM1 :

root@ns358551:~# tcpdump -n -i vmbr2
listening on vmbr2, link-type EN10MB (Ethernet), capture size 262144 bytes
19:04:34.849788 IP 10.0.0.2.25764 > IP_PUBLIC_SERVER_SSH.22: Flags [S], seq 1598292745, win 29200, options [mss 1460,sackOK,TS val 612205 ecr 0,nop,wscale 7], length 0
Pas de retour

En effet ce ne sont pas des iptables sur pfSense, on fait la configuration par le site WEB d'administration.
Mais dans le principe le NAT MASQUERADE et les redirections de ports doivent bien se situer sur le pfSense (c'est le but de l'architecture).

Je vais essayer les règles suivantes :

PROXMOX :

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8006 -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -j DNAT --to 10.0.0.254 (adresse IP du pfSense)

("Vous pouvez utiliser la cible `-j ACCEPT' pour laisser passer une connexion sans réaliser de NAT.")

Pour garder les paquets 80 et 8006 sur le proxmox, et rediriger le reste sur pfSense.

PFSENSE :

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -p tcp --dport 8080 -i eth0 -j DNAT --to 10.0.0.200 (SERVEUR WEB)
iptables -t nat -A PREROUTING -p tcp --dport 5432 -i eth0 -j DNAT --to 10.0.0.210 (SERVEUR BDD)

Pour faire le partage de connexion NAT et les redirections de ports.

Bonjour,

Ce que je cherche à faire est exactement l'inverse,

Ne pas rediriger les ports 80 et 8006, et rediriger tout le reste vers la pfSense.

Salut, merci pour ton retour.

Dans mon cas il s'agit d'un serveur de la filière Low-Cost de OVH (Kimsufi, serveur KS-3B), sur ces serveurs il n'est pas possible d'avoir plusieurs IP, ni d'IP failover. Donc je dois me débrouiller avec une seule IPv4.

J'ai bien compris l'architecture réseau que je dois configurer, le soucis c'est plus la mise en pratique, car j'ai peu d'expérience en réseau / iptables.

Mon soucis est de savoir comment faire passer l'ensemble du trafic TCP / UDP sur le firewall (pfSense), tout en gardant un accès au SSH et au serveur WEB du Proxmox.

Au passage, si vous connaissez un bon tuto sur le fonctionnement des iptables je suis preneur.
J'ai lu celui-ci qui est vraiment clair, mais il manque la partie NAT (http://sid.rstack.org/articles/netfilter/netfilter1.html).

Peux-tu préciser les règles IPTABLES qui permettent de "renvoyer TOUT sauf PING/SSH/8006 vers le PFsense" ?