OpenVPN szelektív comp-lzo

Linux-haladó

Sziasztok

Adott egy OpenVPN szerver, rajta sok külső kliens.
Szerver configban: comp-lzo
A sok kiadott kliens configban: comp-lzo

Most egy MikroTik-et is rá kellene kötni, de mint tudjuk, a comp-lzo ott nem támogatott.
Szerver logban: Bad LZO decompression header byte: XX

Próbáltam a ccd mappában létrehozott $user fájllal lebeszélni róla, de egyelőre hasztalan.
Google alapján próbáltam:
comp-lzo no
push "comp-lzo no"
use-compression=no

Emmellett mindvégig a szerver.confban bekapcsolva hagytam a comp-lzo -t, mert a többi kliens miatt kell.

Hogy lehet erre az egy userre tíltani a comp-lzo -t?

Köszönöm!

  • 4340 megtekintés

Köszi, hogy uánanéztél. Igen, erre én is rátaláltam. Fel is frissítettem a legújabb verzióra, hátha...
A ccd jól múködött, külön IP-t kapott, de a kikapcsolt comp-lzo opcióval nem foglalkozott az új OpenVPN verzió sem.
Kliens oldalon gondolom a MikroTik nem tud mit kezdeni ezzel, szerver oldalon viszont igazán kikapcsolhatta volna. Nem tette.

Mivel sürgetett a határidő, szereztem egy plusz IP-t és arra felhúztam egy új OpenVPN szervert comp-lzo nélkül.
A plusz port is járható lett volna, de 443 kellett és az már foglalt volt.

Azért ha idővel lesz megoldás, érdekelne, mert sűrűn belefutok, hogy egy VPN koncentrátorba MikroTik kliensek is becsatlakoznának.
Eddig, ahol tudtam, jobb híján felhúztam egy MikroTik specifikus OpenVPN szervert eltolt porttal.

Jobb volna egy univerzális megoldás.

( uid_6201 v | 2016. 04. 26., k – 21:46 )

comp-lzo érdekes mellékhatásai: Linux OpenVPN mindkét oldalon, TAP-ként (ethernetet vigyen át)

Szerver konfigban nincs comp-lzo
Kliens konfigban van comp-lzo

tcpdump a szerveroldalon meglepő MAC címeket jelenít meg és meglepő ethernet protokollokat.
Sajnos úgy néz ki, nem jelzik egymásnak, hogy comp-lzo -s vagy tömörítetlen csomagot küldenek.

Szia!

Itt lesz a megoldás: "comp-lzo # Compression - must be turned on at both end"

Mindkét oldalon vagy be vagy ki, különben nem fognak egy nyelvet beszélni. Szerintem csinálj annak az egy kliensnek még egy szerver "instance"-t, mondjuk 1194 mellé csinálj egy 1195-ös szerver conf-ot és az az egy user ott jöjjön be. Nagy meló egy kapcsolatért, de ha muszáj, akkor muszáj.

( pista_ v | 2016. 04. 26., k – 22:08 )

Esetleg csinálni egy külön VLAN-t és annak már lehet külön szerverkonfigja, ahogy csak szeretnéd.

Gyanítom külön portra tenni ugyanabba a hálózati tartományba nem fogja engedni, de elég élénk a fantáziám ahhoz, hogy tennék rá egy kísérletet.. ;-)

( wpeople v | 2016. 04. 27., sze – 10:49 )

Mikrotik-OpenVPN sem UDP-t, sem tömörítést nem támogat.
Win/Linux pedig jobban meg UDP-vel és tömörítéssel.

Én a szerverből két instance-t futtatnék, egyet UDP-re (tömörítéssel), egyet TCP-re (tömörítés nélkül) bind-elnék.

( xclusiv v | 2016. 04. 27., sze – 14:12 )

Elvileg az lenne a megoldás, hogy server oldalon comp-lzo adaptive (bár ez a default), klienseken pedig comp-lzo no. És akkor kliensenként lehet szabályozni ccd-ből.

Kipróbálnom még nem kellett, csak olvasgattam róla...

Öööö... de...
Jó hogy kiszúrtad, hülyeséggé formáltam a korábbi olvasmányélményeimet.
A man ezt írja:

--comp-lzo [mode]
Use fast LZO compression -- may add up to 1 byte per packet for
incompressible data. mode may be "yes", "no", or "adaptive"
(default).

In a server mode setup, it is possible to selectively turn com‐
pression on or off for individual clients.

First, make sure the client-side config file enables selective
compression by having at least one --comp-lzo directive, such as
--comp-lzo no. This will turn off compression by default, but
allow a future directive push from the server to dynamically
change the on/off/adaptive setting.

Next in a --client-config-dir file, specify the compression set‐
ting for the client, for example:

comp-lzo yes
push "comp-lzo yes"

The first line sets the comp-lzo setting for the server side of
the link, the second sets the client side.

Szóval az adaptive-nak nem sok köze van a dologhoz, kliens oldalon legyen valami amit aztán CCD-ből felül lehet csapni.

Lehet, nemtom. Letesztelni most nem fogom, de ha valaki mégis akkor érdekel az eredmény.

Szerk.: olvasgattam kicsit, ha jól értem ez alapján a baromi régen tologatott ticket alapján kliens oldalon van a probléma, mert ez a default: "The old behaviour ('comp-lzo' not pushable) is achievable when doing '--comp-lzo disabled' in the client configs."
Ha ez így van, akkor ezt a default behavior-t kellene "comp-lzo no"-ra áttenni, és problem solved.
Aztán 5 éve nem csinálják meg, pedig patch-et is küldött be valaki...

( Zs | 2016. 04. 27., sze – 17:10 )

A comp-lzo paraméter kliens oldalon megadható - azt ccd alapokon felülírni tudtommal nem lehet. (Azért a nagyesküt nem teszem le rá!) A dolgot ráadásul kicsit olyannak érzem, mintha az egyik kliens RSA128-cal jönne be, mert csak ezt tudja, a többi meg RSA256-tal, mert valamikor az lett beállítva és ezért mindenhol máshol az van. Ez sem igazán bírálható felül konfigból. Két lehetőséget látok:
- a fentebb is említett adaptíve opciót szerver oldalon. Ez ideális esetben észleli, hogy a kliens nem tömörít, ezért a szerver oldal se fog tömöríteni afelé a kliens felé, egyébként meg a többi felé igen. De erre mondom, hogy a puding próbája az evés.
- külön fogadó a "renitens" kliensnek.

A doksi szerint lehet.
Viszont elgondolkodtam ezen az comp-lzo=adaptive beállításon, és lehet hogy nem is írtam elsőre hülyeséget.

Mert van a "--comp-noadapt" opció, amire ezt írja a dokument:

When used in conjunction with --comp-lzo, this option will disable OpenVPN's adaptive compression algorithm. Normally, adaptive compression is enabled with --comp-lzo.

Adaptive compression tries to optimize the case where you have compression enabled, but you are sending predominantly uncompressible (or pre-compressed) packets over the tunnel ... With adaptive compression, OpenVPN will periodically sample the compression process to measure its efficiency. If the data being sent over the tunnel is already compressed, the compression efficiency will be very low, triggering openvpn to disable compression for a period of time until the next re-sample test.

Ezek szerint az lzo compression alapban adaptive, szóval sok értelme nem lenne külön "comp-lzo adaptive" és "comp-lzo yes" beállításnak, illetve ha pl. valamilyen (pl. kompatibilitási) okból mégis ugyanazt jelentené, akkor csak odaírnák már a doksiba.

Bár tudja a fene, itt sincs kifejtve, hogy mi a fenét is jelent pontosan ez az adaptive...