NetFilter, soucis avec DNAT

Le
Eric Masson
'Soir,

Le lan@home est gardé par un OpenWRT sur lequel j'ai mis en place une
redirection du tcp/443 vers un serveur interne, cependant, ça ne
fonctionne pas des masses.

iptables me retourne les éléments suivants :

root@rtrwrtfenint:~# iptables -n -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
prerouting_rule all -- 0.0.0.0/0 0.0.0.0/0

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
postrouting_rule all -- 0.0.0.0/0 0.0.0.0/0
MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain postrouting_rule (1 references)
target prot opt source destination

Chain prerouting_rule (1 references)
target prot opt source destination
prerouting_vlan1 all -- 0.0.0.0/0 0.0.0.0/0

Chain prerouting_vlan1 (1 references)
target prot opt source destination
ACCEPT udp -- 0.0.0.0/0 217.128.200.48 multiport dports 500
ACCEPT udp -- 0.0.0.0/0 217.128.200.48 multiport dports 4500
ACCEPT tcp -- 0.0.0.0/0 217.128.200.48
DNAT tcp -- 0.0.0.0/0 217.128.200.48 multiport dports 443 to:192.168.85.1:443
root@rtrwrtfenint:~# iptables -n -L
Chain INPUT (policy DROP)
target prot opt source destination
DROP all -- 0.0.0.0/0 0.0.0.0/0 state INVALID
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp option=!2 flags:0x02/0x02
input_rule all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 47 -- 0.0.0.0/0 0.0.0.0/0
REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable

Chain FORWARD (policy DROP)
target prot opt source destination
DROP all -- 0.0.0.0/0 0.0.0.0/0 state INVALID
TCPMSS tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
forwarding_rule all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy DROP)
target prot opt source destination
DROP all -- 0.0.0.0/0 0.0.0.0/0 state INVALID
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
output_rule all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable

Chain forward_vlan1 (1 references)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 192.168.85.1 tcp dpt:443

Chain forwarding_rule (1 references)
target prot opt source destination
forward_vlan1 all -- 0.0.0.0/0 0.0.0.0/0

Chain input_rule (1 references)
target prot opt source destination
input_vlan1 all -- 0.0.0.0/0 0.0.0.0/0

Chain input_vlan1 (1 references)
target prot opt source destination
ACCEPT udp -- 0.0.0.0/0 217.128.200.48 multiport dports 500
ACCEPT udp -- 0.0.0.0/0 217.128.200.48 multiport dports 4500
ACCEPT tcp -- 0.0.0.0/0 217.128.200.48

Chain output_rule (1 references)
target prot opt source destination

Une analyse tcpdump sur le trafic entrant sur vlan1 capture bien les
paquets entrant sur le tcp/443, cependant une capture sur br0 ne voit
pas passer de paquets réécrits à destination de 192.168.85.1.

Niveau interfaces, le paramétrage est le suivant :
root@rtrwrtfenint:~# ifconfig -a
br0 Link encap:Ethernet HWaddr 00:0F:66:C8:B9:65
inet addr:192.168.85.15 Bcast:192.168.85.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1482456 errors:0 dropped:0 overruns:0 frame:0
TX packets:1341422 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1194448986 (1.1 GiB) TX bytes:956158749 (911.8 MiB)

eth0 Link encap:Ethernet HWaddr 00:0F:66:C8:B9:65
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:2471018 errors:0 dropped:0 overruns:0 frame:0
TX packets:2367188 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1855202270 (1.7 GiB) TX bytes:1376736709 (1.2 GiB)
Interrupt:5

eth1 Link encap:Ethernet HWaddr 00:0F:66:C8:B9:67
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:2595654 errors:0 dropped:0 overruns:0 frame:119910
TX packets:2712257 errors:6 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1571821486 (1.4 GiB) TX bytes:2094164948 (1.9 GiB)
Interrupt:4 Base address:0x1000

ipsec0 Link encap:Ethernet HWaddr 00:0F:66:C8:B9:66
inet addr:217.128.200.48 Mask:224.0.0.0
UP RUNNING NOARP MTU:16260 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

ipsec1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
NOARP MTU:0 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

ipsec2 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
NOARP MTU:0 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

ipsec3 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
NOARP MTU:0 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

ppp0 Link encap:Point-Point Protocol
inet addr:192.168.85.15 P-t-P:192.168.0.15 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:4706 errors:0 dropped:0 overruns:0 frame:0
TX packets:4844 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:546447 (533.6 KiB) TX bytes:370296 (361.6 KiB)

vlan0 Link encap:Ethernet HWaddr 00:0F:66:C8:B9:65
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:1104652 errors:0 dropped:0 overruns:0 frame:0
TX packets:850905 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:861921028 (821.9 MiB) TX bytes:140421309 (133.9 MiB)

vlan1 Link encap:Ethernet HWaddr 00:0F:66:C8:B9:66
inet addr:217.128.200.48 Bcast:223.255.255.255 Mask:224.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1480 Metric:1
RX packets:1366358 errors:0 dropped:0 overruns:0 frame:0
TX packets:1516022 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:948801724 (904.8 MiB) TX bytes:1225382109 (1.1 GiB)

Sur ce coup, je suis sec, quelqu'un aurait-il une idée lumineuse ?

Merci d'avance.

--
SM> Désolé (c'est quand-même terrible cette société où l'on doit
SM> s'excuser d'être doué, vraiment)
Si en + tu devais t'excuser d'être crétin t'aurais un job a plein temps
-+- RM in http://neuneu.ctw.cc - Là, ya indubitablement consensus -+-
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #6748151
Salut,


Le est gardé par un OpenWRT sur lequel j'ai mis en place une
redirection du tcp/443 vers un serveur interne, cependant, ça ne
fonctionne pas des masses.

iptables me retourne les éléments suivants :

:~# iptables -n -t nat -L


L'ennui avec la sortie d'iptables -L, c'est d'une part qu'elle est
pénible à lire et d'autre part qu'il manque les interfaces d'entrée et
de sortie à moins d'ajouter -v. C'est possible d'avoir la sortie
d'iptables-save à la place ? Tu pourrais aussi ajouter la sortie de
"brctl show" pour voir qu'est-ce qui est ponté avec quoi, la version du
noyau et un petit topo sur ce à quoi correspond chaque interface ?

Eric Masson
Le #6748381
Pascal Hambourg
'Lut,

L'ennui avec la sortie d'iptables -L, c'est d'une part qu'elle est
pénible à lire et d'autre part qu'il manque les interfaces d'entrée et
de sortie à moins d'ajouter -v. C'est possible d'avoir la sortie
d'iptables-save à la place ?


Euh, non, pas dispo sur la machine et pas dispo en package...

Par contre :

:~# iptables -L -v -n
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
6 408 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
35322 4502K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
4 160 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp option=!2 flags:0x02/0x02
1951 206K input_rule all -- * * 0.0.0.0/0 0.0.0.0/0
450 93220 ACCEPT all -- !vlan1 * 0.0.0.0/0 0.0.0.0/0
284 9173 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT 47 -- * * 0.0.0.0/0 0.0.0.0/0
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset
895 85275 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
9979 534K TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
314K 182M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
12345 868K forwarding_rule all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- br0 br0 0.0.0.0/0 0.0.0.0/0
12220 860K ACCEPT all -- br0 vlan1 0.0.0.0/0 0.0.0.0/0
114 7394 ACCEPT all -- br0 ppp0 0.0.0.0/0 0.0.0.0/0
11 704 ACCEPT all -- ppp0 br0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- br0 ppp1 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- ppp1 br0 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
44715 4849K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
297 23517 output_rule all -- * * 0.0.0.0/0 0.0.0.0/0
297 23517 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable

Chain forward_vlan1 (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.85.1 tcp dpt:443

Chain forwarding_rule (1 references)
pkts bytes target prot opt in out source destination
0 0 forward_vlan1 all -- vlan1 * 0.0.0.0/0 0.0.0.0/0

Chain input_rule (1 references)
pkts bytes target prot opt in out source destination
1501 113K input_vlan1 all -- vlan1 * 0.0.0.0/0 0.0.0.0/0

Chain input_vlan1 (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- * * 0.0.0.0/0 217.128.200.48 multiport dports 500
0 0 ACCEPT udp -- * * 0.0.0.0/0 217.128.200.48 multiport dports 4500
322 18825 ACCEPT tcp -- * * 0.0.0.0/0 217.128.200.48

Chain output_rule (1 references)
pkts bytes target prot opt in out source destination


Tu pourrais aussi ajouter la sortie de "brctl show" pour voir
qu'est-ce qui est ponté avec quoi, la version du noyau et un petit
topo sur ce à quoi correspond chaque interface ?


:~# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.000f66c8b965 no vlan0
eth1

Pour les interfaces, c'est un WRT54GS 1.1, donc une seule interface
ethernet (eth0) physique associée à un switch programmable supportant
les vlans :
- vlan1, port du switch connecté à un AM200 configuré en half-bridge,
dhcp
- vlan0, 4 ports restants, bridgé avec le wireless (eth1)

Le kernel est un 2.4.30 mips issu du projet OpenWRT (patchs divers et
variés), le firmware est un White-russian RC5.

La redirection en question a fonctionné jusqu'à il y a un mois et demi,
ce n'est plus le cas depuis que j'ai remonté le lan (déménagement et
changement de FAI).

Ça te va, ou te faut-il d'autres infos ?

Merci.

--
J'ai reçu un mail parlant d'un petit garçon malade. Je l'ai transféré à
tous ceux que je connaissais. On me dit que c'est un attrape couillons.
Est-ce vrai? Suis-je vraiment aussi con que le prétend ma femme?
-+-C in GNU - Le plus dur dans le mariage, c'est d'en sortir vivant -+-

Eric Masson
Le #6748371
Eric Masson
'Re,

Euh, non, pas dispo sur la machine et pas dispo en package...


Euh, Mauvaise recherche, changer recherche !

:/# iptables-save
# Generated by iptables-save v1.3.3 on Sat May 31 22:15:38 2008
*nat
:PREROUTING ACCEPT [18375:1358735]
:POSTROUTING ACCEPT [234:18150]
:OUTPUT ACCEPT [765:69138]
:postrouting_rule - [0:0]
:prerouting_rule - [0:0]
:prerouting_vlan1 - [0:0]
-A PREROUTING -j prerouting_rule
-A POSTROUTING -j postrouting_rule
-A POSTROUTING -o vlan1 -j MASQUERADE
-A prerouting_rule -i vlan1 -j prerouting_vlan1
-A prerouting_vlan1 -d 217.128.200.48 -p udp -m multiport --dports 500 -j ACCEPT
-A prerouting_vlan1 -d 217.128.200.48 -p udp -m multiport --dports 4500 -j ACCEPT
-A prerouting_vlan1 -d 217.128.200.48 -p tcp -j ACCEPT
-A prerouting_vlan1 -d 217.128.200.48 -p tcp -m multiport --dports 443 -j DNAT --to-destination 192.168.85.1:443
COMMIT
# Completed on Sat May 31 22:15:39 2008
# Generated by iptables-save v1.3.3 on Sat May 31 22:15:39 2008
*mangle
:PREROUTING ACCEPT [3210672:2320546653]
:INPUT ACCEPT [69597:8724397]
:FORWARD ACCEPT [3140748:2311659667]
:OUTPUT ACCEPT [87234:10162290]
:POSTROUTING ACCEPT [3228009:2321824486]
COMMIT
# Completed on Sat May 31 22:15:39 2008
# Generated by iptables-save v1.3.3 on Sat May 31 22:15:39 2008
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:forward_vlan1 - [0:0]
:forwarding_rule - [0:0]
:input_rule - [0:0]
:input_vlan1 - [0:0]
:output_rule - [0:0]
-A INPUT -m state --state INVALID -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-option 2 --tcp-flags SYN SYN -j DROP
-A INPUT -j input_rule
-A INPUT -i ! vlan1 -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -p gre -j ACCEPT
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j forwarding_rule
-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -i br0 -o vlan1 -j ACCEPT
-A FORWARD -i br0 -o ppp0 -j ACCEPT
-A FORWARD -i ppp0 -o br0 -j ACCEPT
-A FORWARD -i br0 -o ppp1 -j ACCEPT
-A FORWARD -i ppp1 -o br0 -j ACCEPT
-A OUTPUT -m state --state INVALID -j DROP
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -j output_rule
-A OUTPUT -j ACCEPT
-A OUTPUT -p tcp -j REJECT --reject-with tcp-reset
-A OUTPUT -j REJECT --reject-with icmp-port-unreachable
-A forward_vlan1 -d 192.168.85.1 -p tcp -m tcp --dport 443 -j ACCEPT
-A forwarding_rule -i vlan1 -j forward_vlan1
-A input_rule -i vlan1 -j input_vlan1
-A input_vlan1 -d 217.128.200.48 -p udp -m multiport --dports 500 -j ACCEPT
-A input_vlan1 -d 217.128.200.48 -p udp -m multiport --dports 4500 -j ACCEPT
-A input_vlan1 -d 217.128.200.48 -p tcp -j ACCEPT
COMMIT
# Completed on Sat May 31 22:15:39 2008

--
VDS cd avec + de 12 000 photos de culs en tous genres
c'est mon best of que j'ai glané sur Internet. quel que soit le sujet,
j'ai ! il y a vraiment de tout...
-+- art in
Pascal Hambourg
Le #6748901

# Generated by iptables-save v1.3.3 on Sat May 31 22:15:38 2008
*nat
:PREROUTING ACCEPT [18375:1358735]
:POSTROUTING ACCEPT [234:18150]
:OUTPUT ACCEPT [765:69138]
:postrouting_rule - [0:0]
:prerouting_rule - [0:0]
:prerouting_vlan1 - [0:0]
-A PREROUTING -j prerouting_rule
-A POSTROUTING -j postrouting_rule
-A POSTROUTING -o vlan1 -j MASQUERADE
-A prerouting_rule -i vlan1 -j prerouting_vlan1
-A prerouting_vlan1 -d 217.128.200.48 -p udp -m multiport --dports 500 -j ACCEPT
-A prerouting_vlan1 -d 217.128.200.48 -p udp -m multiport --dports 4500 -j ACCEPT
======================================================= > -A prerouting_vlan1 -d 217.128.200.48 -p tcp -j ACCEPT

======================================================= Cette règle ramasse toutes les connexions TCP et la cible ACCEPT
provoque la sortie de la chaîne, ce qui neutralise la règle de
redirection qui suit. En la supprimant, ça devrait marcher mieux.

-A prerouting_vlan1 -d 217.128.200.48 -p tcp -m multiport --dports 443 -j DNAT --to-destination 192.168.85.1:443


Eric Masson
Le #6750161
Pascal Hambourg
'Lut,

======================================================= >> -A prerouting_vlan1 -d 217.128.200.48 -p tcp -j ACCEPT
======================================================= > Cette règle ramasse toutes les connexions TCP et la cible ACCEPT
provoque la sortie de la chaîne, ce qui neutralise la règle de
redirection qui suit. En la supprimant, ça devrait marcher mieux.

-A prerouting_vlan1 -d 217.128.200.48 -p tcp -m multiport --dports 443 -j DNAT --to-destination 192.168.85.1:443



En supprimant la dite règle, ça fonctionne de suite, par contre une
question, si l'ordre des deux règles était inversé, cela pourrait-il
fonctionner ?

Cela ressemble à un bug de génération de règles, mais vu que la version
que j'utilise n'est plus maintenue, il va falloir que j'envisage un
upgrade vers Kamikaze, ce qui va m'obliger à enfin déballer mon WGT634U
:)

Merci

--
DM> J'arrive seulement sur ce groupe de discussion .Que faut il faire ?
Rien, il n'y a absolument rien d'autres à faire que taper son message en
répondant au groupe, ou pourquoi pas un nouveau message. Rien d'autres
-+- E in Guide du Neuneu Usenet - Mais où ce qu'il est-il donc ? -+-


Pascal Hambourg
Le #6750151

-A prerouting_vlan1 -d 217.128.200.48 -p tcp -j ACCEPT



En supprimant la dite règle, ça fonctionne de suite, par contre une
question, si l'ordre des deux règles était inversé, cela pourrait-il
fonctionner ?


Oui puisque la règle DNAT serait atteinte avant la règle ACCEPT, mais je
ne vois franchement pas du tout à quoi sert cette règle ACCEPT pour TCP
dans la mesure où la politique par défaut normale des chaînes de la
table 'nat' est déjà ACCEPT.



Eric Masson
Le #6750141
Pascal Hambourg
'Re,

Oui puisque la règle DNAT serait atteinte avant la règle ACCEPT, mais je
ne vois franchement pas du tout à quoi sert cette règle ACCEPT pour TCP
dans la mesure où la politique par défaut normale des chaînes de la
table 'nat' est déjà ACCEPT.


C'est plus que probablement un bug dans le script de génération des
règles, il faudrait que je jette un oeil dans le dépôt Subversion
d'OpenWRT histoire de voir si un fix n'a pas été mis en place.

En tous cas, merci pour ton aide, autant pf me cause, autant Netfilter
me semble toujours aussi bizarre...

Éric

--
que fait le webmaster du ng ? ils ne sont que 7 ou 8 à nous manger sur
le dos et dans 5 ans ils seront maxi 3 ....alors payer maintenant en
vous en sortant le mieux possible pour plus tard.........
-+- MH in GNU : Webmasters de tous les newsgroups, unissez-vous -+-

Pascal Hambourg
Le #6750611
Pascal Hambourg
je ne vois franchement pas du tout à quoi sert cette règle ACCEPT pour
TCP dans la mesure où la politique par défaut normale des chaînes de
la table 'nat' est déjà ACCEPT.


C'est plus que probablement un bug dans le script de génération des
règles


J'y pense, sa création est peut-être liée à celle des deux règles
précédentes qui concernent IPSec.

En tous cas, merci pour ton aide, autant pf me cause, autant Netfilter
me semble toujours aussi bizarre...


Moi c'est le contraire. Ils n'ont pas la même logique, probablement. Je
ne sais pas pour pf, mais iptables est un filtre de paquets qui
fonctionne à un niveau très élémentaire, c'est pourquoi les jeux de
règles sont souvent assez touffus.


Eric Masson
Le #6750601
Pascal Hambourg
J'y pense, sa création est peut-être liée à celle des deux règles
précédentes qui concernent IPSec.


Encore plus tordu, c'était lié à un bug de l'interface http du bouzin,
qui faisait que la règle ACCEPT sur le protocole tcp n'apparaissait pas
dans l'interface...

J'ai ajouté au passage une règle pour esp des fois que je monterai des
tunnels ipsec gw à gw un de ces jours (pour le moment le client
l2tp/ipsec utilise esp over udp)

Moi c'est le contraire. Ils n'ont pas la même logique, probablement. Je
ne sais pas pour pf, mais iptables est un filtre de paquets qui
fonctionne à un niveau très élémentaire, c'est pourquoi les jeux de
règles sont souvent assez touffus.


On doit rentrer dans des questions d'habitude ;)

--
Puisque nous n'avons aucun problème traduisant le Suédois au frencece
ne devrait pas être aucun problème pour que vous le fassiezl'autre voie
autour. Sucez sur ceci: www.Hlookslikeshit.xxx.com
-+- H in GNU : Pour qui sont ces suédois qui sucent sur nos sites ? -+-

Publicité
Poster une réponse
Anonyme