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.
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)
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 -+-
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 Hambourg
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 ?
Salut,
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
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 ?
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
Pascal Hambourg writes:
'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 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 -+-
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 :
root@rtrwrtfenint:~# 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 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 ?
root@rtrwrtfenint:~# 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 -+-
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 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
Eric Masson writes:
'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 <http://www.le-gnu.net> - Tu le sens mon gros neuneu -+-
Eric Masson <emss@free.fr> writes:
'Re,
Euh, non, pas dispo sur la machine et pas dispo en package...
Euh, Mauvaise recherche, changer recherche !
root@rtrwrtfenint:/# 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 <http://www.le-gnu.net> - Tu le sens mon gros neuneu -+-
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 <http://www.le-gnu.net> - Tu le sens mon gros neuneu -+-
Pascal Hambourg
# 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.
# 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.
# 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 -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.
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 ? -+-
======================================================= >> -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.
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 ? -+-
======================================================= >> -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.
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
-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.
-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.
-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
Pascal Hambourg writes:
'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 -+-
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 -+-
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
Pascal Hambourg writes:
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.
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.
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
Pascal Hambourg writes:
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 ? -+-
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 ? -+-
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 ? -+-
