Mythau MTU y VPN: pam mae eich pecynnau'n crebachu a ble mae'r lle'n mynd

Mae rhywun yn dweud wrthych fod y VPN yn "colli pecynnau oherwydd MTU", rydych yn gosod y twnnel i 1400, ac mae'r trosglwyddiad yn gweithio eto. Mae'r canlyniad hwnnw'n teimlo fel diagnosis. Cyd-ddigwyddiad rhifyddeg ydyw fel arfer: gwnaethoch ddewis rhif sy'n ddigon bach i ffitio o dan derfyn na wnaethoch erioed ei adnabod, a byddwch yn cyfarfod yr un terfyn eto ar y rhwydwaith nesaf gyda chyllideb wahanol.

Mae dau fyth yn achosi'r rhan fwyaf o hyn. Y cyntaf yw mai MTU rhyngwyneb y twnnel yw MTU'r llwybr. Yr ail yw bod encapsulation yn costio "un pennawd" a bod PPPoE yn costio dim sy'n werth ei gyfrif. Mae'r ddau yn anghywir mewn ffyrdd sy'n gwneud y rhif a ddewiswch yn edrych yn fympwyol pan fo mewn gwirionedd yn cael ei bennu.

Myth un: MTU'r twnnel yw MTU'r llwybr

Mae'r gwerth a osodwch ar ryngwyneb twnnel yn addewid lleol am y pecyn mewnol mwyaf y bydd'r gweithrediad yn ei drosglwyddo i lawr. Mae gwir gapasiti'r llwybr yn eiddo i bob dolen rhyngoch chi a'r pen pell, a gall newid pan fydd llwybr yn newid, pan fydd cysylltiad symudol yn trosglwyddo, neu pan fydd traffig yn cymryd peering gwahanol. Mae 1500 wedi'i ffurfweddu yn dweud wrthych beth fydd eich gwesteiwr yn ei adeiladu, nid beth fydd y rhwydwaith yn ei gario.

Mae darganfod MTU'r llwybr yn bodoli i gymodi'r ddau, ac mae'n dibynnu ar adborth. Gyda IPv4, dylai llwybrydd na all anfon pecyn maint llawn ymlaen anfon neges ICMP "fragmentation needed", ac mae'r anfonydd yn gostwng ei amcangyfrif. Gyda IPv6, y cyfatebol yw neges Packet Too Big, ac nid yw llwybryddion yn darnio o gwbl wrth dramwyo. Pan fydd yr adborth hwnnw'n cael ei hidlo, mae'r anfonydd yn parhau i gynhyrchu pecynnau na all y llwybr eu cario, ac nid oes dim yn dweud wrtho pam.

Myth dau: mae encapsulation yn costio un pennawd

Cyfrwch yr haenau allanol yn onest. Mae pennawd IP allanol yn 20 beit ar gyfer IPv4 neu 40 ar gyfer IPv6. Mae encapsulation UDP ar gyfer tramwyo NAT yn ychwanegu 8. Mae protocol y twnnel yn ychwanegu ei bennawd ei hun, fector cychwyn neu nonce, padio hyd at ffin bloc neu aliniad y seiffr, treiler a gwerth gwirio cyfanrwydd. Yn dibynnu ar y protocol a'r seiffr, mae'r cyfanswm yn gyfforddus yn y degau o feitiau cyn i'r pecyn mewnol hyd yn oed ddechrau.

Yna tynnwch eto ar gyfer pennawdau'r pecyn mewnol ei hun. Mae segment TCP y tu mewn i'r twnnel yn cario ei bennawd IP 20 beit ei hun a'i bennawd TCP 20 beit, ac mae MSS TCP yn deillio o'r MTU, nid o lwyth enwol y twnnel. Dyna pam y gall ping â llwyth llai lwyddo tra bod trosglwyddiad ffeil yn stopio: mae'r offer yn profi pethau gwahanol, a dim ond un ohonynt yn arfer segment TCP maint llawn.

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

Mae'r gorchymyn cyntaf yn adrodd MTU'r twnnel sydd wedi'i ffurfweddu. Mae'r ddau brawf yn anfon llwyth o 1472 beit, sydd gyda 28 beit o benawdau IPv4 ac ICMP yn becyn o 1500 beit, ac yna un llai. Os yw'r prawf mawr yn methu'n llwyr a'r un bach yn llwyddo, mae gennych fai sy'n dibynnu ar faint yn hytrach na phroblem llwybro gyffredinol.

Myth tri: mae PPPoE yn dal i roi 1500 glân i chi

Nid yw dolen fynediad PPPoE confensiynol yn cario pecyn IP o 1500 beit. Mae pennawd PPPoE ynghyd â maes protocol PPP yn bwyta 8 beit y tu mewn i ffrâm Ethernet, sy'n gadael 1492 ar gyfer y pecyn IP. Dyna'r terfyn traddodiadol a ddisgrifir yn RFC 2516. Os rhedwch VPN dros ddolen o'r fath, mae gorbenion y twnnel yn dod o'r 1492 hwnnw, nid o 1500.

Mae RFC 4638 yn diffinio ffordd i drafod llwyth PPP mwy pan fydd y concentrator mynediad a chyfarpar y cwsmer ill dau yn ei gefnogi, a dyna pam nad yw "mae'r cysylltiad hwn yn defnyddio PPPoE" ar ei ben ei hun yn profi rhif penodol. Ni all gosodiad lleol orfodi dyfais ganolradd i dderbyn pecyn na chafodd ei ffurfweddu ar ei gyfer erioed, felly'r cwestiwn defnyddiol yw beth a drafododd y ddolen mewn gwirionedd, nid beth mae'r label yn ei ddweud.

Pam mae'r methiant yn edrych yn ddetholus

Mae ceisiadau bach yn llwyddo a throsglwyddiadau mawr yn stopio yn arwydd clasurol o dwll du MTU llwybr. Mae'r ysgwyd llaw, y cwestiwn DNS a'r alwad API i gyd yn ffitio; mae'r trosglwyddiad swmp yn cynhyrchu segmentau maint llawn sy'n marw ar un ddolen, ac nid yw'r neges ICMP a ddylai fod wedi adrodd y broblem byth yn cyrraedd. Mae'r cysylltiad yn edrych yn iawn ac mae'r lawrlwytho'n hongian, sy'n gwneud i bobl edrych ar y gweinydd yn lle'r llwybr.

Ail gamgymeriad cysylltiedig yw cymysgu tri rhif: MTU'r rhyngwyneb, MSS TCP, a gosodiad darnio neu badio'r protocol ei hun. Mae clampio MSS ar lwybrydd yn ailysgrifennu'r MSS a hysbysebir fel bod yr anfonydd yn adeiladu segmentau llai; nid yw'n newid MTU'r twnnel, ac nid yw'n helpu traffig UDP. Gosod yr un rhif ar y tri am eu bod yn edrych yn gysylltiedig yw sut mae newid bwriad da yn torri sefydliad sy'n gweithio.

Beth i'w newid, ac ym mha drefn

Dechreuwch gyda thystiolaeth. Cadarnhewch gyda'r profion uchod fod y fai yn dibynnu ar faint, yna dewch o hyd i'r maint lleiaf sy'n llwyddo a'r mwyaf sy'n methu. Gwiriwch wir MTU'r ddolen fynediad cyn rhoi'r bai ar y twnnel; mae dolen PPPoE yn capio'r gyllideb cyn i'ch VPN ei chyffwrdd. Cadwch nodyn o'r gwerthoedd gwreiddiol fel y gellir gwrthdroi'r newid.

Yna cymhwyswch yr addasiad lleiaf y mae'r cleient yn ei ddogfennu. Mae llawer o gleientiaid yn cynnig MTU twnnel ynghyd ag opsiwn trwsio MSS, ac mae'r opsiwn MSS yn aml yn y lifer gwell ar gyfer TCP oherwydd ei fod yn cyrraedd yr anfonydd heb grebachu pob pecyn. Ailbrofwch yr un gyrchfan a'r un trosglwyddiad, a chofnodwch y rhifau y setlwyd arnynt. Nid yw gwerth twnnel sy'n gweithio ar un rhwydwaith mynediad yn gysonyn cyffredinol, a bydd gan y safle nesaf ei gyllideb ei hun.