WiFi ve vlacích ČD (CDWiFi) a VPN workaround (MTU≤1398)

Možná jste si všimli, když se potřebujete ve vlaku ČD připojit na jejich WiFi (protože v pokovených sklech oken vagonů, které se chovají jako Faradayova klec, není většinu cesty stejně mobilní signál použitelný na volání a hotspot a práci na notebooku) a chcete se připojit na skoro libovolnou VPN, tak vám po připojení na VPN často prakticky vůbec nejde internet.

Přišel jsem na to, co je blbě s WiFi Českých drah a proč na tom selhává většina VPN připojení. Není to proto, že by to ČD záměrně blokovala. Je to chyba v síťové konfiguraci (TCP/IP stacku).

TL;DR: Je potřeba si zmenšit MTU na VPN síťovém rozhraní používající UDP protokol, aby to prošlo linkou co mají ČD za wifi AP ve vlacích.

ČD mají na trase z vlaku dál do internetu menší MTU (max velikost L2 datagramu), než je standardní, protože to připojení asi mají zabalené do další VPN vrstvy zřejmě kvůli bondingu konektivity přes víc SIM karet či operátorů. Jenže to vašemu počítači a síťovému stacku vašeho OS ta ČD WiFi neřekne.

VPN, co nastavují normální MTU na TUN připojení v UDP režimu epicky failujou, protože to spojení ČD delší datagramy, tj naprostou většinu dat, potichu zahazuje místo aby je odmítalo s chybou.

OpenVPN v TCP režimu si s tím umí poradit. Věci, co běží na UDP, tedy většina VPN protokolů i řady dalších aplikací, ale nikoli.

Místo aby síťové rozhraní vracelo na větší datagramy způsobně zprávu Message too long, tak cokoli mezi 1398 a 1500 b velikosti se ztrácí v černé díře Českých drah.

Pro funkční OpenVPN v UDP režimu je potřeba manuálně hrábnout do konfiguračního souboru .ovpn profilu, zakázat přijetí MTU od serveru a vynucení vlastní, nižší MTU aby se všechny datagramy vešly pod to okno mezi 1398 a 1500 b a všechno se krájelo na menší chunky:

pull-filter ignore "tun-mtu"
pull-filter ignore "link-mtu"
tun-mtu 1398
mssfix 1398
mtu-disc no

V tu chvíli v logu OpenVPN klienta najdete něco jako

2024-08-09 05:54:09 Pushed option removed by filter: 'tun-mtu 1500'
2024-08-09 05:54:09 net_iface_mtu_set: mtu 1398 for tun0

Stabilně už teď jedu na Linuxu s vlastním OpenVPN serverem doma nebo v práci v UDP režimu ve vlaku ČD.

ProtonVPN klient mi nedovoluje měnit tyhle parametry a linuxový klient mi funguje jen když v nastavení pustím OpenVPN v TCP režimu:

Pro OpenVPN/udp bych si asi musel stáhnout .ovpn profily a připojovat se ručně přes NetworkManager nebo openvpn klienta.

Na Windows teď nemám jak testovat, ale pokud stejným problémem trpí i ostatní protokoly jako výchozí Wireguard či Stealth a IKEv2, tak i na Windows může být nutné si vynutit jen OpenVPN/tcp a nebo si stáhnout ty openvpn konfiguráky a do nich si hrábnout a připojovat se přes OpenVPN klienta namísto oficiálního VPN klienta.

Po VPN připojení by měl linuxový ping s parametry:

ping -M do -s 1370 google.com

projít normálně

zatímco

ping -M do -s 1371 google.com

když to nefunguje po připojení na VPN v UDP režimu správně to nic neodpoví (vše timeoutuje),

po opravě MTU u klienta to už správně aspoň vrátí, že Message too long:

ping: local error: message too long, mtu=1398

Shrnuto: Myslel jsem, že ČD nějak chtějí záměrně blokovat VPN, když po připojení na VPN prakticky vypadne internet, ale reálně to je „jen“ nesprávně konfigurovaný TCP/IP stack.

Problém je, pokud nemáte vlastní VPN server na bázi OpenVPN nebo komerční VPN co umí připojení i v TCP režimu, ale nějakou proprietární korporátní VPN, která se na takovéto nestandardní připojení neumí sama přizpůsobit a nemůžete si zároveň upravit parametry maximálního MTU pro VPN síťové rozhraní.