Problema viteza scazuta NAT

Merge la fel de bine si cu regulile puse de ogo, cu mentiunea ca la prerouting nu te lasa sa folosesti parametrul -o .

root@debian:~# cat /etc/iptables.up.rules
# Generated by iptables-save v1.8.7 on Sat Aug 13 12:40:47 2022
*mangle
:PREROUTING ACCEPT [4157:638573]
:INPUT ACCEPT [230:43568]
:FORWARD ACCEPT [3926:593362]
:OUTPUT ACCEPT [116:16712]
:POSTROUTING ACCEPT [4042:610074]
-A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1452
-A POSTROUTING -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1452
COMMIT
# Completed on Sat Aug 13 12:40:47 2022
# Generated by iptables-save v1.8.7 on Sat Aug 13 12:40:47 2022
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [3926:593362]
:OUTPUT ACCEPT [116:16712]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -p tcp -m tcp --tcp-flags SYN SYN,RST -j ACCEPT
COMMIT
# Completed on Sat Aug 13 12:40:47 2022
# Generated by iptables-save v1.8.7 on Sat Aug 13 12:40:47 2022
*nat
:PREROUTING ACCEPT [316:58150]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [1:120]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o ppp0 -j MASQUERADE
COMMIT
# Completed on Sat Aug 13 12:40:47 2022

Edited by marchand, 13 August 2022 - 11:45.

Sunt mai multe tabele care contin chain-ul FORWARD, asa cum vezi si tu.  
Poate se numesc la fel chain-urile dar tabelele au fiecare rolul lor iar dupa cum vezi, in iptables, prima tabela interogata e mangle iar primul chain “interogat” e prerouting.

Edited by ogo, 13 August 2022 - 11:53.

Sa o luam cu pasi marunti....

Pana acum am reusit sa duc mtu la ppoe la 1500, deci RFC RFC4638 este suportat!
De precizat ca pe server(gateway) nu am si nu am avut nici o problema cu transferul, chiar si cu mtu 1492 sau  alte valori care ereau puse automat in trecut .

Din experimente am observat ca la clienti viteza este mereu mica la latente de depases 20,30 ms cu serverele testate(>~100km) iar intre 5ms si 20 ms aleator am fie viteaza mare,fie viteaza mica.
Sub 5ms testul incepe si atunci cu viteza mica dar creste rapid la viteza mare.
Acest fenomen nu il inteleg, si ma intreb daca chiuar are legatura cu setarile de MTU.

Atentie, pe lan eu am MTU 4088(jumbo packet pentru a sustine viteaza de 10gbps) dar am incercat si cu 1500 si a fost acelasi situatie.

O sa incerc si niste teste hardware(sa elimin temporar serverul din bucla inlocuind cu un rooter wifi) si lasand switch-ul 10gbit si acces point-ul wifi sa vad ce se intampla...

Incerc si variantele de reguli expuse mai devreme si revin...

Va multumesc mult pentru ajutor!

Edited by CPX, 13 August 2022 - 12:09.

Ai pus tu mtu1500 pe pppoe dar ai verificat sa si mearga?
Ce output ai la
ping -M do -s 1472 1.1.1.1 -c 3
?

ogo, on 13 august 2022 - 12:50, said:

Da, am verificat, cred ca e ok

$ ping -M do -s 1472 1.1.1.1 -c 3
PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
1480 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=13.8 ms
1480 bytes from 1.1.1.1: icmp_seq=2 ttl=60 time=13.1 ms
1480 bytes from 1.1.1.1: icmp_seq=3 ttl=60 time=12.8 ms

Edited by CPX, 13 August 2022 - 13:02.

Da, e bine.

PS
Sa stergi regula de clampling, nu mai e nevoie de ea.

Am testat toate scripturile de aici plus inca unul simplu din internet, am scos regula de clamping si din pacate problema se mentine...

Desemena am elimiat ca vina restul retelei legand un rooter exact in locul server-ului.
Acesta a functionat la viteze foarte mari indiferent de MTU setat(am incercat 1400,1480,1492).

Ma gandesc la o setare de driver sau la o problema a placii de retea gateway, un Mellanox ConnectX-3 EN MCX311(care are ultimul firmware instalat)

Deocamdata nu mai a idei....

Edited by CPX, 13 August 2022 - 22:27.

Eu cred ca nu ai inteles.
Daca ai pus mtu 1500 pe interfata ppp0 trebuie sa stergi regula de mss clamping din iptables.

marchand, on 13 august 2022 - 11:43, said:

corect.
trebuie

-i 

- pt ca ppp0 este input network interface name
respectiv

-o

pt output network interface name

deci regulile ar fi:

sudo iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,RST SYN -i ppp0 -j TCPMSS --set-mss 1452

si

sudo iptables -t mangle -A POSTROUTING-p tcp --tcp-flags SYN,RST SYN -o ppp0 -j TCPMSS --set-mss 1452

Conform packet flow-ului eu cred ca este suficient sa faci modificarea doar in postrouting . Nu cred ca este nevoie sa modifici si  in prerouting .

Si pachetele ce iti vin in WAN  cu DF set, si nu au fost initiate din LAN, nu mai ajung (nu toata lumea face/are nevoie de NAT de ex). Pt ca mss sa fie functional primul pachet SYN trebuie sa fie modificat.
Totodata, fiind regula si in PRE face clamp si la pachetele ce vin din WAN si sunt destinate exclusiv gateway-ului: ssh/http(s):
multi vor sa poata accesa gateway-ul si din WAN, direct (fara vpn de ex)
Iarasi, comunicarea nu e exclusiva pe directia LAN->(POST)WAN.

ogo, on 14 august 2022 - 09:28, said:

Stersem regula de clamping

Oricum am gasit problema , si nu are legatura nici cu mss, nici cu MTU si nici cu NAT!

Ar fi functionat bine cu toate variantele, asta nu insemna ca cele prezentate aici nu sunt mai optime si vom continua discutia pe seama lor mai ales ca am si alte probleme si as vrea sa vedem daca fac bine setarile...

Chestiunea erea de la powersave!!!!!
Am observat ca daca initiez alt transfer prin samba paralel cu testul sau daca incarc procesorul cu stress test viteza tinde sa creasca simtitor...

Folosind powertop am facut diferite setari si unele optiuni dezactivate rezolva problema. Acum nu stiu daca este un bug hardware/software sau altceva..

Dupa ce finalizez cu powertop o sa revin cu intrebari si sa vedem varianta finala in iptables si  daca fac ok setarile pt ipv6.

Multumesc inca o data pentru raspunsuri!

ogo, on 14 august 2022 - 15:48, said:

Din punctul meu de vedere nu are sens sa alterezi pachetele adresate router-ului si initiate de catre router , nu faci decat sa "strici" ICMP-ul si nu vad de ce ai face asta .
In plus la pachetele primite , prerouting-ul este inainte de filter si alterezi si pachetele adresate catre tine dar pe care le blochezi din firewall , incarci procesorul inutil .

ICMP-ul n-are treaba cu mss-ul, el e doar un header al pachetului iar mss-ul este layer 4 si se aplica doar payload-ului pachetelor (tcp) si ATAT.
Icmp-ul e cu totul si cu totul alt protocol si nu e alterat in niciun fel de mss.

Poate intelegi asa:

ping -s 1472 1.1.1.1

unde -s 1472 = e marimea payload-ul propriu-zis la care se adauga 2 headere: 8 bytes de la icmp si 20 de la ip header si rezulta  1500 bytes MTU.

ICMP are treaba cu mss

For IPv4 packets, Path MTU Discovery works by setting the Don't Fragment (DF) flag bit in the IP headers of outgoing packets. Then, any device along the path whose MTU is smaller than the packet will drop it, and send back an Internet Control Message Protocol (ICMP) Fragmentation Needed (Type 3, Code 4) message containing its MTU, allowing the source host to reduce its Path MTU appropriately. The process is repeated until the MTU is small enough to traverse the entire path without fragmentation

Eu cred ca nu intelegi.
Una este MTU si alta e MSS.
MTU se aplica intregului pachet iar MSS doar payload-ului acestuia.

Eu cred ca tu nu intelegi ce este mtu

MTU = MSS + TCP / IP headers