[IPTABLES] avoir l'IP source externe avec PREROUTING

Support Debian
Tags: #<Tag:0x00007f509f786d78>
#25

Juste une question, un interphonboe c’est pour une tilisation locale, donc à travers internet on se demande un peu à quoi ça sert? Ou c’est le mot interphone qui n’est pas adapté.

ta BOX, si elle est en panne du bascule sur de la 4G c’est ça?
De quel FAi s’agit-il pour ta box? Certains FAi ont des Box qui permettent des connexions VPN. De ce fait pas besoin de faire le VPN jusqu’au serveur (et ca sera plus propre).
D’ailleurs si le VPS peut faire un VPN vers ton infra, alors ce qui te sert à te connecter sur ton VPS peut tout aussi bien directement se connecter sur ton infra sans le VPS.

Mais le vrai besoin, c’est toujours qu’est ce qui vient se connecter sur ton « interphone »? tu ne nous as toujours pas dit de ce qu’il s’agissait.

#26

L’utile l’interphone se fait soit en local ou par le WAN, sinon pas besoin de redirige le flux comme je le fait.
Il aurait été direct sans aucune redirection.

La box bascule en 4g si problème, c’est une box Bouygues Télécom avec mon propre routeur en plus.
En 4G ce n’est que du CGNAT, même chez orange aujourd’hui…

Mon VPS ne sert qu’en cas de perte de lien ADSL.
Mais je le rappelle, tout le réseau fonctionne très bien, scripts et autre.

Ceux qui se connectent sur l’interphone sont les applications SIP des téléphones.

Mon seul problème étant de ne pas avoir les adresses IP externes qui sont perdu avec ma règles IPTABLES PREROUTING.
je cherche donc une solution à cela si elle existe.

#27

Asséner des évidences ne m’explique toujours pas le rapport avec PREROUTING.

Je ne vois pas ce routeur dans ton schéma.

Je t’ai expliqué en long en large et en travers que les règles DNAT dans PREROUTING n’avaient rien à voir avec le masquage de l’adresse IP source qui est causé uniquement par les règles MASQUERADE dans POSTROUTING. Si tu continues à t’obstiner je vais te laisser te débrouiller…
Pourquoi as-tu mis en place ces règles MASQUERADE, quelle est leur utilité ?

#28

Je veux juste que tout mon traffic passe par mon serveur principal

C’est une box ADSL (bridge) de chez bouygues telecom avec un routeur 4G et WAN relié sur la box (un TP LINK MR600, impossible à patcher avec openwrt …)

J’ai bien compris cela, je m’obstine pas, je cherche à comprendre !
Plus haut, tu me parles de routage dynamique, que je ne connais pas …
Le MASQUERADE sert juste à retourner les paquets provenant de l’interphone vers le serveur
Franchement je ne vois pas comment je peux me passer de POSTROUTING (sans MASQUERADE) mais il faut bien que je redirige mes paquets.
Si j’utilise SNAT, je ne peux plus m’enregistrer sur asterisk …

#29

Non, je n’ai pas parlé de ça.

En d’autres termes, MASQUERADE te sert à assurer un routage symétrique. Et bien il va falloir trouver un autre moyen.

Il y a pourtant bien d’autres moyens de forcer l’interphone à envoyer son trafic au serveur, par exemple :

  • Route par défaut via le serveur
  • Routage avancé basé sur l’adresse source, le port source, une marque de connexion…
  • Interphone dans un sous-réseau distinct de celui du routeur

SNAT ne vaut pas mieux que MASQUERADE, c’est aussi du NAT source.

Le NAT, c’est toujours une solution de facilité pour masquer un problème de routage au lieu de le résoudre. Mais parfois au prix d’effets de bord.

#30

Bonjour,

Elles sont perdues depuis « ta/tes » boxes… dirais-je…

Il y a peut-être une solution mais cela concernerait quelques chose par rapport à fail2ban - c’est ici que tu souhaites « voir/savoir » l’adresse IP externe du client ?

Essaies de chercher « FIND REMOTE IP ADDRESS fail2ban derrière proxy reverse » (un peu comme dans Apache (serveur Web) quand tu as des reverses proxy Apache devant tes serveurs Web et que du coup tu vois les adresses IP locales des serveurs Web frontaux/proxy. Donc il faut changer une « variable de logs » dans le serveur Web que tu logs.

Ou une recherche de ce type.

  • Dans apache, pour les logs c’est la variable %{X-Forwarded-For}i à la place %h

  • En PHP pour le code, c’est la variable $_SERVER["HTTP_X_FORWARDED_FOR"] à la place de $_SERVER["REMOTE_ADDR"]

  • En python : get client ip → je n’en sais rien :wink:

J’ajoute ce « tag » : X-Real-IP

Parce qu’on parle de l’adresse du client et donc c’est sur le serveur d’applications que tu dois chercher des informations… iptables sert à rediriger les paquets « seulement » .
Le client (logiciel) lui, à envoyer son « adresse IP » dans les paquets, donc sur tout le bout de la chaine de transmission (en entré), l’adresse IP publique doit y être et normalement c’est la variable du dessus et cela jusqu’au logiciel (donc du même protocole).

:slight_smile:

Bon courage.

#31

J’ai trouvé çà :

Using the X-Forwarded-For HTTP header to preserve the original client IP address for traffic translated by a SNAT object

Les mecs, ils ajoutent un « header » ou ils cherchent la variable " X_FORWARDED" si j’ai bien compris.

Je n’ai jamais travailler sur un serveur SIP / Asterisk ni avec fail2ban.

Bon, ok, la honte koi :face_with_raised_eyebrow:

Par contre si tu veut une IP publique/externe de tes clients derrière un « proxy » (je dis cela, puisque tu vois les adresses IP locales de ton serveur(s), donc il doit y avoir un reverse dedans/quelque part), il faut, donc chercher comment configurer/avoir X_FORWARDED_FOR à la place de HOST ou REMOTE_ADDR sur ton interphone.

:wink:

#32

ça signifie qu’il faut proxifier, utiliser un HAProxy ou un nginx/apache en mode proxy (HAProxy est préférable en terme de sécurité et d’efficacité).

#33

Je disais cela, puisqu’il voit sur son « interphone » les adresses IP locales. Donc, il doit déjà en avoir un de proxy sûrement.

Comme tu as dis @Zargos, bonjour @Zargos,

  1. soit NGINX
  2. soit Apache
  3. soit HAproxy

Et si c’est pour les bannir (parce qu’il se fait flooder, j’ai cru lire), çà doit être dans la configuration de fail2ban.

Oui HAProxy c’est mieux (jamais utilisé). Il faudrait :slight_smile:

Romain

#34

Non, seulement depuis le serveur intermédiaire qui fait du NAT source.

Le flux concerné est du protocole SIP, donc un proxy web est hors de propos.

#35

Alors moi, je n’en sais rien, mais :

Caractéristiques induites du SIP ( Session Initiation Protocol)

…
Basé sur l’adresse IP : cela induit que le SIP ne traverse pas les NAT (mais cela peut être résolu en déployant des mécanismes client-serveur supplémentaires comme STUN ou en couplant SIP avec Jabber) ;
…

IAX: Inter-Asterisk eXchange Version 2 - 7.3 : Considérations NAT

IAX est très bien adapté pour fonctionner derrière NAT en raison de son approche à port unique. Cette approche élimine tout délai de début d’appel de flux multimédia pendant que la passerelle NAT établit une association de port bidirectionnelle. Le déploiement d’un seul serveur IAX derrière une passerelle NAT nécessite peu d’efforts. Si le serveur agit en tant que bureau d’enregistrement, le port UDP IAX sur la passerelle NAT doit être transmis au serveur. Si le serveur agit en tant qu’inscrit, le temporisateur d’actualisation REGREQ de 60 secondes par défaut devrait être suffisant pour maintenir une association de port dans la passerelle NAT ; cependant, un mappage de port statique est préférable.

Si plusieurs serveurs doivent être déployés derrière une seule passerelle NAT, la plupart des passerelles NAT exigent que chaque serveur IAX utilise différents ports UDP.
Bien sûr, il peut y avoir des implémentations NAT qui reconnaissent quand plusieurs appareils utilisent le même port privé et le gèrent de manière appropriée.

NdMoi-même : Pour mes infos personnelles :slight_smile:

#36

La boxe ne fait pas du NAT ?

:rofl:

Je fais des règles de routage sur ma boxe, et sur chacun des routeurs pour par exemple attraper un serveur web sur un de mes ordinateurs.

Perso, j’ai ma boxe internet, avec un seul fil réseau vers un routeur, puis un autre seul fil sur le routeur vers un autre routeur, puis encore un seul fil sur le routeur vers (le dernier) routeur que j’ai acheté où j’ai branché mes ordinateurs - Je rigole, ou pas :slight_smile:
Tout çà sur des réseaux différents puis ma plage d’adresses réseaux locales de mes ordinateurs.

Question de confidentialité :rofl:

Donc le stagiaire du FAI il est en galère :smiley: pour attraper un de mes postes (dirais-je). Pourtant :smiley: …

#37

Juste comme ça, le routage ça ne protège pas :slight_smile:

#38

Juste comme ça, les routeurs oui, me protège. Mais je suis conscient que d’ouvrir un port de communication, c’est dangereux surtout sur des protocoles de Paire à Paire - tous « 2 » serveurs où l’on pourrait écrire un code malfaisant et me l’injecter au plus profond de moi :smiley:

Bonne journée, soirée.

#39

Mon soucis n’a rien à voir avec la box, le schéma plus haut vaut mieux qu’un long discours.
Je teste le routage avancé avec le marquage du port.
Je mettrais la solution quand cela fonctionnera.

#40

Bonjour @crashcoq tu as lu mon commentaire 30 la solution y est peut-être.

çà c’est bien :smiley: de lire çà :wink:

Bonne soirée et bon courage.

#41

Rien avoir avec le protocole HTTP, c’est du SIP …

#42

C’est presque pareil, c’est du streaming, une session par annoncement de demande pour ne pas multicaster en permannance tout les ports du/des routeurs et surcharger le réseaux interne et en l’occurrence aussi le réseau mondial.

Çà doit passer dans la couche IGMP (v3) Internet Group Management Protocol qui fait partit des Internet layer protocols (Protocoles de la couche Internet).

#43

Presque sauf que du SIP, la partie signalisation c’est TCP ou UDP mais le RTP c’est UDP …

#44

L’utilisation du routage avancé n’est pas triviale, il y a plein de petits pièges abscons (jeu de mots volontaire) à éviter.
N’hésite pas à demander si tu as des doutes, des questions…

1 J'aime