Mitet e MTU-së në VPN: pse paketat tuaja tkurren dhe ku shkon hapësira

Dikush të thotë se VPN-i "po humb paketa për shkak të MTU-së", ti e vendos tunelin në 1400 dhe transferimi funksionon përsëri. Ai rezultat duket si diagnozë. Zakonisht është një rastësi aritmetike: zgjodhe një numër mjaft të vogël për t'u futur nën një kufi që nuk e identifikuat kurrë, dhe do të hasni të njëjtin kufi përsëri në rrjetin tjetër me një buxhet tjetër.

Dy mite shkaktojnë pjesën më të madhe të kësaj. I pari është se MTU-ja e ndërfaqes së tunelit është MTU-ja e rrugës. I dyti është se enkapsulimi kushton "një krye" dhe PPPoE nuk kushton asgjë që ia vlen të numërohet. Të dy janë të gabuar në mënyra që e bëjnë numrin e zgjedhur të duket arbitrar ndërkohë që në fakt është i përcaktuar.

Miti i parë: MTU-ja e tunelit është MTU-ja e rrugës

Vlera që vendosni në një ndërfaqe tuneli është një premtim lokal për paketën më të madhe të brendshme që implementimi do të dorëzojë poshtë. Kapaciteti real i rrugës është një veti e çdo lidhjeje midis jush dhe skajit të largët, dhe mund të ndryshojë kur ndryshon një rrugë, kur një lidhje celulare transferohet ose kur trafiku merr një peering tjetër. Një 1500 e konfiguruar ju tregon çfarë do të ndërtojë hosti juaj, jo çfarë do të mbajë rrjeti.

Zbulimi i MTU-së së rrugës ekziston për të pajtuar të dyja, dhe varet nga reagimi. Në IPv4, një ruter që nuk mund të përcjellë një paketë me madhësi të plotë duhet të dërgojë një mesazh ICMP "fragmentation needed", dhe dërguesi ul vlerësimin e tij. Në IPv6, ekuivalenti është një mesazh Packet Too Big, dhe ruterët nuk fragmentojnë fare në tranzit. Kur ai reagim filtrohet, dërguesi vazhdon të prodhojë paketa që rruga nuk mund t'i mbajë, dhe asgjë nuk i thotë përse.

Miti i dytë: enkapsulimi kushton një krye

Numëroni shtresat e jashtme me ndershmëri. Një krye IP e jashtme është 20 bajt në IPv4 ose 40 në IPv6. Enkapsulimi UDP për kalimin e NAT shton 8. Protokolli i tunelit shton kryen e vet, një vektor inicializimi ose nonce, mbushje deri në kufirin e bllokut ose të rreshtimit të shifrimit, një bisht dhe një vlerë kontrolli integriteti. Në varësi të protokollit dhe shifrimit, totali qëndron rehat në dhjetëra bajt përpara se paketa e brendshme të fillojë fare.

Pastaj zbritni përsëri kryet e vetë paketës së brendshme. Një segment TCP brenda tunelit mban kryen e vet IP prej 20 bajt dhe kryen TCP prej 20 bajt, dhe MSS e TCP rrjedh nga MTU-ja, jo nga ngarkesa nominale e tunelit. Kjo është arsyeja pse ping me ngarkesë më të vogël mund të ketë sukses ndërsa një transferim skedari ngec: mjetet testojnë gjëra të ndryshme, dhe vetëm njëri prej tyre ushtron një segment TCP me madhësi të plotë.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

Komanda e parë raporton MTU-në e konfiguruar të tunelit. Dy sondat dërgojnë një ngarkesë prej 1472 bajt, që me 28 bajt krye IPv4 dhe ICMP është një paketë 1500 bajt, pastaj një më të vogël. Nëse sonda e madhe dështon plotësisht dhe ajo e vogël ka sukses, keni një defekt që varet nga madhësia, jo një problem të përgjithshëm rrugëtimi.

Miti i tretë: PPPoE ju jep ende 1500 të pastër

Një lidhje aksesi PPPoE konvencionale nuk mban një paketë IP prej 1500 bajt. Kryeja PPPoE plus fusha e protokollit PPP zënë 8 bajt brenda kuadrit Ethernet, duke lënë 1492 për paketën IP. Ky është kufiri tradicional i përshkruar në RFC 2516. Nëse drejtoni një VPN mbi një lidhje të tillë, kostot shtesë të tunelit vijnë nga ato 1492, jo nga 1500.

RFC 4638 përcakton një mënyrë për të negociuar një ngarkesë PPP më të madhe kur e mbështesin si koncentratori i aksesit ashtu edhe pajisja e klientit, prandaj "kjo lidhje përdor PPPoE" vetëm nuk provon një numër të caktuar. Një cilësim lokal nuk mund të detyrojë një pajisje të ndërmjetme të pranojë një paketë për të cilën nuk është konfiguruar kurrë, prandaj pyetja e dobishme është çfarë negocioi në të vërtetë lidhja, jo çfarë thotë etiketa.

Pse defekti duket selektiv

Që kërkesat e vogla kanë sukses dhe transferimet e mëdha ngecin është nënshkrimi klasik i një vrime të zezë të MTU-së së rrugës. Shtrëngimi i duarve, pyetja DNS dhe thirrja API të gjitha futen; transferimi masiv prodhon segmente me madhësi të plotë që vdesin në një lidhje, dhe mesazhi ICMP që duhej të raportonte problemin nuk mbërrin kurrë. Lidhja duket në rregull dhe shkarkimi varet, gjë që i bën njerëzit të shikojnë serverin në vend të rrugës.

Një gabim i dytë i lidhur është përzierja e tre numrave: MTU-ja e ndërfaqes, MSS e TCP dhe cilësimi i vetë protokollit për fragmentim ose mbushje. Shtrëngimi i MSS në një ruter rishkruan MSS-në e shpallur që dërguesi të ndërtojë segmente më të vogla; nuk e ndryshon MTU-në e tunelit dhe nuk ndihmon trafikun UDP. T'u japësh të treve të njëjtin numër sepse duken të lidhur është mënyra se si një ndryshim me qëllim të mirë prish një konfigurim që funksionon.

Çfarë të ndryshohet dhe në çfarë rendi

Filloni me prova. Konfirmoni me sondat më sipër se defekti varet nga madhësia, pastaj gjeni madhësinë më të vogël që kalon dhe më të madhen që dështon. Kontrolloni MTU-në reale të lidhjes së aksesit përpara se të fajësoni tunelin; një lidhje PPPoE e kufizon buxhetin përpara se VPN-i juaj ta prekë. Shënoni vlerat origjinale që ndryshimi të mund të kthehet.

Pastaj aplikoni rregullimin më të vogël që dokumenton klienti. Shumë klientë ofrojnë një MTU tuneli plus një opsion rregullimi të MSS-së, dhe opsioni MSS shpesh është levë më e mirë për TCP sepse arrin te dërguesi pa e zvogëluar çdo paketë. Ritestoni të njëjtin destinacion dhe të njëjtin transferim, dhe shënoni numrat ku u ndalet. Një vlerë tuneli që funksionon në një rrjet aksesi nuk është konstante universale, dhe vendi tjetër do të ketë buxhetin e vet.