OpenVPN 2.6.x z některých sítí nefunguje správně

[kutildomaci]

Bohužel pro mě není úplně snadné to lépe diagnostikovat, protože sám nemám k dispozici připojení, které je problematické, ze všech svých lokalit se připojím bez problémů.

1/ týká se to více serverů s OpenVPN, vybraným příkladem nechť je server na němž běží OpenVPN 2.6.14 (64bit Gentoo, ale totéž se projevuje proti OpenVPN 2.6.3 na aktuálním Debian 12.11)
2/ problém se projevuje delší dobu, není to záležitost posledního týdne, ale spíš tak od té doby, co existuje verze OpenVPN 2.6.x
3/ fórum na OpenVPN.net nefunguje (extrémně pomalé, občas SQL chyby - https://forums.openvpn.net), zkusil bych prudit tam, ostatně někdo už se ptal a bez odpovědi, jen to kvůli nefunkčnosti teď nemohu najít
4/ problém se týká klientů s W10, W11, MAC (TunnelBlick), jakmile je na klientovi OpenVPN 2.6.x a zkouší se připojit skrz "správného" providera
5/ ve všech případech bez problémů pingnu skrz, není to tím, že by OpenVPN 2.6.x nenavázala spojení
6/ zkoušel jsem se dívat, co přesně Samba dělá a na čem skončí... není mi to zcela jasné, určitě se uživatel autentikuje, někdy se i zobrazí první složka prvního prokliknutého sharu a tím to obvykle skončí, skoro nikdy nelze provést víc, jen vzácně třeba prokliknout do podsložky, v logu se mi zdálo, že komunikace prostě v nějaký okamžik přestane probíhat bez zjevné chyby
7/ přeinstalování na OpenVPN 2.5.x (nebo přepnutí v TunnelBlicku) problém "řeší" (=skryje)
8/ ani jeden ze serverů provoz z VPN neroutuje, servery poskytují služby přímo do VPN = provoz nejde přes další zařízení
9/ nepozoroval jsem, že by se totéž týkalo jiných služeb (ale to může znamenat jen to, že jsem si toho nevšiml)
10/ uživatel, který má problémy s OpenVPN 2.6 a dejme tomu se nepřipojí přes domácího poskytovatele nemá problém přes jiného poskytovatele (třeba přes hotspot na mobilu)

V první řadě mě zajímá - pozorovali jste něco podobného?

Není mi jasné, jak by cokoli cestou mohlo mít vliv specificky na jeden protokol přenášený VPN a ne na ostatní. Samozřejmě mě napadají divoké spekulace - třeba zavirovaný router v cestě, nebo cosi shnilého v síti poskytovatele... ale zase - jak by mohl byť zavirovaný router zasáhnout jen Sambu a ne třeba ping skrz tutéž VPN? To by pak VPN zcela postrádala smysl. Krom toho jsem nepozoroval podezřelý provoz, který bych s tím dokázal spárovat. (to neznamená, že není...)

Díky předem za každý konstruktivní nápad.

[Reklama]

[LamZelezo]

Změř MTU jednotlivých VPNek a případně nastav dle měření.

[kutildomaci]

Změř MTU jednotlivých VPNek a případně nastav dle měření.

To bude muset pár dnů počkat až budu mít příležitost se připojit k někomu v lokalitě odkud to nefunguje. V tuto chvíli mohu říct jen to, že všude mám nastaveno výchozích 1500 bytů...

z logu OpenVPN klienta 2.6.13
link_mtu = 1500
tun_mtu = 1400
tls_mtu = 1250

V žádné z konfigurací jsem velikost MTU neměnil, všude je výchozí. Pokud to výchozí nastavení nefunguje, tak bych zároveň čekal, že si toho někdo všimne... v mém případě to je tak 1 - 2 lidi z 20 až 30 uživatelů na server? To mi nepřijde tak vzácné.

Když jsem zkusil ping l 60000 ipv4 tak mi tcpdump -vv -i tun0 ... ukazuje velikost ICMP fragmentů 1500, přičemž stejným způsobem vidím, že samba packety při procházení složkami s jednoduchou strukturou se pohybují max ve stovkách.

[LamZelezo]

Neco resit bude mit smysl, az budes mit vysledky mereni.

[lojza007]

OpenVPN je docela robustní a spoustu chyb zvládne. Ale pokud to s verzí 2.5 funguje, tak tam mají opravdu něco špatně, respektive něco bude přísněji nastaveno (možná to nějaký parametr umí vypnout?). Taky tipuju, že je problém s MTU, v rámci spoje by to možná chtělo snížit někam kolem 1200 a pak případně zvyšovat, ale každý spoj bude mít to MTU jinak, uvnitř spoje by pak neměl být problém s normálním MTU, kdy to prostě bude fragmentovat packety.
Další možný test je na klientovi to MTU snížit ručně a zkusit. Každopádně i SMB toho celkem dost snese.
Co případně přejít na Wireguard? Ten toho nejspíš snese ještě víc nebo IPSec, který bývá dost často povolený i na různých hotspotech kvůli VoWIFI.

A pokud je ten specifický provider O2, tak to už jsem někde taky zahlídl, že v případě VDSL můžou být s VPN různé problémy, zdrojem je opět MTU.

Každopádně kromě experimentů s MTU bych určitě doporučil Wireshark na stanici a tcpdump na serveru, už v rámci té komunikace může být vidět, co přesně se děje.

[Reklama]

[kutildomaci]

V tuto chvíli vím, že ping xxxx -s 60440 projde správně a správně se fragmentuje.

Nakouknul jsem záznamů z tcpdumpu WireSharkem během navazování spojení Sambou:

Začátek komunikace proběhne v obou verzích VPN stejně (NTLMSSP_AUTH atd...) až k "SRVSVC 56 NetShareEnumAll response...", potom v obou případech klient pošle "[TCP Dup ACK 39#1] ..." a na nefunkční OpenVPN 2.6 server odpovídá 8x "1440 [TCP Retransmission] 445 → 50000 [ACK]..." což při použití OpenVPN 2.5 nenastalo, tam komunikace probíhá dál zobrazením obsahu složky. Stejně to začalo zlobit nejméně ve dvou případech ve stejném okamžiku.

V případě OpenVPN 2.5 následují "Tree Connect Request Tree:..." a odpovědi na ně. Tj. normální provoz, zobrazení složky, vytváření metadat ._.DS_Store v případě MACku...

V případě OpenVPN 2.6 následuje opět "Session setup request ...", k pokusu o zobrazení složky vůbec nedojde.


Protože v packetech SMB2 byly zamíchané i DNS dotazy, tak vím, že i DNS prochází správně.

Jsem omezený tím, co můžu provádět na PC uživatelů a všechna připojení odkud se mohu já připojit tenhle problém nemají. Proto se znovu ptám - stalo se vám to někde? Pozorovali jste něco podobného?

Mezitím čekám na další příležitost zkoumat u někoho s Windows...