OpenVPN nem bírja az iramot, update, TCP Window Scaling probléma

Hálózati eszközök

Van egy régi Debian alapú átjáró/tűzfal, amire csatlakoznak kliensek és egy másik telephely, általában OpenVPN 2.0.x-en. Készítenék egy új átjárót a telephelyre, amit vezeték nélküli kapcsolaton érnénk el, és olyan 100 MBitet bír a vonal, később az eszközök cseréjével talán többet is.

Lényeg:
Közvetlenül egy vagy két switchen keresztül összekötve a két átjárót, ha másolok egy kb 5 megánál nagyobb állományt egy NAS-ról a VPN-en át a másik átjáróra kötött laptopra, minden más forgalom meghal, RDP kifagy, icmp echo-k elvesznek és a másolás is meg megakad és újraindul.
Azt vettem még észre, hogy ilyenkor a régi átjárón a többi kapcsolat is szakadozik (VPN internet, minden ami az adott hálókártyától függ)
Ha az új szerveren csökkentem a hálókártya sebességét 100-ról 10 mbit-re, vagy csak 100 mbit full duplexre állítom a hálókártyát, akkor stabilizálódik a helyzet, a másolás egyenletes lesz, rdp nem szakad, icmp kiesése ritkul.
Próbáltam még fragment méretet állítani, fast-io-t ki-be kapcsolni, titkosítást és tömörítést kikapcsolni próbaképp. Csak a hálókártya visszafogása segített. Realtek alapú gigabites PCI-Express kártya, TP-link ugyan de a firmware és a meghajtó úgy is a kernel része, úgyhogy elvileg mindegy. Próbáltam a legutolsó stabil Debiannal és 14.04-es Ubuntuval, ugyanaz a helyzet.
Mi lehet a megoldás, valaki látott-e ilyet? Hogy lehetne csak az OpenVPN-t visszafogni, a hálókártyát meg nem? Vagy lehet nem is ez az oldal a rosz hanem a régi központi átjáró és annak öregecske hálókártyája? Ha azt fogom vissza, az kevésbé hatásos.

Frissítés:

Közben meglett a ludas egy Draytek router beépített switchének képében.
Viszont előjött egy új gond.

Vista esetén csak akkor működik jól a hálózat, ha kikapcsolom a tcp window scaling-ot a Vista-s gépen.

Mit kellene a Debian alapú átjárón, amin a VPN is fut állítani, hogy akkor is jól működjön, ha nincs kikapcsolva a tcp window scaling?

Hiba: szakad mindenféle egyéb kapcsolat, netrádió, ping, ha a VPN-en túlról másolok nagy állományokat SMB protokollal. Annyival jobb a helyzet, mint az előző hibánál, hogy a VPN kapcsolat stabil, a késleltetések alacsonyak a két átjáró között.

Így néz ki valahogy az adatút:
NAS---GW1----(VPN TUN, UDP)-----GW2---Vistás laptop
Ha jól olvastam, a TCP window scaling akkor müxik rosszul, ha valamelyik átjáró rosszul ír át adatokat a tcp csomagok továbbításánál. Itt ugye két Debian alapú átjáró jöhet szóba. Mindkettőn be van kapcsolva a tcp window scaling, ha jól láttam a proc könyvtár mélyén. az iptables szabályok meg nincsennek agyon bonyolítva, szimpla forward. A VPN konfig pedig tartalmazza a "fragment 1300" és "mssfix" sorokat.

  • 4852 megtekintés

( andrej_ v | 2014. 09. 18., cs – 19:06 )

Egy konfig nem artana az erzekeny reszeket kitakarva.

( ncc1701 | 2014. 09. 18., cs – 19:24 )

Ilyet mondjuk konkrétan nem láttam. Ilyenkor CPU terhelés?

TUN mód UDP protokollal Mindtkét gép 2 magos Core 2 architektúrájú processzorral és g31-es lappal, nem tipikusan szervercumó, de ebből van dögivel :) az egyik processzora 2,2 a másiké 2.4 GHz.
Szerver oldali konfig:
daemon ***
dev tun
proto udp
lport ****
float
comp-lzo
ifconfig **** ****
route ***
secret /etc/openvpn/*****
keepalive 10 50
persist-tun
persist-key
user nobody
group nogroup
passtos
#sndbuf 524288
#rcvbuf 524288
#txqueuelen 200
#verb 3

Kikommentelve amiket még próbálgattam.
A szerveren néztem a cpu terhelést és 30% felé nem ment, de nem nagyon nézegettem. Pláne mivel a kikapcsolt titkosítás se segített, cipher és auth none.

Innentől csak hülye ötleteim vannak. Próbált tcp-n, illetve a comp-lzo-t vedd ki, hátha. De a procinak bőven vinnie kéne, bár az ovpn csak 1 magot használ. Ettől független nálam microserveren van olyan eset, h egyszerre kezel 15-20 vpn kapcsolatot, bár azt a net felé, ott meg kissebb a sávkeskenység.

TCP-t holnap fogom, amúgy a szerver itt is bír egy telephelyet meg pár maszek usert, és lehet működne is az új helyén WLAN-on keresztül ez a z új átjáró, mint ahogy most is bírja egy másik gép (abban egy 3 GHz-s P4 van Debilánnyal), de azért rossz ómen, hogy így direktbe kötve ennyire nem működik, csak ha a hálókártyát butítom.

( Mcsiv v | 2014. 09. 18., cs – 19:59 )

"100 mbit full duplex" -> ez a normalis allapot, nem a half duplex

// Happy debugging, suckers
#define true (rand() > 10)

Ok, hát az nem fog menni, max garanciális csere. Abból kell főzni, ami van.
PCI-os és PCI-Expresses kártyával is csinálja. Érdemes kikapcsolni az összes offload-ot amit tud a kártya?
Valamint azt sem értem hogy az új átjáró hogy tudja a régit megakasztani? Nincs valami ismertebb inkompatibilitás a különféle 2.0x-es OpenVPN-ek között? És arra valami workaround? A shaper opción kívűl mivel lehet még az OpenVPN-t visszafogni? A shaper nekem sehogy nem működött.

( bennyh | 2014. 09. 19., p – 09:07 )

Uraim, megvan a bűnös (legalább is úgy néz ki, de még tesztelek). Itt szídtátok ezeket a drága kis realtekeket :D
Szóval. Az a lényeg, hogy a két gép egy Draytek Vigyor 29 akárhányon volt összekötve, aminek van gigabites switch része, amiről kiderült most, hogy a lónak egy jó hosszú anatómiai tartozéka ezek szerint. Ha ehelyett fogok egy szintén sokat szidott TP-link nem managelhető 4000 Ft bekerülési értékű cumót és azon át madzagolom össze a két átjárót (+ rákötöttem a drayteket, mert mások mégis csak neteznének :D) akkor olyan szépen másol, mint az ólom, akarom mondani álom :D és nem hal le semmi.

( ubul_ | 2014. 09. 19., p – 09:31 )

iperf-el milyen a hálózati teljesítmény a két végpont között?
SSH-val létrehozott ad-hoc vpn is lassú?