RULES & NAT - SITEWEB
-
@jdh:
81.200.30.1/25
81.201.30.1/26
81.202.30.1/27
81.203.30.1/28Ce ne serait pas plutôt 81.200.20.1/32 pour votre 2ième adresse ip publique (présente sur WAN) ? J'aimerais bien savoir comment vous feriez la différence entre vos écritures …
Je n'avais pas fait attention aux (fausses) adresses IP ;D ;D
ça sent le copier/coller dans un tableur ;) -
Les adresses IP PUBLIQUES cités sont des exemples c'est pour le principe. J'ai créé un ALIAS regroupant les IP PUBLIQUES que j'ai besoin.
-
J'ai créé un RULE
Proto Source Port Destination Port Gateway Queue Schedule
IPv4 * IP PUBLIQUES * WAN address * * none -
J'ai créé un rule sur les adresses ip avec l'alias IP PUBLIQUES
Proto Source Port Destination Port Gateway Queue
IPv4 * IP PUBLIQUES * WAN address * * noneEt ensuite une NAT
If Proto Src. addr Src. ports Dest. addr Dest. ports NAT IP NAT Ports
WAN TCP IP PUBLIQUES * LAN address 443 (HTTPS) 192.168.1.200 443 (HTTPS)Je viens de regarder mes logs et les adresses IP PUBLIQUES ne sont pas bloques sur le firewall.
-
Il n'empêche que l'exemple est particulièrement mal choisi puisque c'est la même adresse avec des masques différents !
Ma remarque est sur ce masque !Le mieux est TOUJOURS d'indiquer une adresse publique de la forme 81.xx.xx.1, 81.xx.xx.2 et ainsi de suite …
(Cette notation permet de bien mentionner le côté 'je n'ai pas mis les vraies adresses'.)EDIT : J'ai commencé à écrire avant les 2 post supplémentaires !
Si vous souhaitez avoir des avis, il serait judicieux de mettre une copie d'écran de vos règles.
Je mentionne qu'une seule règle est nécessaire pour donner un accès à un serveur Intranet via une adresse publiques (c'est dire la difficulté).
La seul règle nécessaire est bien évidemment un NAT port forward : je l'ai décrit le 8/1.
L'utilisation d'alias dans une règle NAT ne me parait pas judicieux mais je peux me tromper.Par ailleurs, et c'est le principe de la mutualisation en http, la logique est plutôt d'avoir une seule ip publique et un serveur web capable de pousser plusieurs sites web (avec des noms différents).
-
@jdh:
Il n'empêche que l'exemple est particulièrement mal choisi puisque c'est la même adresse avec des masques différents !
Ma remarque est sur ce masque !Le mieux est TOUJOURS d'indiquer une adresse publique de la forme 81.xx.xx.1, 81.xx.xx.2 et ainsi de suite …
(Cette notation permet de bien mentionner le côté 'je n'ai pas mis les vraies adresses'.)EDIT : J'ai commencé à écrire avant les 2 post supplémentaires !
Si vous souhaitez avoir des avis, il serait judicieux de mettre une copie d'écran de vos règles.
Je mentionne qu'une seule règle est nécessaire pour donner un accès à un serveur Intranet via une adresse publiques (c'est dire la difficulté).
La seul règle nécessaire est bien évidemment un NAT port forward : je l'ai décrit le 8/1.
L'utilisation d'alias dans une règle NAT ne me parait pas judicieux mais je peux me tromper.Par ailleurs, et c'est le principe de la mutualisation en http, la logique est plutôt d'avoir une seule ip publique et un serveur web capable de pousser plusieurs sites web (avec des noms différents).
Site Distant @IP PUBLIQUE / MASK
81.XXX.XX.6/25
83.XXX.XX.8/26
94.XXX.XX.2/27
87.XXX.XX.4/28Pfsense
@IP PUBLIQUE 81.240.20.20
@IP INTRANET 192.168.1.253Site Web intranet @IP INTRANET 192.168.1.200
-
Bon, puisque vous ne semblez pas comprendre, expliquez comment, depuis Internet, accédez vous à 81.XXX.XX.6/25 ? (sous-entendu différemment de 81.xx.xx.6/32 ou /26)
La règle NAT est correcte et indique une cible claire.
Si cela pouvait vous inspirez … -
Depuis internet, les sites distants avec les adresses publiques ennoncées dans le topic doivent pouvoir communiquer avec le serveur de mon reseau informatique.
C'est pour cette raison que je pensais créer une rule autorisant ces sites à communiquer avec le wan de mon pfsense et ensuite une nat qui redirige les communication vers mon ip lan 192.168.1.200
Je suis perdu dans les solutions entre une NAT outbound, 1:1 et port forward.
-
En terme de règle sur le FW, il faut autoriser les adresses externes à accéder… à l'interface WAN.
Tu utilises bien ce concept pour ta règle de NAT.
Le sigle "∞" à gauche de ta règle de NAT signifie qu'il y a une règle de FW automatiquement créée avec cette règle de NAT.
Tu peux y accéder lorsque tu es en mode édition sur la règle de NAT ;)Et à l'occasion, tu constateras que la règle du tu crées manuellement ne marche pas car tu autorises à accès à l'IP de ton adresse LAN... sur l'adresse WAN
-
En terme de règle sur le FW, il faut autoriser les adresses externes à accéder… à l'interface WAN.
Tu utilises bien ce concept pour ta règle de NAT.
Le sigle "∞" à gauche de ta règle de NAT signifie qu'il y a une règle de FW automatiquement créée avec cette règle de NAT.
Tu peux y accéder lorsque tu es en mode édition sur la règle de NAT ;)Et à l'occasion, tu constateras que la règle du tu crées manuellement ne marche pas car tu autorises à accès à l'IP de ton adresse LAN... sur l'adresse WAN
Si je resume la situation le NAT que j'ai créé est fonctionnel car tout ce qui arrive sur le wan avec le port 443 est redirigé vers mon lan.
Mais ma rule est n'est pas operationnelle je dois crée un rule sur le wan qui autorise les adresses IP PUBLIQUES.
-
Mais ma rule est n'est pas operationnelle je dois crée un rule sur le wan qui autorise les adresses IP PUBLIQUES.
…. si tu continues ta phrase jusqu'au bout:
une règle sur le WAN qui autorise les adresses publiques à accéder à l'adresse IP WAN (et pas LAN) :P
-
Je vois que vous ne comprenez vraiment pas beaucoup !
1ère erreur :
Vos adresses 81.XXX.XX.6/25 sont stupides ! Si vous voulez ajouter des adresses virtuelles, elles seront /32, que l'on note sans le /32 par convention.J'ai eu beau l'écrire plusieurs fois, posez plusieurs fois la question 'comment on fait', vous passez sur ces âneries sans comprendre …
2ième erreur :
J'écris que la règle NAT est correcte (et qu'elle génère automatiquement une règle liée dans l'onglet WAN).
J'écris les mot 'cible claire', et vous ne comprenez pas la suite logiqueIl faut 1 règle NAT identique pour chaque ip virtuelle !
C'est quand même pas grand chose ...Ce qui aurait été intelligent, c'est de créer des règles WAN pour accepter le ping sur les ip publiques. Mais ça, vous avez oublié en route.
Perso c'est ce que je commence par faire parce que cela permet de vérifier que les ip virtuelles sont bien 'présentes' et 'actives' au niveau du WAN.En fait c'est souvent bien plus simple mais il faut juste faire ce qui est nécessaire.
Quand quelqu'un répète quelque chose, il faudrait comprendre que cela veut dire des choses ... Mais non ...