OpenVPN mssfix: pse një klient ngec në transfertat e mëdha
mssfix rishkruan madhësinë e segmentit TCP që shpallet brenda tunelit. Nuk e ndryshon madhësinë e UDP, dhe vlera do të thotë vetëm atë që thotë versioni juaj.
Një laptop i vetëm ngec në ngarkimet përmes tunelit ndërsa çdo pajisje tjetër në të njëjtin server vazhdon të punojë. Ky model tregon një rrugë të vetme, jo konfigurimin e serverit, dhe është hyrja e zakonshme në çështjen e mssfix. Opsioni mund të ndihmojë, por vetëm për lidhjet TCP që ai rishkruan vërtet. Njohja e shtrirjes së tij ju pengon të ndryshoni një server që punon për të shpëtuar një klient.
Çfarë rishkruan opsioni
mssfix redakton madhësinë maksimale të segmentit që shpallet në shtrëngimet e duarve TCP që kalojnë përmes tunelit, në mënyrë që ana dërguese të zgjedhë segmente që përshtaten në buxhetin e inkapsuluar. Ai vepron mbi shtrëngimin e duarve, që do të thotë se një lidhje e hapur para ndryshimit mban vlerën e negociuar.
Ai nuk i zvogëlon datagramet UDP dhe nuk vendos MTU-në e tunelit. Dy probleme të ndryshme prodhojnë të njëjtin simptomë: një dërgues TCP që injoron kufirin e rrugës, dhe një rrugë që hedh në heshtje paketa të mëdha të çdo madhësie. mssfix trajton të parën dhe nuk bën asgjë për të dytën.
Ky dallim shpjegon eksperimentet zhgënjyese. Vendosja e një vlere më të vogël në një rrugë me vrimë të zezë ndryshon madhësinë e segmentit, por jo hedhjen që vijon, kështu që transferta dështon në një pikë tjetër.
Shtrirja është TCP brenda tunelit
Rishkruhet vetëm trafiku TCP. Një sesion QUIC, një lojë ose një aplikacion që dërgon datagrame të mëdha UDP do të mbajë madhësitë e veta të paketave, dhe nëse janë ato transfertat që ngecin, rregullimi i përket më mirë MTU-së së tunelit ose rrugës. Lexoni cilin protokoll përdor transferta që dështon para se t'i drejtoheni një opsioni TCP, sepse shtresa e gabuar ka rregullimin e vet.
Edhe drejtimi ka rëndësi. Një cilësim i klientit ndikon në trafikun që ai klient dërgon në tunel, ndërsa serveri mbulon rrjedhat që përçon drejt klientëve. Nëse ngecin vetëm shkarkimet hyrëse, vlera në anën e klientit nuk është e gjithë historia.
Numri dhe fjala kyçe nuk janë të transportueshme
Versioni i komunitetit i OpenVPN 2.6 pranon një fjalë kyçe opsionale pas vlerës. Me mtu, numri përshkruan madhësinë e paketës së jashtme duke përfshirë titujt IP dhe UDP; pa të, argumenti ndjek një konventë tjetër llogaritëse. Prandaj një rresht i kopjuar midis versioneve nuk përshkruan të njëjtin buxhet paketash. Konsultoni faqen e manualit që vjen me ndërtimin që ekzekutoni vërtet, në vend të një udhëzuesi për një version tjetër.
Sintaksa duket kështu:
mssfix 1400 mtu
Trajtoni 1400 si vendmbajtëse, jo si rekomandim për rrugën tuaj. Nxirrni vlerën nga rruga e matur dhe inkapsulimi që përdoret vërtet, dhe mbani mend se klientët në versione më të vjetra ose implementime të tjera mund ta refuzojnë ose ta interpretojnë ndryshe fjalën kyçe.
Konfirmojeni fillimisht në klientin e vetëm
Matni rrugën nga makina që dështon përpara se të ndryshoni ndonjë gjë. Një ngarkesë që rruga mund të mbajë pa fragmentim është numri që kërkoni:
ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1
Sonda e parë përshtatet në një paketë prej 1500 bajtësh pasi shtohen 28 bajtë tituj. Nëse dështon me një gabim fragmentimi dhe më e vogla ka sukses, madhësia e përdorshme ndodhet diku midis tyre, dhe kostot e tunelit zbriten nga lart.
Pastaj përsëritni transfertën që ngeci, në një lidhje të re, dhe krahasoni. Nëse klienti i vetëm përmirësohet ndërsa të tjerët mbeten të paprekur, keni gjetur shtrirjen e problemit. Nëse ngecin të gjithë klientët, vlera në anën e serverit është ajo që duhet rishikuar. Asnjëra nga dy rezultatet nuk justifikon një ndryshim në harduer që nuk ka qenë kurrë në rrugën që dështon.