Linux

Utilitzeu la taula en brut d’iptables per resoldre ip_conntrack: taula plena, caient el problema dels paquets

Use Iptables Raw Table Solve Ip_conntrack



1) Què és una taula crua? Per a què serveix això?

iptables té 5 cadenes: PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING, 4 taules: filtre, nat, mangle, raw.

L'ordre de prioritat de les quatre taules és de més alt a més baix: raw -> mangle -> nat -> filter

Per exemple: si hi ha una taula mangle a la cadena PRROUTING, també hi ha una taula nat, llavors la processa mangle i la processa la taula nat.

La taula RAW només s’utilitza a la cadena PREROUTING i a la cadena OUTPUT a causa de la màxima prioritat, de manera que els paquets rebuts es poden processar abans de fer un seguiment de la connexió. Un cop l'usuari utilitza la taula RAW, en cadena, després de processar la taula RAW, s'ometrà la taula NAT i el processament ip_conntrack, és a dir, la traducció d'adreces i el processament de seguiment de paquets del paquet de dades ja no es realitzaran.

Les taules RAW es poden utilitzar per millorar el rendiment sense necessitat de fer nat. Per exemple, es pot accedir a un gran nombre de servidors web, de manera que el port 80 ja no pot permetre que iptables faci processament de paquets de seguiment d’enllaços per millorar la velocitat d’accés dels usuaris.

2) Quin és el flux del paquet iptables?

(Font d'introducció del procés: http://selboo.com.cn/post/721/)
Com passar per cada cadena i taula al seu torn quan arriba un paquet (Figura).



Els passos bàsics són els següents:
1. El paquet arriba a la interfície de xarxa, com ara eth0.
2. Introduïu la cadena PREROUTING de la taula en brut. El propòsit d’aquesta cadena és processar el paquet abans de fer un seguiment de la connexió.
3. Si es fa el seguiment de la connexió, es gestiona aquí.
4. Aneu a la cadena PREROUTING de la taula mangle, on podeu modificar el paquet de dades, com ara TOS.
5. Introduïu la cadena PREROUTING de la taula nat, podeu fer DNAT aquí, però no filtrar.
6. Determineu la ruta per veure si es lliura a l'amfitrió local o es reenvia a altres amfitrions.

Aquí discutim dues situacions diferents, un cas és que el paquet s’envia a altres hosts i passarà en seqüència:
7. Introduïu la cadena FORWARD de la taula mangle, que també és especial aquí. Després de la primera decisió d’encaminament, encara podem realitzar algunes dades al paquet abans de prendre la decisió d’encaminament final. Algunes modificacions.
8. Aneu a la cadena FORWARD de la taula de filtres, on podem filtrar tots els paquets reenviats. Cal tenir en compte que els paquets que passen per aquí es reenvien i la direcció és bidireccional.
9. Aneu a la cadena POSTROUTING de la taula mangle, on s’han pres totes les decisions d’encaminament, però els paquets continuen a l’amfitrió local i podem fer algunes modificacions.
10. Introduïu la cadena POSTROUTING de la taula nat, que s'utilitza generalment per fer SNAT aquí. No filtreu aquí.
11. Introduïu la interfície de xarxa de sortida. Acabat.

En un altre cas, el paquet s’envia a l’amfitrió local i després passarà per:
7. Introduïu la cadena INPUT de la taula mangle, aquí després de la ruta, abans de l'amfitrió local, també podem fer algunes modificacions corresponents.
8. Aneu a la cadena INPUT de la taula de filtres, on podem filtrar tots els paquets entrants, independentment de la interfície de xarxa que provingui.
9. Gestioneu l'aplicació a l'amfitrió local perquè es processi.
10. Després de processar-lo, prengui una decisió d’encaminament i vegi on s’enviarà.
11. Introduïu la cadena OUTPUT de la taula en brut, que és abans del procés de seguiment de connexions dels paquets locals.
12. El seguiment de la connexió gestiona els paquets locals.
13. Aneu a la cadena OUTPUT de la taula mangle, on podem modificar el paquet, però no filtrar-lo.
14. Introduïu la cadena OUTPUT de la taula nat a NAT les dades enviades pel propi tallafoc.
15. Torneu a prendre decisions d’encaminament.
16. Introduïu la cadena OUTPUT de la taula de filtres per filtrar els paquets sortints.
17. Aneu a la cadena POSTROUTING de la taula mangle, com al pas 9 del cas anterior. Tingueu en compte que aquí no només es processen els paquets que passen pel tallafoc, sinó que també es processen els paquets generats pel tallafoc.
18. Aneu a la cadena POSTROUTING de la taula nat, com al pas 10 del cas anterior.
19. Introduïu la interfície de xarxa de sortida. Acabat.


3) Ús de la taula en brut d’iptables

Afegiu una taula en brut, -j NOTRACK salta un altre processament de taula abans que es processin altres taules
L’estat afegeix un UNTRACKED a més dels quatre anteriors.

Per exemple:
pot utilitzar l'objectiu 'NOTRACK' per permetre a les regles especificar que els paquets del port 80 no entren al subsistema de seguiment d'enllaços / NAT

iptables -t raw -A PREROUTING -d 1.2.3.4 -p tcp --dport 80 -j NOTRACK
iptables -t raw -A PREROUTING -s 1.2.3.4 -p tcp --sport 80 -j NOTRACK
iptables -A FORWARD -m state --state UNTRACKED -j ACCEPT

4) Resoleu el problema d’ip_conntrack: taula plena, caient el paquet


Al servidor web iptables habilitat, sovint es produeix el següent error quan el trànsit és elevat:

ip_conntrack: taula completa, caient el paquet


La raó d’aquest problema és que, com que el servidor web rep moltes connexions, iptables farà tots els enllaços per al seguiment d’enllaços quan s’activa iptables, de manera que iptables tindrà una taula de seguiment d’enllaços, quan la taula estigui plena, es produirà l’error anterior apareixen.

La capacitat màxima de la taula de seguiment d’enllaços d’iptables és / proc / sys / net / ipv4 / ip_conntrack_max i l’enllaç se suprimirà de la taula després d’un temps d’espera de diversos estats.

Per tant, hi ha dues solucions:

(1) Augmenteu el valor ip_conntrack_max

vi /etc/sysctl.conf

net.ipv4.ip_conntrack_max = 393216
net.ipv4.netfilter.ip_conntrack_max = 393216


(2): reduïu el temps d'espera de ip_conntrack

vi /etc/sysctl.conf

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 300
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120


Els dos mètodes anteriors són anàlegs. Quan l'aigua bulli, canvieu a una olla gran. En circumstàncies normals, el problema es pot resoldre, però en casos extrems encara no n’hi ha prou. Que hauria de fer?

D’aquesta manera s’ha d’anar cap a l’altre camí, mitjançant el mètode de baix a dalt. La taula en brut d’iptables no s’utilitza per al seguiment d’enllaços de paquets. Afegirem enllaços amb connexions molt grans a la taula en brut d’iptables.

Com a servidor web, pot fer això:

iptables -t raw -A PREROUTING -d 1.2.3.4 -p tcp --dport 80 -j NOTRACK
iptables -A FORWARD -m state --state UNTRACKED -j ACCEPT


5) prova d'efecte de taula en brut d'ipables

Fem una prova en un servidor web; primer no utilitzeu la taula en brut, observeu la mida de la taula de seguiment d’enllaços (/ proc / net / ip_conntrack):

Primer cop d’ull a la configuració d’iptables:
cat / etc / sysconfig / iptables

# Generat per iptables-save v1.3.5 el dimarts 18 d'agost a les 10:10:52 de 2010
* filtre
: INPUT ACCEPT [0: 0]
: ACCEPTACIÓ PER endavant [0: 0]
: ACCEPTACIÓ DE SORTIDA [104076: 12500201]
: RH-Firewall-1-INPUT - [0: 0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p esp -j ACCEPT
-A RH-Firewall-1-INPUT -p ah -j ACCEPTEU
-A RH-Firewall-1-INPUT -d 224.0.0.251 -p udp -m udp --dport 5353 -j ACCEPTAR
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state RELATED, ESTABLISHED -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-forbidden
COMPROMETRE’s
# Completat el dimarts 18 d'agost a les 10:10:52 de 2010

Prova amb ab en una altra màquina:

ab -c 1000 -n 5000 http://192.168.20.26/index.html

Vegeu la mida de la taula de seguiment d'enllaços (/ proc / net / ip_conntrack) al servidor web:

[root @ xxxxx html] # wc -l / proc / net / ip_conntrack
5153 / proc / net / ip_conntrack

Podeu veure que hi ha 5153 enllaços a la taula de seguiment. La pressió de la més gran es pot informar com a ip_conntrack: taula plena, error de paquet de caiguda.


A continuació, activem la taula en brut:

Actualitzeu primer iptables:

[root @ xxxxx html] # cat / etc / sysconfig / iptables
# Generat per iptables-save v1.3.5 el dimarts 18 d'agost a les 10:10:52 de 2010
* filtre
: INPUT ACCEPT [0: 0]
: ACCEPTACIÓ ENDAVANT [0: 0]
: ACCEPTACIÓ DE SORTIDA [104076: 12500201]
: RH-Firewall-1-INPUT - [0: 0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p esp -j ACCEPT
-A RH-Firewall-1-INPUT -p ah -j ACCEPTEU
-A RH-Firewall-1-INPUT -d 224.0.0.251 -p udp -m udp --dport 5353 -j ACCEPTAR
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state RELATED, ESTABLISHED, UNTRACKED -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-forbidden
COMPROMETRE’s
# Completat el dimarts 18 d'agost a les 10:10:52 de 2010
# Generat per iptables-save v1.3.5 el dimarts 18 d'agost a les 10:10:52 de 2010
* cru
: PREROUTING ACCEPT [116163: 9327716]
: ACCEPTACIÓ DE SORTIDA [104076: 12500201]
-A PREROUTING -p tcp -m tcp --dport 80 -j NOTRACK
-A OUTPUT -p tcp -m tcp --sport 80 -j NOTRACK
COMPROMETRE’s
# Completat el dimarts 18 d'agost a les 10:10:52 de 2010

La part vermella és nova.

Reinicieu iptables:

servei iptables es reinicia

Podeu utilitzar l'ordre iptables per veure si està habilitat correctament:

[root @ xxxxx html] # iptables -t raw -L -n
PREROUTING en cadena (política ACCEPTA)
destinació de la font prot opt ​​de destinació
NOTRACK tcp - 0.0.0.0/0 0.0.0.0/0 tcp dpt: 80

Cadena OUTPUT (política ACCEPTA)
destinació de la font prot opt ​​de destinació
NOTRACK tcp - 0.0.0.0/0 0.0.0.0/0 tcp spt: 80

A continuació, proveu amb ab:

ab -c 1000 -n 5000 http://192.168.20.26/index.html

Veure la mida de la taula de seguiment d'enllaços (/ proc / net / ip_conntrack):

[root @ xxxxx html] # wc -l / proc / net / ip_conntrack
1 / proc / net / ip_conntrack

Només es va fer un seguiment d’un enllaç a la taula de seguiment.

[root @ xxxxx html] # cat / proc / net / ip_conntrack
tcp 6 431999 ESTABLISHED src = 192.168.20.26 dst = 192.168.20.10 esport = 22 dport = 50088 paquets = 85 bytes = 10200 src = 192.168.20.10 dst = 192.168.20.26 esport = 50088 dport = 22 paquets = 92 bytes = 6832 [ASSEGURAT ] marca = 0 segell = 0 ús = 1

Es pot veure que iptables no ha rastrejat l’enllaç amb el port 80 d’entrada i sortida. Els resultats de la prova mostren que la taula raw d’iptables pot resoldre perfectament el problema d’ip_conntrack: taula plena, caient paquet.