Itinero malakceptita pro gastigantaj bitoj? Trovu la celitan prefikson
Malakceptita itinlinio kutime estas gastigantaj bitoj, ne plusenda problemo. Determinu la prefikson, kiun vi celis, anstataŭ larĝigi la maskon ĝis ĝi akceptiĝos.
Via itinlinio revenas malakceptita, kaj la konsilo, kiun vi trovas, diras ebligi IP-plusendadon. Tiuj du aferoj staras en malsamaj etapoj de la problemo. Plusendado decidas, ĉu gastiganto rajtas movi pakaĵojn inter interfacoj; ĝi ne havas opinion pri tio, ĉu la celloko, kiun vi tajpis, estas valida reto. Riparu unue la prefikson, ĉar plusendado ne savos adreson kaj maskon, kiuj malkongruas.
Pri kio la analizilo efektive plendas
Celloko skribita kiel adreso plus masko devas priskribi reton, kaj reto komenciĝas per nuligitaj gastigantaj bitoj. Kiam la adreso, kiun vi donas, ankoraŭ portas valoron en la gastiganta parto, la paro estas interne nekonsekvenca: 172.20.130.0 aspektas ordema, ĉar ĝi finiĝas per nulo, sed nulo en la kvara okto ne estas la sola grava afero. La tria okto estas tiu, kiu tenas ĉi tie vagantajn bitojn.
Iloj traktas tiun nekonsekvencon malsame. Strikta analiziloj rifuzas la linion kaj nomas gastigantajn bitojn. Indulgaj analiziloj maskas la adreson kaj instalas ion, kion vi ne petis, kio estas pli malbona, ĉar la agordo nun enkursigas gamon, kiun vi neniam intencis. La modulo ipaddress de Python montras la elekton senpere: strikta reta analizado ĵetas eraron, kaj strict=False maskas la gastigantajn bitojn. Via kliento povas esti strikta, indulgema aŭ malkonsekvenca inter versioj, do legu la mesaĝon anstataŭ fidi kutimon.
Pritraktu la ekzemplon permane
Prenu tunelon, kiu devas atingi 172.20.130.0 per /20-masko. /20 pruntas kvar bitojn de la tria okto, do tiu okto kalkuliĝas nur en paŝoj de 16: 0, 16, 32 kaj plu ĝis 240. La valoro 130 falas inter 128 kaj 143, kio signifas, ke la ĉirkaŭanta reto komenciĝas ĉe 172.20.128.0, ne ĉe 172.20.130.0 kun la lasta okto malplenigita.
Skribite, la bloko iras de 172.20.128.0 ĝis 172.20.143.255 kaj tenas 4,096 adresojn. Enigi la samajn valorojn en ne-striktan analizilon montras la anstataŭigon, kiun ĝi farus anstataŭ vi:
$ 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 4096Decidu, kiun cellokon vi efektive celis
La malakceptita linio kutime kaŝas unu el tri intencoj, kaj nur vi povas elekti. Se la tunelo bezonas la tutan blokon, skribu 172.20.128.0/20, la kanonan retadreson. Se la tunelo bezonas nur la segmenton 130, la masko malĝustis kaj 172.20.130.0/24 estas la honesta formo. Se unu maŝino estas la celo, IPv4-gastiganta itinero estas /32 kaj neniu maska aritmetiko implikiĝas.
Ĉiu el ili permesas malsaman kvanton da trafiko, kaj tio estas la vera kialo ne larĝigi la maskon ĝis la plendo ĉesos. /16 akceptas la linion preskaŭ ie ajn kaj sendas trafikon al cellokoj, kiujn vi neniam intencis enkursigi tra la tunelo. Skribu la plej mallarĝan prefikson, kiu kongruas kun la intenco, poste konfirmu ĝin kontraŭ la sekva salto, kiun vi atendas, ne kontraŭ la silento de la analizilo.
Kial plusendado neniam estis la solvo
Malakceptita itinero neniam atingas la plusendan vojon, do ŝalti net.ipv4.ip_forward ne povas ŝanĝi la rezulton. Tiu agordo gravas poste, kiam la gastiganto devas pasigi pakaĵojn inter interfacoj, kaj ŝalti ĝin antaŭ ol la tabelo estas ĝusta nur ŝanĝas, kiu etapo malsukcesos poste.
Du aliaj aferoj ofte kulpiĝas en la sama punkto. La itinero povas esti akceptita kaj tamen perdi al pli specifa itinero, kaj fajroŝirma regulo povas faligi trafikon post ĝusta serĉo. Tenu la etapojn apartaj: sintakso, instalado, elekto, filtrado. Labori ĉe la malĝusta etapo ŝajnas produktiva, ĉar ĉiu ŝanĝo restartigas ion.
Kontrolu la instalitan itinero kaj la vojon, kiun ĝi gajnas
Post kiam la kliento akceptas la linion, rigardu, kion ĝi instalas kaj kiun itinero la kerno elektas por reprezenta adreso ene de la bloko. Se la instalita prefikso diferencas de tio, kion vi skribis, normaligilo agis anstataŭ vi.
Demandu membroadreson same kiel unu ekster la bloko, por ke la komparo havu sencon anstataŭ unu trankviliga linio:
ip -4 route show 172.20.128.0/20
ip -4 route get 172.20.140.10
ip -4 route get 172.20.200.10La tria demando devus fali ekster la tunelo, se via prefikso estas ĝusta, kaj kiam ĝi ne estas, la itinero, kiun vi konstruis, estas pli larĝa ol vi pensas. Notu, kion la prefikso devis kovri antaŭ ol tuŝi la sekvan agordon, ĉar itinero, kiu analiziĝas, kaj vojo, kiu funkcias, restas apartaj observoj.