Odpojování od datových schránek při větším stahování

[Adam Kalisz]

Trochu bojuji s webem www.mojedatovaschranka.cz. Příbuzný se snažil z datové schránky stáhnout ca. 2 MB přílohu v Chrome na Windows 11 a opakovaně ho to vyhazovalo s hláškou "Byli jste odhlášeni z informačního systému datových schránek. V průběhu vašeho přístupu došlo ke změně IP adresy. Problém je na straně vašeho připojení k internetu nebo nastavení vašeho OS. Obraťte se prosím na Infolinku pro více informací."
Počítač byl připojený přes Wi-Fi na původní Turris Omnia. Internetová přípojka je dlouhodobě stabilní a poskytuje dual-stack public IPv4 a IPv6. Podle logů z vývojářských nástrojů bylo sezení s datovými schránkami realizováno přes IPv6.

Na routeru v té době již proběhl upgrade na Turris 7.0, ale ještě nebyl router rebootovaný. Připojení kabelem situaci nijak nezměnilo. Bylo podezření, že možná je slabá Wi-Fi, protože předcházející hovor přes Signal moderního smartphone měl špatnou kvalitu.

Nakonec se podařilo přílohu stáhnout po rebootu routeru. Současně bylo přihlášení ale realizováno z anonymního okna Chrome. Následně jsme zkusili i hovor přes Signal na stejném místě ze stejného smartphone, který byl bezproblémový.

Ze souboru HAR, který mi byl zaslán ze sezení, kdy byl ten problém reprodukován, jsem nebyl schopen nic vyčíst.

Zaregistroval někdo v mezidobí mezi upgradem Turris a rebootem nějakou podobnou nestabilitu/ zvláštní chyby? Nepřijde mi, že by se mi svévolně měnily IP adresy u připojených zařízení. Na routeru jsem byl na dálku připojen a neviděl jsem nic na první pohled divného. Ping na připojená zařízení měl i přes Wi-Fi proměnlivě od 0,7 ms do ca. 1,3 ms s občasným odskokem k třeba 3,5 ms, žádný packet loss, z mého pohledu běžná Wi-Fi.

Na www.mojedatovaschranka.cz nejsem schopen pingat ani na IPv4 ani IPv6, ale nezdá se mi, že by byl problém zrovna v tomto.

Vím, že tohle je hyper vágní popis, ale třeba bude mít někdo nápad, jak takovou věc lépe debuggovat a nebo si nebude škubat vlasy, prostě router otočí, nainstuuje anonymní okno a třeba to taky půjde. (Nevím, jestli to bylo anonymním oknem, nebo restartem routeru/ updatem na Turris 7.0. Debugging s lidmi večer po telefonu po celém týdnu v práci je výzva...)

[Reklama]

[.]

V nastavení DS tu dementní pseudo-ochranu změny IP adresy vypnout.

[Marek Staněk]

Nemá v OS náhodou zapnutou randomizaci MAC adresy? Protože pak při každém bliknutí wifiny dostane od DHCPka novou IP adresu. BTW pokud je na místě, kde mu wifina padá hodně často a na routeru nastavený malý pool adres, může to snadno dostat do stavu, kdy mu router novou IP klidně několik hodin nebo i dní nepřidělí, pokud jeho systém uplatňuje ochranu už přidělených adres a drží je pro případ, že by se během platnosti zápůjčky původní MAC znovu připojila.

[mikesznovu]

Klíčové je jestli šlo o :
- je stroj z NATem? pokud ano používá více source adres ? Měla by zůstávat vybraná adresa stabilní, ale možná je i randomizace podle cíle, zdroje, portu, čase
- o změnu portu (něco jako "kdyby neexistoval keepalive") , případně simulovatelné  příkazem promazání conntrack -F
-mění se veřejná IP adresa (to co vidí server)?
-mění se vnitřní adresa klienta (ta zmíněná randomizace MAC)

[.]

Netřeba hledat záhady, prostě DS je mizerně udělaná. Osobně jsem v několika firmách zažil, že dokud se nevypne ta ochrana IP (jak jsem psal výše), tak i v případě, kdy bylo připojení přes veřejnou pevnou IPv4 a souběžně i IPv6, tak DS si při každém úkonu svévolně detekovala IP, jakou uznala sama za vhodné a uživatele vyhazovala. Prostě ochranu proti změně IP vypnout a tím je problém vyřešen.

[Reklama]

[Filip Jirsák]

Netřeba hledat záhady, prostě DS je mizerně udělaná. Osobně jsem v několika firmách zažil, že dokud se nevypne ta ochrana IP (jak jsem psal výše), tak i v případě, kdy bylo připojení přes veřejnou pevnou IPv4 a souběžně i IPv6, tak DS si při každém úkonu svévolně detekovala IP, jakou uznala sama za vhodné a uživatele vyhazovala. Prostě ochranu proti změně IP vypnout a tím je problém vyřešen.

Server vskutku nemůže svévolně detekovat, jakou IP adresu uzná za vhodné, protože má k dispozici jedinou IP adresu – tu, se kterou klient navázal TCP/IP spojení. Pokud jeden klient k jednomu serveru v jednu dobu navazuje spojení jednou po IPv4 a podruhé po IPv6, je něco divného na straně klienta.

Ochrana na straně serveru proti změně IP adresy klienta je vždycky problematická a je dobře, že to jde na straně DS alespoň vypnout. Ale pokud klient při komunikaci s jedním serverem střídá IPv4 a IPv6, je to problém klienta.

[Marek Staněk]

mě šlo o to, že pokud má počítač nebo teolefon nastavenou randomizaci MAC, tak při každém připojení po byť krátkodobém výpadku wifi hlásí jinou MAC => dostane jinou IP => při opakovaném přístupu na tutéž IP serveru mu NAT přidělí nový odchozí port => z pohledu DS je to nové připojení a vlaky přes to nejedou.

[.]

Netřeba hledat záhady, prostě DS je mizerně udělaná. Osobně jsem v několika firmách zažil, že dokud se nevypne ta ochrana IP (jak jsem psal výše), tak i v případě, kdy bylo připojení přes veřejnou pevnou IPv4 a souběžně i IPv6, tak DS si při každém úkonu svévolně detekovala IP, jakou uznala sama za vhodné a uživatele vyhazovala. Prostě ochranu proti změně IP vypnout a tím je problém vyřešen.

Server vskutku nemůže svévolně detekovat, jakou IP adresu uzná za vhodné, protože má k dispozici jedinou IP adresu – tu, se kterou klient navázal TCP/IP spojení. Pokud jeden klient k jednomu serveru v jednu dobu navazuje spojení jednou po IPv4 a podruhé po IPv6, je něco divného na straně klienta.

Ochrana na straně serveru proti změně IP adresy klienta je vždycky problematická a je dobře, že to jde na straně DS alespoň vypnout. Ale pokud klient při komunikaci s jedním serverem střídá IPv4 a IPv6, je to problém klienta.

To tak ale právě není a osobně jsem vyzkoušel, že DS detekovala IPv4 a po pár minutách práce (bez odhlášení) pak IPv6 a usera vyhodila. A podotýkám, že jsem to identicky zažil ve dvou různých firmách, přičemž připojení bylo v jedné firmě přes Vodafone a ve druhé přes nej.cz, přičemž to dělalo v obou firmách stejně až do vypnutí té ochrany (jenom pro úplnost, tak obě firmy spolu neměly vůbec nic společného).

Výše uvedené není problém klienta, ale mizerně provedené DS. Samozřejmě to, že lze ochranu vypnout, je nejenom dobře, ale prakticky i nutnost.

[Filip Jirsák]

To tak ale právě není a osobně jsem vyzkoušel, že DS detekovala IPv4 a po pár minutách práce (bez odhlášení) pak IPv6 a usera vyhodila.

Ale server nic takového detekovat nemůže, technicky není jak. Server zná IP adresu klienta (a tedy i protokol), který se k němu připojil. Ta situace, co popisujete, může nastat, ale pak to znamená, že se k serveru klient připojil jednou po IPv4 a pak po IPv6. A to fakt není chyba serveru. Na poskytovateli to nezáleží, spíš na klientovi a routeru. Např. by to mohlo nastat, pokud si klient nebo router chvíli budou myslet, že IPv6 konektivitu nemají a klient použije IPv4.

Čistě teoreticky by něco takového mohlo nastat chybou serveru v případě, že by část služeb poskytoval jen po IPv4 a na některé z těch služeb byla také ta kontrola IP adresy. Ale webové rozhraní datových schránek, na kterém probíhá ta kontrola, je provozováno jen z jendé domény. Nebo by to mohla chyba serveru být v případě, kdy by DNS server chvíli neposkytoval AAAA záznamy (nebo A, ale to by neprošlo bez povšimnutí). Tj. v obou případech by server donutil klienta zvolit jiný protokol. Ale je to nepravděpodobné.

[.]

Nemám důvod si vymýšlet a kromě toho i úvodní dotaz od jiného usera potvrzuje, že na straně DS nějaký problém s IP prostě je. No ať je to jak chce, tak hlavně, že řešení problému je poměrně triviální.

[Ondřej Caletka]

Ochrana na straně serveru proti změně IP adresy klienta je vždycky problematická a je dobře, že to jde na straně DS alespoň vypnout. Ale pokud klient při komunikaci s jedním serverem střídá IPv4 a IPv6, je to problém klienta.

Je to problém klienta, ale není to nic divného, je to standardizované chování zvané Happy Eyeballs, kdy spolu zápasí IPv6 a IPv4 o to, kterému se podaří navázat spojení dřív. Pokud oba protokoly fungují zhruba stejně dobře (resp. IPv6 funguje o trochu hůř než IPv4 - ale právě o takovou trochu, o jakou dostává od algoritmu HE náskok), pak se klient náhodně připojuje tu po IPv4, tu po IPv6.

Nemá v OS náhodou zapnutou randomizaci MAC adresy? Protože pak při každém bliknutí wifiny dostane od DHCPka novou IP adresu.

Který OS mění MAC adresu při každém připojení ke stejné síti? To rozhodně není běžné, běžně jsou náhodné MAC adresy v rámci jedné sítě stabilní.

[Filip Jirsák]

Nemám důvod si vymýšlet a kromě toho i úvodní dotaz od jiného usera potvrzuje, že na straně DS nějaký problém s IP prostě je. No ať je to jak chce, tak hlavně, že řešení problému je poměrně triviální.

Vy jste pozoroval, že DS odpojily klienta kvůli změně IP adresy mezi IPv4 a IPv6. To nerozporuju. Ale už si domýšlíte, že to je problém na straně DS. A to s největší pravděpodobností pravda není.

Je to problém klienta, ale není to nic divného, je to standardizované chování zvané Happy Eyeballs, kdy spolu zápasí IPv6 a IPv4 o to, kterému se podaří navázat spojení dřív. Pokud oba protokoly fungují zhruba stejně dobře (resp. IPv6 funguje o trochu hůř než IPv4 - ale právě o takovou trochu, o jakou dostává od algoritmu HE náskok), pak se klient náhodně připojuje tu po IPv4, tu po IPv6.

Právě to mi připadá divné, na normálně fungujícím dual-stacku by měl mít IPv6 přednost. Ale rozumím, že to může vychýlit i drobnost, a normálně (bez kontroly IP adres) se na to nepřijde.

[.]

I kdybych připustil u jedné z firem problém na straně klienta, tak rozhodně nepřipustím, že u druhé firmy je také problém na straně klienta a autor toho vlákna má také problémy s klientem. Prostě všichni nemohou mít špatné klienty, takže chyba je bez debat na straně DS nebo jinak řečeno, pokud je výše uvedené chování klientů standardem (což být může, o tom se nehádám), pak by tvůrci DS měli s tímto počítat. A nejlépe nechat ochranu IP u DS defaultně vypnutou (stejně je to ochrana k lejnu a např. internetová bankovnictví nic takového nemají, resp. jsem to u žádné z bank nezaznamenal a také se svět nezbořil).

[Filip Jirsák]

Všichni mohou mít „špatné“ klienty, Ondřej Caletka výše vysvětloval, proč se to může dít. Jestli je to chyba klienta nebo ne je těžko říct – já bych od prohlížeče čekal, že když už jednou zjistí, která cesta je lepší, bude se jí nějakou dobu držet (třeba dokud nedojde k nějaké změně v síti, neukončí se prohlížeč, neuspí prohlížeč, nepřestane daná komunikace fungovat). Ona taková změna IP adresy také může způsobit, že komunikace skončí v jiném datovém centru, což třeba kvůli eventually consistent synchronizaci může znamenat, že klient uvidí stará data. Za mne by měl klient změnit IP adresu jen když už mu nic jiného nezbývá, ne jen tak, protože tím možná ušetří tři milisekundy.

Mimochodem, nevíte, o jaký prohlížeč se jednalo? Zrovna u Chrome, který je zmíněn v otázce, by mne to docela překvapilo, protože bych čekal, že v Googlu lidé od cloudu vysvětlí kolegům od prohlížeče, že to není dobrý nápad.

Mně se ochrana IP adresy také nelíbí, ale pokud už má být implementovaná, musí být ve výchozím nastavení zapnutá, Protože přesně ti uživatelé, kteří by si ji měli zapnout, ji nikde zapínat nebudou.

[.]

V jednom případě šlo o Chrome a přihlášení do DS klasicky jménem a heslem (to bylo připojení přes nej.cz). Ve druhém případě pak EDGE a přihlášení do DS přes bankovní identitu České spořitelny (připojení přes kabelovku Vodafone - exUPC).