impossible de répondre directement dans le fil, suis obligé de le
recréer
>Message n° 2 de ce fil
>De :Pascal@plouf (pascal@plouf.invalid)
>Objet :Re: PB avec le MASQUERADING
>Date :2005-01-13 16:32:19 PST
>
>Salut,
>
>googlio a écrit :
>> J'ai un problème de MASQUERADING. Vient-il de IPTABLES ? Je
l'ignore.
>
>Es-tu obligé de CRIER ?
Je le refera plus...
>> Le voici: J'ai un poste linux qui route ma connexion internet par
>> modem pour mon LAN. Le masquerading fonctionne mais j'ai découvert
par
>> hazard grace aux logs que
>>
>> 1. Des paquets à destination de 192.168.x.y (une station du LAN
autre
>> que le routeur) transitent sur le firewall (table FILTER)
>
>C'est parfaitement normal. Les opérations de masquerading et de
>dé-masquerading ont lieu respectivement dans les chaînes POSTROUTING
et
>PREROUTING de la table nat. Donc les paquets qui traversent la chaîne
>FORWARD de la table filter portent l'adresse privée de la station qui
>émet ou reçoit ces paquets.
Problème: ce n'est pas ce que je vois habituellement dans les logs. La
plupart du temps, l'IP destination des paquets entrants logués par la
table filter est mon IP publique... Si la connexion n'est pas
relative, le masquerading n'a pas lieu ? Ce serait normal aussi ?
>Règle importante : *on ne doit pas* faire de filtrage dans la table
nat
Merci, c'est noté
>> Ceux que je vois sont filtrés parcequ'ils arrivent en
>> grand nombre avec un flag RST.
>
>Tu filtres sur quel critère exactement ? Il n'est pas anormal de
>recevoir un tel paquet, il peut simplement correspondre à une demande
de
>connexion TCP d'une de tes machines locales qui a été refusée par la
>machine distante (port fermé).
J'autorise 2 RST par minute (burst) en entrée, puis 1 (limite), ce qui
ne provoque aucun filtrage la plupart du temps. Lorsque je surfe sur
le site de mon FAI, et un ou deux autres, il y en a plein qui
arrivent, logués, eux, avec une IP destination privée, ce qui voudrait
donc dire qu'ils sont en effet relatifs à une multitude de tentatives
de connexion de mon browser sur des ports fermés, mais je ne vois pas
de cohérence là dedans...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal
impossible de répondre directement dans le fil, suis obligé de le recréer
Eh oui, c'est Google qui merde encore et toujours... Non content de sabrer les références et les suivis, il massacre aussi la citation.
C'est parfaitement normal. Les opérations de masquerading et de dé-masquerading ont lieu respectivement dans les chaînes POSTROUTING et PREROUTING de la table nat. Donc les paquets qui traversent la chaîne FORWARD de la table filter portent l'adresse privée de la station qui émet ou reçoit ces paquets.
Problème: ce n'est pas ce que je vois habituellement dans les logs. La plupart du temps, l'IP destination des paquets entrants logués par la table filter est mon IP publique...
Logués à quel endroit ? Tu pourrais fournir tes règles iptables ?
Si la connexion n'est pas relative, le masquerading n'a pas lieu ? Ce serait normal aussi ?
Si un paquet entrant destiné à l'adresse publique du routeur ne correspond pas ou n'est pas lié à une connexion établie masqueradée, le dé-masquerading n'a aucune raison d'avoir lieu. Le paquet est dirigé dans la chaîne INPUT et ne passe pas dans FORWARD. Il n'y a aucune raison pour qu'un tel paquet traverse la chaîne FORWARD.
J'autorise 2 RST par minute (burst) en entrée, puis 1 (limite), ce qui ne provoque aucun filtrage la plupart du temps.
Pourquoi diable limiter les RST ? Il y a deux types de paquets RST : les attendus, correspondant à un SYN émis, identifiables grâce au suivi de connexion (--state ESTABLISHED ou RELATED), et les autres. Les premiers doivent être acceptés sans limitation, les autres bloqués systématiquement.
Lorsque je surfe sur le site de mon FAI, et un ou deux autres, il y en a plein qui arrivent, logués, eux, avec une IP destination privée, ce qui voudrait donc dire qu'ils sont en effet relatifs à une multitude de tentatives de connexion de mon browser sur des ports fermés, mais je ne vois pas de cohérence là dedans...
Peut-être des liens périmés pointant sur des sites fermés.
impossible de répondre directement dans le fil, suis obligé de le
recréer
Eh oui, c'est Google qui merde encore et toujours... Non content de
sabrer les références et les suivis, il massacre aussi la citation.
C'est parfaitement normal. Les opérations de masquerading et de
dé-masquerading ont lieu respectivement dans les chaînes POSTROUTING et
PREROUTING de la table nat. Donc les paquets qui traversent la chaîne
FORWARD de la table filter portent l'adresse privée de la station qui
émet ou reçoit ces paquets.
Problème: ce n'est pas ce que je vois habituellement dans les logs. La
plupart du temps, l'IP destination des paquets entrants logués par la
table filter est mon IP publique...
Logués à quel endroit ? Tu pourrais fournir tes règles iptables ?
Si la connexion n'est pas
relative, le masquerading n'a pas lieu ? Ce serait normal aussi ?
Si un paquet entrant destiné à l'adresse publique du routeur ne
correspond pas ou n'est pas lié à une connexion établie masqueradée, le
dé-masquerading n'a aucune raison d'avoir lieu. Le paquet est dirigé
dans la chaîne INPUT et ne passe pas dans FORWARD. Il n'y a aucune
raison pour qu'un tel paquet traverse la chaîne FORWARD.
J'autorise 2 RST par minute (burst) en entrée, puis 1 (limite), ce qui
ne provoque aucun filtrage la plupart du temps.
Pourquoi diable limiter les RST ?
Il y a deux types de paquets RST : les attendus, correspondant à un SYN
émis, identifiables grâce au suivi de connexion (--state ESTABLISHED ou
RELATED), et les autres. Les premiers doivent être acceptés sans
limitation, les autres bloqués systématiquement.
Lorsque je surfe sur
le site de mon FAI, et un ou deux autres, il y en a plein qui
arrivent, logués, eux, avec une IP destination privée, ce qui voudrait
donc dire qu'ils sont en effet relatifs à une multitude de tentatives
de connexion de mon browser sur des ports fermés, mais je ne vois pas
de cohérence là dedans...
Peut-être des liens périmés pointant sur des sites fermés.
impossible de répondre directement dans le fil, suis obligé de le recréer
Eh oui, c'est Google qui merde encore et toujours... Non content de sabrer les références et les suivis, il massacre aussi la citation.
C'est parfaitement normal. Les opérations de masquerading et de dé-masquerading ont lieu respectivement dans les chaînes POSTROUTING et PREROUTING de la table nat. Donc les paquets qui traversent la chaîne FORWARD de la table filter portent l'adresse privée de la station qui émet ou reçoit ces paquets.
Problème: ce n'est pas ce que je vois habituellement dans les logs. La plupart du temps, l'IP destination des paquets entrants logués par la table filter est mon IP publique...
Logués à quel endroit ? Tu pourrais fournir tes règles iptables ?
Si la connexion n'est pas relative, le masquerading n'a pas lieu ? Ce serait normal aussi ?
Si un paquet entrant destiné à l'adresse publique du routeur ne correspond pas ou n'est pas lié à une connexion établie masqueradée, le dé-masquerading n'a aucune raison d'avoir lieu. Le paquet est dirigé dans la chaîne INPUT et ne passe pas dans FORWARD. Il n'y a aucune raison pour qu'un tel paquet traverse la chaîne FORWARD.
J'autorise 2 RST par minute (burst) en entrée, puis 1 (limite), ce qui ne provoque aucun filtrage la plupart du temps.
Pourquoi diable limiter les RST ? Il y a deux types de paquets RST : les attendus, correspondant à un SYN émis, identifiables grâce au suivi de connexion (--state ESTABLISHED ou RELATED), et les autres. Les premiers doivent être acceptés sans limitation, les autres bloqués systématiquement.
Lorsque je surfe sur le site de mon FAI, et un ou deux autres, il y en a plein qui arrivent, logués, eux, avec une IP destination privée, ce qui voudrait donc dire qu'ils sont en effet relatifs à une multitude de tentatives de connexion de mon browser sur des ports fermés, mais je ne vois pas de cohérence là dedans...
Peut-être des liens périmés pointant sur des sites fermés.
