VPN MTUren mitoak: zergatik txikitzen diren zure paketeak eta nora doan tokia

Norbaitek esaten dizu VPNak "paketeak galtzen dituela MTU dela eta", zuk tunela 1400era jartzen duzu, eta transferentziak berriro funtzionatzen du. Emaitza horrek diagnostiko itxura du. Normalean aritmetikaren kasualitatea da: inoiz identifikatu ez zenuen muga baten azpitik sartzeko adina txikia den zenbaki bat aukeratu zenuen, eta hurrengo sarean muga bera aurkituko duzu, aurrekontu desberdinarekin.

Bi mitok eragiten dute horren zatirik handiena. Lehenengoa da tunelaren interfazearen MTUa bidearen MTUa dela. Bigarrena da enkapsulazioak "goiburu bat" kostatzen duela eta PPPoEk ez duela zenbatzea merezi duen ezer kostatzen. Biak oker daude, aukeratzen duzun zenbakia arbitrarioa dirudien moduan, nahiz eta benetan zehaztuta egon.

Lehen mitoa: tunelaren MTUa bidearen MTUa da

Tunel baten interfazean jartzen duzun balioa inplementazioak behera emango duen barne pakete handienari buruzko tokiko promesa da. Bidearen benetako ahalmena zu eta urruneko muturraren arteko esteka bakoitzaren ezaugarria da, eta aldatu egin daiteke ibilbide bat aldatzen denean, konexio mugikor batek esku-hartzen duenean edo trafikoak beste peering bat hartzen duenean. Konfiguratutako 1500 batek zure hostak zer eraikiko duen esaten dizu, ez sareak zer eramango duen.

Bidearen MTUaren aurkikuntza biak adosteko dago, eta atzeraelikaduraren mende dago. IPv4n, tamaina osoko pakete bat aurrera eraman ezin duen bideratzaileak ICMP "fragmentation needed" mezua bidali beharko luke, eta bidaltzaileak bere estimazioa jaisten du. IPv6n, baliokidea Packet Too Big mezua da, eta bideratzaileek ez dute trantsituko zatitzerik egiten. Atzeraelikadura hori iragazten denean, bidaltzaileak bideak eraman ezin dituen paketeak sortzen jarraitzen du, eta ezerk ez dio zergatik esaten.

Bigarren mitoa: enkapsulazioak goiburu bat kostatzen du

Zenbatu kanpoko geruzak zintzotasunez. Kanpoko IP goiburua 20 bytekoa da IPv4n edo 40koa IPv6n. NAT zeharkatzeko UDP enkapsulazioak 8 gehitzen ditu. Tunelaren protokoloak bere goiburua gehitzen du, hasieratze bektore bat edo nonce bat, zifratzearen bloke edo lerrokatze mugara arteko betegarria, amaierako atal bat eta osotasun egiaztapen balio bat. Protokoloaren eta zifratzearen arabera, guztizkoa lasai asko hamarnaka bytetan dago barne paketea hasi aurretik.

Gero kendu berriro barne paketearen bere goiburuak. Tunelaren barruko TCP segmentuak bere 20 byteko IP goiburua eta 20 byteko TCP goiburua daramatza, eta TCPren MSSa MTUtik eratortzen da, ez tunelaren karga nominaletik. Horregatik ping karga txikiagoarekin arrakastatsu izan daiteke fitxategi transferentzia trabatuta dagoen bitartean: tresnek gauza desberdinak probatzen dituzte, eta horietako batek soilik erabiltzen du tamaina osoko TCP segmentu bat.

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

Lehen komandoak konfiguratutako tunelaren MTUa jakinarazten du. Bi probeek 1472 byteko karga bidaltzen dute, eta hori IPv4 eta ICMP goiburuen 28 byteekin 1500 byteko paketea da, gero txikiago bat. Probe handiak erabat huts egiten badu eta txikiak arrakasta, tamainaren araberako akatsa duzu, ez bideratze arazo orokorra.

Hirugarren mitoa: PPPoEk oraindik 1500 garbia ematen dizu

PPPoE sarbide esteka konbentzional batek ez du 1500 byteko IP paketerik eramaten. PPPoE goiburuak eta PPP protokolo eremuak Ethernet markoaren barruan 8 byte hartzen dituzte, eta horrek 1492 uzten ditu IP paketerako. Hori da RFC 2516an deskribatutako muga tradizionala. VPN bat horrelako esteka baten gainean exekutatzen baduzu, tunelaren gainkarga 1492 horietatik ateratzen da, ez 1500etatik.

RFC 4638k PPP karga handiagoa negoziatzeko modua definitzen du, sarbide kontzentratzaileak eta bezeroaren ekipoak hori onartzen dutenean; horregatik "konexio honek PPPoE erabiltzen du" bakarrik ez du zenbaki zehatzik frogatzen. Tokiko ezarpen batek ezin du tarteko gailu bat sekula konfiguratu ez zaion pakete bat onartzera behartu, beraz galdera erabilgarria da estekak benetan zer negoziatu zuen, ez etiketak zer dioen.

Zergatik dirudi hutsegiteak selektiboa

Eskaera txikiak arrakastatsu izatea eta transferentzia handiak trabatzea bideko MTUaren zulo beltzaren sinadura klasikoa da. Esku-ematea, DNS kontsulta eta API deia denak sartzen dira; transferentzia masiboak esteka batean hiltzen diren tamaina osoko segmentuak sortzen ditu, eta arazoa jakinarazi behar zuen ICMP mezua ez da inoiz iristen. Konexioak ondo dirudi eta deskargak zintzilik geratzen da, eta horrek jendea bideari begiratu beharrean zerbitzariari begiratzera bidaltzen du.

Bigarren akats erlazionatua hiru zenbaki nahastea da: interfazearen MTUa, TCPren MSSa eta protokoloaren beraren zatiketa edo betegarri ezarpena. Bideratzaile batean MSS klampatzeak iragarritako MSSa berridazten du bidaltzaileak segmentu txikiagoak eraiki ditzan; ez du tunelaren MTUa aldatzen, eta ez dio UDP trafikoari laguntzen. Hirurei zenbaki bera ematea erlazionatuta diruditelako da aldaketa ondo pentsatu batek konfigurazio funtzionala hausten duen modua.

Zer aldatu, eta zein ordenatan

Hasi frogekin. Berretsi goiko probeekin hutsegitea tamainaren araberakoa dela, eta gero aurkitu pasatzen den tamainarik txikiena eta huts egiten duen handiena. Egiaztatu sarbide estekaren benetako MTUa tunelari errua bota aurretik; PPPoE esteka batek aurrekontua mugatzen du zure VPNak ukitutako aurretik. Idatzi jatorrizko balioak aldaketa atzera bota ahal izateko.

Gero aplikatu bezeroak dokumentatzen duen doikuntza txikiena. Bezero askok tunelaren MTUa eta MSS konponketa aukera eskaintzen dituzte, eta MSS aukera hobea izaten da TCPrako, pakete bakoitza txikitu gabe bidaltzailearengana iristen delako. Probatu berriro helmuga bera eta transferentzia bera, eta idatzi erabaki zenuen zenbakiak. Sarbide sare batean funtzionatzen duen tunel balioa ez da konstante unibertsala, eta hurrengo guneak bere aurrekontua izango du.