[IPTABLES] avoir l'IP source externe avec PREROUTING

Support Debian
Tags: #<Tag:0x00007f50a2ec8840>
#1

Bonjour

J’ai un réseau local avec un serveur qui reçoit les tables NAT provenant du routeur.
C’est le seul exposé à l’extérieur avec un dnsmasq qui sert à l’intérieur et à extérieur du réseau avec le même nom (ça fonctionne très bien, ce n’est pas le problème)

Mon problème:
j’ai un interphone maison avec Asterisk. Comm audio parfaite, pas de soucis de config.
J’ai un règle NAT (pour le SIP et RTP):
EXTERNE → BOX (port 5056 ) → SERVEUR (translation port 5056 vers 5058) → Interphone
Mon soucis, même avec un port autre que SIP, j’ai un nombre d’attaque SIP extrêmement importante.
EN activant FAIL2BAN, il y a bien un blocage mais ce n’est pas l’IP source mais l’IP de mon serveur local (celui entre la box et l’interphone)

iptables -t nat -A PREROUTING -p udp --dport 5056 -j DNAT --to-destination $IP_INTERPHONE:5058

Ma question:
Comment garder l’IP source externe dans le tranfert PREROUTING?

Tout le reste fonctionne parfaitement.
Merci

#2

Bonjour,

l’externe de ton Interphone c’est quoi, ou qui?
Ton serveur n’a qu’une seule interface?
Comment est activé le Fail2BAN? sa configuration?
Sur ton serveur si tu regardes les flux concernés, quelles sont les adresses IP sources/destinations de chacun des flux:

  • Le flux entrant de la BOX (la source doit être la BOX)
  • Le flux sortant vers l’interphone (la source doit être ton serveur)

Du fait du NAT, ton serveur ne voit pas les IP externes.

#3

je comprends pas trop la question … je cherche juste à avoir l’adresse IP source externe qui cherche à se connecter à mon serveur asterisk dans l’interphone.

oui 1 seule
tout le monde est dans le meme sous reseau.

il est actif uniqument sur l’interphone pour la partie asterisk, et lit les log, cela fonctionne parfaitement si je fais:
EXTERNE → BOX → INTERPHONE
Les bonnes adresses sont vus et bien bannis

avec wireshark, je vois bien l’IP externe envoyé dans le serveur, mais le serveur avec le PREROUTING change la source par sa propre adresse IP.
Je cherche juste à conserver cette adresse source avec IPTABLES si cela est possible

#4

Quand tu fais un NAT, pour toon interphone le flux ne viendra que de ton serveur. Ce qui est normal, vu que c’est une partie de la fonction de NAT.
Tout ce qui sort de ton serveur sur cette règle le sera avec l’adresse du serveur.
un forwarding lui permet de conserver l’adresse source.

#5

merci pour la reponse
le FORWARDING permet aussi de translater les ports egalements?

#6

Mais si c’est l’interphone dont le fail2ban réagit, met le fail2ban sur le serveur.

#7

pas possible, le serveur asterisk est sur l’interphone, ainsi que le log

#8

Ton fail2ban doit etre sur le server, c’est lui qui est en frontal. Ton interphone ne verra jamais les IP source du fait du NAT. C’est justement l’objectif d’un NAT, de faire de l’offuscation (masquer ce qui est derrière).
par contre ton serveur lui voit les IP source venant de la BOX. Donc c’est sur lui que ton Fail2ban doit etre mis en place.

Dans ton schema il y a un EXTERNE, c’est qui/quoi? qui ou qu’est ce qui vient se connecter sur ton interphone? l’acteur se connectant dans ton architecture.:

#9

je suis bien d’accord avec ton resonnement, mais mon serveur asterisk est dans l’interphone.
je ne peux pas scinder le serveur asterisk et le client SIP de l’interphone.
J’ai un autre FAIL2BAN dans le serveur principal et un dans l’interphone.
le probleme c’est que les logs sont ceux d’asterisk dans l’interphone qui voit l’adresse uniquement de mon serveur principal, rien d’autre !

L’externe c’est le WAN
je vais regarder FORWARD pour voir

#10

Quel est l’intérêt de faire passer le flux par le serveur au lieu de le rediriger directement sur l’interphone depuis la box ?

La règle DNAT ci-dessus ne modifie pas l’adresse source, il y a donc forcément une autre règle SNAT ou MASQUERADE qui le fait. C’est cette règle qu’il faut supprimer. Mais si l’interphone est dans le même réseau que la box, alors il y a risque de routage asymétrique direct via la box pour le trafic retour, ce qui casse le NAT qui a besoin d’un routage symétrique dans les deux sens. Contournement possible : forcer le routage du flux retour de l’interphone via le serveur et non la box.

N’importe quoi.

Faux.

#11

réponse inutile sans précision.

pareil

Mais la réponse c’est que c’est un Destination NAT et non un Source NAT. Je n’avais pas pris en compte le DNAT dans la règle iptables.

#12

l’interet c’est quand j’utilise mon VPS en tant que VPN, le seul serveur vue est mon serveur principal, c’est lui fait redistribue ensuite les données
et il y a un DNS local avec une adresse commune (WAN et LAN) quand je suis chez moi pour eviter de faire sortir les données.
Mais je le rappelle cela fonctionne deja tres bien en soit

Je n’ai pas d’autre regles PREROUTING, hormis mon VPN avec wireguard, qui est actuellement desactivé pour trouver le probleme

#13

Je ne vois pas le rapport. Peux-tu décrire les flux réseau en jeu ?

Je voulais dire une règle SNAT ou MASQUERADE (message précédent corrigé).

#14

les flux reseaux, vu que j’ai un dnsmasq avec un nom commun à tous mon réseau, que je sois à extérieure ou a l’intérieur, rien ne change pour tous mes services
et cela fonctionne tres bien!

voici mes regles IPTABLES, j’ai vité les INPUT des autres services:

# VPN WIREGUARD SERVER
iptables -A INPUT -p udp --dport $INTERFACE_VPN_SERVER_PORT -j ACCEPT
iptables -A INPUT -i $INTERFACE_VPN_SERVER -j ACCEPT
iptables -I FORWARD -i $INTERFACE_VPN_SERVER -o $INTERFACE_LAN -j ACCEPT
iptables -I FORWARD -i $INTERFACE_LAN -o $INTERFACE_VPN_SERVER -j ACCEPT
iptables -t nat -A POSTROUTING -s $IP_VPN_SERVER/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -o $INTERFACE_VPN_SERVER -j MASQUERADE
# INTERPHONE
iptables -A INPUT -p tcp --dport 5055 -j ACCEPT
iptables -t nat -A PREROUTING -p udp --dport 3478 -j DNAT --to-destination $IP_INTERPHONE:3478
#iptables -t nat -A PREROUTING -p udp --dport 5056 -j DNAT --to-destination $IP_INTERPHONE:5058
iptables -t nat -A PREROUTING -p tcp --dport 5056 -j DNAT --to-destination $IP_INTERPHONE:5058
iptables -t nat -A PREROUTING -p udp -m multiport --dports 6000:7000 -j DNAT --to-destination $IP_INTERPHONE:4000-5000
iptables -t nat -A PREROUTING -p tcp -m multiport --dports 6000:7000 -j DNAT --to-destination $IP_INTERPHONE:4000-5000
iptables -t nat -A POSTROUTING -d $IP_INTERPHONE -p tcp --dport 5058 -j MASQUERADE
iptables -t nat -A POSTROUTING -d $IP_INTERPHONE -p udp --dport 5058 -j MASQUERADE
iptables -t nat -A POSTROUTING -d $IP_INTERPHONE -p udp -m multiport --dports 4000:5000 -j MASQUERADE
iptables -t nat -A POSTROUTING -d $IP_INTERPHONE -p udp -m multiport --dports 4000:5000 -j MASQUERADE
iptables -A INPUT -i $INTERFACE_LAN -s 0.0.0.0/32 -d 224.0.0.1/32 -p igmp -j ACCEPT
iptables -A INPUT -i $INTERFACE_LAN -d 239.0.0.0/8 -p igmp -j ACCEPT
iptables -A INPUT -m pkttype --pkt-type multicast -j ACCEPT
#iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -A INPUT -j ACCEPT -m conntrack --ctstate RELATED,ESTABLISHED
iptables -A INPUT -j ACCEPT -i lo
# Dropper silencieusement tous les paquets broadcastés.
iptables -A INPUT -m pkttype --pkt-type broadcast -j DROP
# Droping all invalid packets
iptables -A INPUT -m state --state INVALID -j DROP
# INTERDIT LE RESTE
#iptables -A INPUT -p all -j DROP
sudo iptables -N LOGGING
sudo iptables -A INPUT -j LOGGING
sudo iptables -A LOGGING -j LOG --log-prefix  "IPT DENIED: " --log-level 4
sudo iptables -A LOGGING -j DROP
iptables -A FORWARD -m state --state INVALID -j DROP

Il est possible que les regles ne soient pas parfaites !

#15

Cela ne répond pas à ma question.

C’est à cause de ces règles que les connexions arrivent à l’interphone avec l’adresse source du serveur. Avant de les supprimer, relis bien mon message précédent concernant le routage asymétrique.

#16

Si je supprime ces règles, plus d’enregistrement SIP …

en clair il me faudrait une regle ce type
iptables -t nat -A POSTROUTING -p tcp -j SNAT --to-source $IP_INTERPHONE:5056

#17

Non, il te faut un routage symétrique. Le NAT source n’est qu’une (mauvaise) façon parmi d’autres d’y parvenir.

#18

Routage symétrique, je ne connais pas.
Je dois créer un sous réseau pour cela?

#19

A toi de voir, du moment que les paquets retour passent par le serveur.
Le routage avancé est une autre option.
Ce n’est pas pour rien que je te demandais de décrire les flux réseau.

#20

Le serveur indiqué est le VPS? ou le VPS est un quatrième élément dans l’architecture?