IPIP WireGuard iekšienē: tie papildu 20 baiti, ko neviens neiekļāva budžetā
IPIP WireGuard iekšienē izmaksā 20 baitus vairāk. Veidojiet budžetu pareizajā slānī, pirms vainojat fragmentāciju par iesprūdušu pārsūtīšanu dzīvā tunelī.
Mazi pingi visu dienu šķērso tuneli, pienāk SSH baneris, un tad sesija sasalst tajā brīdī, kad sākas faila pārsūtīšana. Šis modelis norāda uz baitu budžetu, kas skaitīts nepareizajā slānī, kur ārējais tunelis tika mērīts pēc savām pašizmaksām un neviens neatņēma iekšējo. Iekļautais IPIP pakets WireGuard ir tikai vēl viens IP pakets, un tieši tāpēc tas patērē baitus, kurus jūs nekad nebijāt rezervējis. Labojums ir aritmētika, un tas ietilpst trīs komandās un vienā tabulā.
Simptoms, kas to atklāj
Fragmentācijas problēmas paziņo sevi ar izmēru, nekad ar adresēm. Jūsu partneris stundu atbild uz 56 baitu ping un pēc tam apklust pie 1400 baitiem, kamēr tunelis paliek pacelts un neviens maršruts nav mainījies. Rokasspiediens ietilpst, pirmais pilnais TCP logs ne, un pārsūtīšana apstājas dažas sekundes pēc tam, kad tā izskatījās vesela.
Izmēriet griestus, pirms kaut ko rediģējat, jo neizmērīti griesti ir tie, pēc kuriem dzīsities divreiz. Nosūtiet vienu zondi zem aizdomīgā izmēra ar iestatītu do-not-fragment bitu, ping -M do -s 1000 10.9.0.2, pēc tam atkārtojiet to izmērā, par kuru jau zināt, ka tas ir pārāk liels. Kad apvērsums seko lietderīgās kravas izmēram, bet galamērķis paliek nemainīgs, maršrutēšana dara savu darbu, un budžetā trūkst vienas galvenes.
Skaitiet katru galveni vienreiz, pareizajā slānī
Sāciet no mazākā MTU ceļā, nevis no tuneļa saskarnes, jo siena atrodas augšpus abiem galiem. WireGuard iztērē 60 baitus ārējam IPv4 transportam: 20 IP, 8 UDP un 32 savai galvenei, un 80 baitus, kad šis transports ir IPv6. 1420 baitu wg0 patur 20 baitu rezervi zem 1440, ko 1500 baitu ceļš patiešām var piegādāt, un tāpēc no viki nokopētais skaitlis šeit joprojām der. Uzzīmējiet visu steku diagrammā, jo nākamais MTU mainītājs citādi izvēlēsies jaunu apaļu skaitli un mantos jūsu kļūdu.
| Layer | Bytes | Remaining |
|---|---|---|
| Path MTU on the wired link | none yet | 1500 |
| WireGuard outer: IP, UDP, WG header | 60 | 1440 |
| Slack kept for safety | 20 | 1420 (wg0) |
| IPIP header inside the tunnel | 20 | 1400 (ipip0) |
| Original IPv4 and TCP headers | 40 | 1360 payload |
Piektā rinda ir vieta, kur budžeti sabrūk, jo 1400 baiti, ko nes iekļautā saskarne, jau ietver pašas oriģinālā paketa 40 baitu galvenes. Tikai 1360 no šiem baitiem sasniedz failu lasošo procesu. Uzskatiet 1400 par lietojumprogrammas lietderīgo kravu, kā aicina jebkura diagramma bez šīs kolonnas, un iekšējā ierīce beigās ir 40 baitus pārāk dāsna pret sienu, kas nav pakustējusies.
Iestatiet abus MTU atsevišķi
Nesējs un iekļautā ierīce ir atsevišķi objekti, tāpēc katram vajadzīga sava vērtība. Piemērojiet tos šādā secībā, jo iekļautā ierīce neko nemanto no nesēja:
ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400
Noteikums, ko vērts iegaumēt: iekšējais MTU = ārējais MTU - 20, kad pakets, ko nes IPIP tunelis, ir IPv4, un - 40, tiklīdz kāda iekšējā paketa puse ir IPv6, jo iekļautā galvene aug no 20 baitiem līdz 40. Nekas cits šajā atņemšanā neietilpst. WireGuard izmaksas jau tika iztērētas, kad izvēlējāties 1420, un to iekasēšana divreiz rada tuneli, kas darbojas nevainojami un paliek lēns, kamēr vien neviens to nemēra. Izvietojums, kurā abas ierīces nes apaļu 1400, ir tieši šīs kļūdas pirkstu nospiedums.
IPv6 jebkurā iekļautā paketa pusē atceļ katru iepriekš minēto skaitli, tāpēc pārrēķiniet, nevis kopējiet skaitli no līdzīgas vietnes. Atņemtās galvenes ir 40 baitu katra, tiklīdz IPv6 parādās ārējā ceļā vai oriģinālajā datagrammā, un lietderīgās kravas skaitlis samazinās tieši par tik.
Ugunsmūra noteikums, kas jums, iespējams, nav vajadzīgs
Starp diviem WireGuard partneriem vienīgais uz vada ir UDP, tāpēc ienākošais noteikums 4. protokolam, numuram, ko RFC 2003 piešķir IPv4-IPv4 iekapsulēšanai, ne rada iekļauto ceļu, ne uztur to dzīvu. IPIP galvene dzīvo šifrētajā lietderīgajā kravā, kur to neredz neviens malas ugunsmūris. 4. protokola atvēršana tomēr neko nepērk, izņemot vēl vienu atļautu ceļu uz resursdatoru.
Politika, kas piemin oriģinālā paketa avotus un galamērķus, pieder pēc dekapsulācijas, tuneļa saskarnēs un maršrutēšanas tabulā. Ielieciet to tur, un malas noteikums var palikt slēgts.
Ko WireGuard faktiski validē
AllowedIPs spriež par WireGuard nestā paketa avotu, un tas, ko tas nes, ir IPIP iekapsulētais pakets. Atļautais IPIP avots tiek pieņemts pat tad, ja iekšējā galvene nosauc resursdatoru, uz kuru jūs labprātāk nevirzītu. Tāpēc oriģinālais avots nav tas, ko partneris pārbaudīja jūsu vietā, un šim iekšējam adrešu pārim pēc dekapsulācijas vajadzīga sava izpilde.
Ietinējs nodrošina maršrutēšanas struktūru, nevis otru kriptogrāfijas slāni. IPIP saukšana par papildu aizsardzību WireGuard iekšienē apraksta citu dizainu.
Pārbaudiet ar kāpnēm, nevis vienu ping
Pārbaudiet izmērus, kas aptver aprēķināto robežu, pēc tam apstipriniet, ko kodols domā par abām ierīcēm. Kad 1360 baiti lietderīgās kravas plus 40 baitu galvenes veido 1400, pirmā atbalss zemāk ietilpst, bet otrā sēž vienu baitu aiz griestiem:
ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0
Tīra pāreja zem griestiem un neveiksme pirmajā izmērā virs tiem nozīmē, ka aritmētika notur no gala līdz galam. Pēc tam atkārtoti palaidiet pārsūtīšanu, kas sākotnēji iesprūda, jo sintētiskā zonde pierāda budžetu un neko nepasaka par sūtītāja pašu rakstīšanas izmēriem. Ja iekļautais ceļš joprojām lūzt tādā izmērā, kuru jūs pierādījāt, ka tas ietilpst, pārbaudiet tālā gala dekapsulāciju un maršrutus, pirms nogriežat vēl desmit baitus no MTU.