[résolu] apache derrière un firewall iptables

Support Debian
#1

Bonjour,

le nat fonctionne mon site est accessible de l’extérieur mais tout les utilisateurs s’enregistre dans le acces.log avec l’ip du firewall

mon infra se présente comme ceci :

internet -> (eth0)firewall(iptables)192.168.0.253 (eth0)-> (etch0)serveur web(apache)192.168.0.220

[code]echo “1” > /proc/sys/net/ipv4/ip_forward

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

iptables -t mangle -F
iptables -t nat -F
iptables -F
iptables -t mangle -X
iptables -t nat -X
iptables -X
iptables -Z

iptables -t nat -A POSTROUTING -p tcp -o eth0 --dport 80 -j MASQUERADE
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j DNAT --to-destination 192.168.0.220:80[/code]

mon problème viens t’il de la configuration d’iptables ou de apache ?

merci

#2

Salut
Moi, ce que je comprends dans ton infrastructure, c’est que tu essais de faire du nat avec une seule interface (eth0). Donc, pour chaque connexion, cette interface est à la fois interface d’entrée et interface de sortie, donc, au vue de tes règles, quand un client se connecte à ton serveur, les paquets subissent dans l’ordre :

  • dans un premier temps les modification “prerouting/DNAT” en entrée (substitution de l’adresse publique de destination par l’adresse privée du serveur web)
  • PUIS modification “postrouting/masquerade” en sortie, au cours de laquelle l’adresse source de la trame est remplacée par l’adresse de l’interface de sortie, soit l’adresse IP de ton firewall, ce qui explique que c’est cette adresse qui se retrouve dans les logs.
    Tu te fais du masquerading à toi même en fait :005

Bon, je me trompe peut être, je débute en iptables :blush:
:006

#3

Non, c’est bon.

#4

J’ai prit en compte vos remarque j’ai rajouté une carte réseau a mon firewall ainsi que supprimé le MASQUERADE, résultat les utilsateurs d’internet se connecte et mon serveur apache me donne les bonnes IP, mais quand je veux me connecter du réseau local ca ne fonctionne pas !!

internet ->(IPEXTERNE)freebox(IPINTERNE)->(ETH0_192.168.0.253)firewall(iptables)(ETCH1_192.168.0.252)->(ETCH0-192.168.0.220)serveur web

ordinateur client (ETCH0_192.168.0.12)

ping monsiteduserveurapache.com = IPEXTERNE

[code]
echo “1” > /proc/sys/net/ipv4/ip_forward

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

iptables -t mangle -F
iptables -t nat -F
iptables -F
iptables -t mangle -X
iptables -t nat -X
iptables -X
iptables -Z

iptables -t nat -A PREROUTING -j DNAT -i eth0 -s 0.0.0.0/0 -d 192.168.0.253 -p TCP --dport 80 --to-destination 192.168.0.220
iptables -t nat -A POSTROUTING -o eth1 -s 0.0.0.0/0 -d 192.168.0.220 -p tcp --dport 80 -m state --state ! INVALID -j SNAT --to-source 192.168.0.252[/code]

une idée ? merci

#5

C’est normal et la solution est simple, mais tes IPs ont l’air curieuses, peux tu donner ton ifconfig?

#6

Je me pose quand même une question : à quoi sert un pare feu qui ne filtre rien, et dont les interfaces d’entrée et de sortie sont sur le même réseau (au vue des adresses, bien qu’on n’ait pas le masque de sous réseau…) ?
Un Nat sur la freebox pour les accès de l’extérieur suffit dans ce cas là, non ?

De plus, quand tu dis te connecter depuis le réseau local : c’est en utilisant l’adresse locale du serveur web, ou l’adresse publique de la freebox ?

#7

firewall :

[code]eth0 Link encap:Ethernet HWaddr
inet addr:192.168.0.253 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:28501 errors:0 dropped:0 overruns:0 frame:0
TX packets:19102 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4233251 (4.0 MiB) TX bytes:5566128 (5.3 MiB)

eth1 Link encap:Ethernet HWaddr
inet addr:192.168.0.252 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6966 errors:0 dropped:0 overruns:0 frame:0
TX packets:172 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2428228 (2.3 MiB) TX bytes:7224 (7.0 KiB)[/code]
web server

eth0 Link encap:Ethernet HWaddr inet addr:192.168.0.220 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:172788 errors:0 dropped:0 overruns:0 frame:0 TX packets:182137 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:32850799 (31.3 MiB) TX bytes:60181448 (57.3 MiB)

poste client

toutes les machines sont pingables le serveur web à 192.168.0.252 en route par défault et mon poste client accède au net

#8

[quote=“dric64”]Je me pose quand même une question : à quoi sert un pare feu qui ne filtre rien, et dont les interfaces d’entrée et de sortie sont sur le même réseau (au vue des adresses, bien qu’on n’ait pas le masque de sous réseau…) ?
Un Nat sur la freebox pour les accès de l’extérieur suffit dans ce cas là, non ?

De plus, quand tu dis te connecter depuis le réseau local : c’est en utilisant l’adresse locale du serveur web, ou l’adresse publique de la freebox ?[/quote]

il ne filtre rien car pour l’instant je veux juste valider la connexion au site apache derrière la passerelle,

après tu as tout à fait raison il faudra que ce soit plus restrictif et séparer les réseaux

et c’est d’ailleur le but de ma démarche mais chaque chose en son temps :slight_smile:

#9

[quote=“voodoo_”][quote=“dric64”]Je me pose quand même une question : à quoi sert un pare feu qui ne filtre rien, et dont les interfaces d’entrée et de sortie sont sur le même réseau (au vue des adresses, bien qu’on n’ait pas le masque de sous réseau…) ?
Un Nat sur la freebox pour les accès de l’extérieur suffit dans ce cas là, non ?

De plus, quand tu dis te connecter depuis le réseau local : c’est en utilisant l’adresse locale du serveur web, ou l’adresse publique de la freebox ?[/quote]

il ne filtre rien car pour l’instant je veux juste valider la connexion au site apache derrière la passerelle,

après tu as tout à fait raison il faudra que ce soit plus restrictif et séparer les réseaux

et c’est d’ailleur le but de ma démarche mais chaque chose en son temps :)[/quote]

D’accord :005

#10

Bon je vais essayer de trouver pourquoi tu n’accèdes pas à ton serveur en réseau local, en partant du principe que tu utilises l’ip locale pour t’y connecter :
Client et serveur étant sur le même réseau, ton client doit essayer d’accéder au serveur directement. Or ce dernier est planqué connecté directement derrière le pare feu d’apres ce que j’ai compris, donc il n’arrive pas à le joindre : je dirais qu’il te manque une route sur le client pour lui dire par ou passer (par 192.168.0.253) pour joindre le .220 qui est bien caché connecté directement derrière.
J’ai bon ? :115

#11

[quote=“dric64”]Bon je vais essayer de trouver pourquoi tu n’accèdes pas à ton serveur en réseau local, en partant du principe que tu utilises l’ip locale pour t’y connecter :
Client et serveur étant sur le même réseau, ton client doit essayer d’accéder au serveur directement. Or ce dernier est planqué connecté directement derrière le pare feu d’apres ce que j’ai compris, donc il n’arrive pas à le joindre : je dirais qu’il te manque une route sur le client pour lui dire par ou passer (par 192.168.0.253) pour joindre le .220 qui est bien caché connecté directement derrière.
J’ai bon ? :115[/quote]

bon ca vas peut être sembler tordu :slight_smile: mais le dns du site est externe donc quand 192.168.0.12 tente d’aller sur 192.168.0.220 il repasse par l’ip externe de la freebox, et la connexion ne se fait pas :neutral_face:

#12

Hummm, j’ai déjà entendu ca quelque part, que certains FAI bloquent l’accès à certains services (web notamment) lorsque les connexions à ces derniers sont initiées depuis le LAN, vers sa propre IP publique (connexion aller/retour par l’extérieur) :017 Sur ce forum d’ailleurs il me semble, mais il était chez orange, et avait un problème avec un serveur web de musique en line qu’il hébergeait sur son réseau local aussi.

#13

en mettant les rêgles iptables de mon premier post,

192.168.0.12 accède au site sans problème mais avec l’ip 192.168.0.253 (je viens de retester)

un vrai casse tête :033

#14

dans ta premiere installation, la freebox n’est pas en mode routeur, si ?

#15

la freebox est en mode routeur depuis le début, je jongle avec l’ancienne et la nouvelle conf à la volé

#16

je viens de tester sur la mienne, je peux me connecter a mon serveur web sans problème en utilisant l’adresse lan, ou l’adresse wan, donc j’ai du me rêver ce problème imaginaire.
Tu as fait quoi comme redirection sur ta freebox ?

#17

[quote=“dric64”]je viens de tester sur la mienne, je peux me connecter a mon serveur web sans problème en utilisant l’adresse lan, ou l’adresse wan, donc j’ai du me rêver ce problème imaginaire.
Tu as fait quoi comme redirection sur ta freebox ?[/quote]
un forwarding du port 80 sur l’ip 192.168.0.253

j’ai fait un tcpdump sur le firewall

192.168.0.254 étant la patte interne de la freebox :

avec la nouvelle règle c’est la 254 qui requète le serveur web (c’est la que serait le problème non ? ):

avec l’ancienne c’est le 253 qui requète

avec la nouvelle règle le site ne fonctionne pas :

192.168.0.254.59768 > 192.168.0.253.www: S, cksum 0xa136 (correct), 2312810015:2312810015(0) win 192.168.0.254.59768 > 192.168.0.220.www: S, cksum 0xa157 (correct), 2312810015:2312810015(0) win

avec l’ancienne règle le site fonctionne :

192.168.0.254.59770 > 192.168.0.253.www: S, cksum 0xe93b (correct), 1958050 192.168.0.253.59770 > 192.168.0.220.www: S, cksum 0xe95d (correct), 1958050210:1958050210(0) win 192.168.0.220.www > 192.168.0.253.59770: S, cksum 0x2bc9 (correct), 3752434926:3752434926(0) ack 192.168.0.253.www > 192.168.0.254.59770: S, cksum 0x2ba7 (correct), 3752434926:3752434926(0) ack 192.168.0.254.59770 > 192.168.0.253.www: ., cksum 0x7111 (correct), 1:1(0) ack 1 win 65535 192.168.0.253.59770 > 192.168.0.220.www: ., cksum 0x7133 (correct), 1:1(0) ack 1 win 65535 192.168.0.254.59770 > 192.168.0.253.www: P 1:640(639) ack 1 win 65535 <nop,nop,timestamp 192.168.0.253.59770 > 192.168.0.220.www: P 1:640(639) ack 1 win 65535 <nop,nop,timestamp 192.168.0.220.www > 192.168.0.253.59770: ., cksum 0x6dd5 (correct), 1:1(0) ack 640 win 221 192.168.0.253.www > 192.168.0.254.59770: .,

#18

Humm, il doit te manquer des règles Forward, pour dire au firewall qu’il doit faire transiter les paquets arrivant sur le port 80 de la premiere interface du firewall, vers l’autre interface, celle reliée au serveur web :017

#19

[quote=“voodoo_”]firewall :

[code]eth0 Link encap:Ethernet HWaddr
inet addr:192.168.0.253 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:28501 errors:0 dropped:0 overruns:0 frame:0
TX packets:19102 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4233251 (4.0 MiB) TX bytes:5566128 (5.3 MiB)

eth1 Link encap:Ethernet HWaddr
inet addr:192.168.0.252 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6966 errors:0 dropped:0 overruns:0 frame:0
TX packets:172 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2428228 (2.3 MiB) TX bytes:7224 (7.0 KiB)[/code]
web server

eth0 Link encap:Ethernet HWaddr inet addr:192.168.0.220 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:172788 errors:0 dropped:0 overruns:0 frame:0 TX packets:182137 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:32850799 (31.3 MiB) TX bytes:60181448 (57.3 MiB)

poste client

toutes les machines sont pingables le serveur web à 192.168.0.252 en route par défault et mon poste client accède au net[/quote]

Tu as 2 interfaces qui sont sur le même réseaux, tôt ou tard tu auras des soucis.

Pour ton problème, un indice: C’est un problème souvent évoqué ici (la dernière fois, c’était il y a une semaine en gros) et rappele toi qu’une connexion, c’est un couple IP1-IP2. Si IP1 interroge IP2 et que IP3 lui répond, ça n’ira pas. Mais règle cette histoire de deux interfaces sur le même réseau, tu vas avoir des soucis.

#20

Rajoute :

#forward des paquets arrivant sur eth0 vers eth1
iptables -t filter -A FORWARD -i eth0 -o eth1 -s 0.0.0.0/0 -d 192.168.0.220 -p tcp --dport 80 -m state ! --state INVALID -j ACCEPT

#réponses à ces paquets par le serveur
iptables -t filter -A FORWARD -i eth1 -o eth0 -s 192.168.0.220 -d 0.0.0.0/0 -p tcp --sport 80 -m state --state RELATED,ESTABLISHED -j ACCEPT

Corrige celle la :
iptables -t nat -A PREROUTING -j DNAT -i eth0 -s 0.0.0.0/0 -d 192.168.0.253 -p TCP --dport 80 --to-destination 192.168.0.220

par

iptables -t nat -A PREROUTING -j DNAT -i eth0 -s 0.0.0.0/0 -d 192.168.0.253 -p TCP --dport 80 --to-destination 192.168.0.220:80

Tu retires ta directive POSTROUTING sans quoi, tu vas avoir le même problème que la dernière fois, c’est à dire des logs qui indiquent que le client est toujours le pare feu (normal, ils se substitue à l’adresse source réelle pour que les paquets retours puissent retrouver leur chemin, c’est en fait le même “problème” qu’avec masquerade…).

Et tu vérifies bien que la route par défaut sur ton serveur web est bien la patte du pare feu à laquelle il est relié 192.168.0.152 je crois sinon, il ne saura plus par quel chemin répondre au requête puisqu’on à supprimé le postrouting.

J’espère que je ne me suis pas mélangé les pinceaux :017