Actualizarea 20.04 provoacă erori de rețea și corupție de copiere a fișierelor clienților Windows

Am un client care are o mașină virtuală Ubuntu 20.04 care rulează într-un server NAS qNAP care oferă funcționalitate de gestionare a informațiilor clienților Windows 10.VM-ul este alăturat domeniului lor, dar serverul qNAP nu este. Serverul NAS este folosit doar ca un loc ușor pentru a rula VM. VM-ul oferă mult mai multe funcționalități decât dispozitivul NAS pentru acest client, ale cărui detalii sunt puțin implicate și ar necesita mai mult spațiu decât permite acest forum. (Aș fi bucuros să discut despre asta cu oricine pe un canal lateral...)

Această configurație a rulat cu succes de luni de zile fără probleme până vineri trecute. Aceste servere NAS au fost vizate de o bandă de ransomware, așa că qNAP a decis să forțeze o actualizare a sistemului de operare NAS. Probabil că nu este cea mai bună abordare, dar asta s-a întâmplat. Apoi am intrat la distanță în sistemul lor și am actualizat Ubuntu VM. Apoi software-ul de deasupra a fost actualizat. În retrospectivă, probabil că nu a fost o idee bună să actualizăm totul dintr-o dată, dar asta a funcționat aici, în laboratorul nostru. Totuși, atunci a început distracția...

Software-ul care rulează în VM are software client Windows care este actualizat printr-o partajare Samba care este mapată la o literă de unitate pe sistemele Windows 10. Fișierul .exe care a fost descărcat a avut câteva erori ciudate și nu a rulat. Fișierul părea corupt. Am copiat manual din nou fișierul din partajarea CIFS de pe VM și a eșuat din nou, dar cu o altă eroare. De fiecare dată când copiam fișierul, dimensiunea era corectă, dar eșua într-un mod diferit. Apoi am încărcat o copie direct pe mașina Windows, ocolind VM-ul și totul a fost bine. După cum puteți vedea, există o mulțime de locuri pentru a arăta cu degetul, dar iată ce am făcut în încercarea de a izola problema:

1. Am făcut niște teste de copiere cu următoarele rezultate.
2. Încărcările de fișiere de aproape orice dimensiune (câțiva octeți până la 1 GB) toate au fost încărcate corect în VM.
3. Descărcările de fișiere s-au comportat diferit în funcție de dimensiunea lor. Fișiere mici de câțiva octeți descărcate corect. Fișierele de dimensiunea executabilului (~700k) au fost corupte. Fișierele mai mari decât acestea (câțiva MB) au dat o eroare Windows 0x8007003B. „Eroare de rețea neașteptată” Google pare să indice o problemă cu firewall-ul Windows, care este dezactivată, sau un antivirus care ia în cale, care a fost eliminat. Încă primesc eroarea.
4. M-am uitat în jurnalele de pe VM și pe mașina Windows și nu am văzut probleme.
5. A rulat o sesiune ping lungă pentru a vedea dacă ar putea exista congestie în rețea. Fără pachete scăpate după multe ore de rulare. Problemele persistă în weekend, când toată lumea era plecată.
6. A făcut un winscp de la VM la mașina Windows ocolind samba. Mai are eroarea. Ar indica că nu este o problemă de samba, ci o problemă de rețea de nivel inferior pe VM.
7. A declanșat o partajare direct pe dispozitivul NAS. Asta funcționează perfect. Acest lucru ar părea că elimină anumite tipuri de probleme de rețea externe, cum ar fi cablurile proaste sau dispozitivele de rețea configurate greșit. Totuși, asta nu elimină puntea de rețea internă din dispozitivul NAS utilizat de VM. Am căutat să văd dacă există vreo problemă de configurare acolo, dar nu am găsit-o.
8. Asigurați-vă că cadrele jumbo nu au fost activate. Experiența mea cu cadre jumbo configurate greșit este pachetele abandonate, nu corupția sau erorile de genul acesta.
9. Am făcut o stare smbstatus pe VM pentru a ne asigura că toată lumea rulează SMB3. Sunt. Nu rulează criptarea, dar utilizează semnarea cu AES-128-CMAC. (NOTĂ: 52 de mașini Windows au partajarea mapată la o literă de unitate.)
10. M-am asigurat că Samba rulează pe portul TCP 445. A fost.
11. Am două dispozitive qNAP aici în laboratorul meu care nu se confruntă cu aceste probleme. Singura diferență cu acestea pe care o pot vedea este că au VM-uri care nu sunt pe un domeniu. Îmi este greu să cred că VM-ul pe domeniu ar putea cauza coruperea datelor, dar cred că toți am văzut probleme mai ciudate. Proiectul de astăzi este să le configurez pe domeniul meu de testare aici și să vedem ce se întâmplă.
12. Persoana de suport IT la acest client este excepțională. Am lucrat cu el de-a lungul anilor cu mare succes. Nu există alte probleme raportate de rețea pe site-ul lor.
13. El este dispus să ajute aici, inclusiv să declanșeze Wireshark pentru a vedea dacă putem spune ce se întâmplă.
14. Suntem amandoi nedumeriti...

Iată câteva lucruri pe care m-am gândit să le încerc, dar m-am gândit că aș cere sfaturi, deoarece acestea necesită puțin timp...

1. Conectați un VM la domeniul meu de testare în laboratorul meu.
2. Rulați wireshark în rețeaua lor. Vezi dacă putem vedea ce se întâmplă pe fir.
3. Vedeți dacă putem găsi o mașină Linux suplimentară pentru a vorbi cu VM în încercarea de a elimina partea client Windows din configurație.
4. Creați un VM suplimentar în dispozitivul NAS, dar nu îl actualizați la cel mai recent cod ubuntu. Vedeți dacă acest lucru poate ajuta la izolarea unui fel de problemă de actualizare.

Poate cineva să ofere alte lucruri de căutat sau de făcut?

Mulțumesc anticipat!

Bruce

Ei bine, după 4 zile pe site-ul clientului și o mulțime de configurații diferite încercate, este fără îndoială o problemă cu dispozitivul qNAP NAS. Acea actualizare a sistemului care a fost instalată automat pentru a se apăra împotriva atacului ransomware a rupt aparent rețeaua de pe dispozitivul lor. Rețineți că nu pot spune că este fiecare server qNAP, deoarece am putut configura cât mai aproape de o configurație similară în laboratorul nostru, deși cu un server qNAP de model mai mic, fără nicio corupție a datelor din rețea. Cu toate acestea, după ce le-au restaurat sistemul pe hardware-ul local și și-au adus serverul qNAP înapoi în laboratorul nostru, problema persistă în continuare pe acel server.

Aici este un link către forumul qNAP dacă este cineva interesat.

[https://forum.qnap.com/viewtopic.php?f=318&t=164927][1]

Concluzia... nu are nimic de-a face cu Ubuntu.