Maršruts noraidīts resursdatora bitu dēļ? Atrodiet paredzēto prefiksu

Jūsu maršruta rinda atgriežas noraidīta, un atrastais padoms saka iespējot IP pārsūtīšanu. Šīs divas lietas ir dažādos problēmas posmos. Pārsūtīšana nosaka, vai resursdators drīkst pārvietot paketes starp saskarnēm; tai nav viedokļa par to, vai ievadītais galamērķis ir derīgs tīkls. Vispirms salabojiet prefiksu, jo pārsūtīšana neglābs adresi un masku, kas nesaskan.

Par ko parseris patiešām sūdzas

Galamērķim, kas rakstīts kā adrese plus maska, jāapraksta tīkls, un tīkls sākas ar nullētiem resursdatora bitiem. Ja norādītā adrese joprojām satur vērtību resursdatora daļā, pāris ir iekšēji pretrunīgs: 172.20.130.0 izskatās kārtīgi, jo beidzas ar nulli, bet nulle ceturtajā oktetā nav vienīgais, kam ir nozīme. Šeit liekos bitus tur tieši trešais oktets.

Rīki šo pretrunu risina dažādi. Stingri parseri noraida rindu un nosauc resursdatora bitus. Maigi parseri maskē adresi un instalē kaut ko tādu, ko jūs neprasījāt, kas ir sliktāk, jo konfigurācija tagad maršrutē diapazonu, kuru jūs nekad neesat paredzējis. Python ipaddress modulis piedāvā izvēli tieši: stingra tīkla parsēšana izraisa kļūdu, un strict=False maskē resursdatora bitus. Jūsu klients var būt stingrs, maigs vai starp versijām nekonsekvents, tāpēc lasiet ziņojumu, nevis paļaujieties uz ieradumu.

Izstrādājiet piemēru ar roku

Ņemiet tuneli, kuram jāsasniedz 172.20.130.0 ar /20 masku. /20 aizņemas četrus bitus no trešā okteta, tāpēc šis oktets tiek skaitīts tikai 16 soļos: 0, 16, 32 un tālāk līdz 240. Vērtība 130 atrodas starp 128 un 143, kas nozīmē, ka aptverošais tīkls sākas ar 172.20.128.0, nevis ar 172.20.130.0 ar nullētu pēdējo oktetu.

Izrakstīts, bloks iet no 172.20.128.0 līdz 172.20.143.255 un satur 4,096 adreses. To pašu vērtību nodošana nestingram parserim parāda aizstāšanu, ko tas būtu veicis jūsu vietā:

$ python3 -c "import ipaddress; n=ipaddress.ip_network('172.20.130.0/20', strict=False); print(n, n.num_addresses)"
172.20.128.0/20 4096

Izlemiet, kuru galamērķi jūs patiešām domājāt

Noraidītā rinda parasti slēpj vienu no trim nodomiem, un izvēlēties varat tikai jūs. Ja tunelim vajadzīgs viss bloks, ierakstiet 172.20.128.0/20, kanonisko tīkla adresi. Ja tunelim vajadzīgs tikai 130 segments, maska bija nepareiza, un 172.20.130.0/24 ir godīgā forma. Ja mērķis ir viena mašīna, IPv4 resursdatora maršruts ir /32 un maskas aritmētika tajā nepiedalās.

Katrs no tiem atļauj citādu trafika apjomu, un tas ir īstais iemesls nepaplašināt masku, līdz sūdzība pārstāj. /16 pieņem rindu gandrīz visur un sūta trafiku uz galamērķiem, kurus jūs nekad neesat gribējis maršrutēt caur tuneli. Ierakstiet šaurāko prefiksu, kas atbilst nodomam, pēc tam apstipriniet to pret nākamo lēcienu, ko gaidāt, nevis pret parsera klusumu.

Kāpēc pārsūtīšana nekad nebija risinājums

Noraidīts maršruts nekad nesasniedz pārsūtīšanas ceļu, tāpēc net.ipv4.ip_forward pārslēgšana nevar mainīt rezultātu. Šis iestatījums ir svarīgs vēlāk, kad resursdatoram jālaiž paketes starp saskarnēm, un tā ieslēgšana pirms tabulas izlabošanas maina tikai to, kurš posms kritīs nākamreiz.

Tajā pašā punktā bieži tiek vainotas vēl divas lietas. Maršrutu var pieņemt, un tas tomēr zaudē konkrētākam maršrutam, un ugunsmūra noteikums var nomest trafiku pēc pareizas meklēšanas. Turiet posmus atsevišķi: sintakse, instalēšana, atlase, filtrēšana. Darbs nepareizajā posmā šķiet produktīvs, jo katra izmaiņa kaut ko pārstartē.

Pārbaudiet instalēto maršrutu un ceļu, kuru tas uzvar

Kad klients ir pieņēmis rindu, apskatiet, ko tas instalēja un kuru maršrutu kodols izvēlas reprezentatīvai adresei bloka iekšienē. Ja instalētais prefikss atšķiras no ierakstītā, jūsu vietā darbojās normalizators.

Pajautājiet dalībnieka adresi un arī vienu ārpus bloka, lai salīdzinājums būtu jēgpilns, nevis viena nomierinoša rinda:

ip -4 route show 172.20.128.0/20
ip -4 route get 172.20.140.10
ip -4 route get 172.20.200.10

Trešajam vaicājumam jāiekrīt ārpus tuneļa, ja jūsu prefikss ir pareizs, un, ja tas neiekrīt, uzbūvētais maršruts ir platāks, nekā domājat. Pierakstiet, ko prefiksam vajadzēja aptvert, pirms pieskaraties nākamajam iestatījumam, jo parsējams maršruts un strādājošs ceļš paliek atsevišķi novērojumi.