IPv6 link-local ne deluje prek VPN: zakaj se fe80 ustavi na povezavi

Dvignete tunel, pingate fe80::1 s tunelom kot izvornim vmesnikom in nič se ne vrne. To ni pozabljeno pravilo požarnega zidu. Naslov link-local ima pomen samo na tisti eni povezavi, kjer je nastal, usmerjeni VPN pa ni ta povezava. fe80::1 oddaljenega usmerjevalnika živi v oddaljenem segmentu LAN; vi sedite en skok stran v drugem segmentu, IPv6 pa sploh nima mehanizma, s katerim bi usmerjevalnik posredoval pakete link-local.

Predpona fe80 opisuje obseg, ne razpona

Link-local unicast je fe80::/10, odločilna lastnost pa ni število, ampak obseg. Naslov velja samo na eni povezavi in vsak vmesnik oblikuje enega iz svojega identifikatorja, zato lahko dva nepovezana stroja v dveh nepovezanih omrežjih oba odgovorita na fe80::1 brez najmanjšega konflikta. Predpona v bistvu pravi „na neki povezavi“; povezava sama pride iz konteksta.

Na gostitelju je ta kontekst območje ali scope ID, ki ga dodate za znakom za odstotek: fe80::1%eth0 v Linuxu, fe80::1%3 ali fe80::1%12 v Windows in v orodjih, ki prikazujejo indekse vmesnikov. Jedro naslov razreši skupaj z indeksom vmesnika in nato pošlje. Če območje odstranite, je cilj dvoumen, zato sklad nima načina, da bi izbral segment.

Zakaj usmerjeni tunel tega ne more dostaviti

Usmerjeni VPN je vmesnik od točke do točke, ki nosi lastne naslove, običajno /64 prostora IPv6 unique-local ali zasebnega v tunelu. Oddaljeni LAN je ločena povezava, do katere pride končna točka tunela z usmerjanjem in posredovanjem v vašem imenu. To sta dva različna segmenta, zato naslov iz enega ni veljaven cilj v drugem.

Pravilo posredovanja je izrecno v standardu in ni posebnost vašega odjemalca: usmerjevalniki ne posredujejo paketov z link-local izvorom ali ciljem. Zato paket umre tudi, ko je usmerjevalna tabela videti pravilna. Če dodate pot za fe80::/64 proti tunelu, bo sklad v skladu s standardom pot zavrnil ali pa jo sprejel in zavrgel vsak ustrezni paket: obseg cilja pravi „samo ta povezava“, odhodni vmesnik pa ni ta povezava.

Odkrivanje sosedov krepi isto mejo. Gostitelji razrešujejo link-local naslednje skoke z zahtevo za soseda, poslano na multicast z obsegom povezave in omejitvijo skoka 255, zato lahko usmerjevalniki zavrnejo vse posredovano. Če bi to delovalo prek tunela, bi pomenilo posredovanje odkrivanja za oddaljeni segment, kar je most Layer 2 v drugem klobuku.

Obstaja tišja druga napaka in ujame ljudi, ki pot vseeno poskušajo vsiliti: območje. Katero koli območje vnesete lokalno, poimenuje vmesnik tunela, medtem ko je naslov, ki ga želite, vezan na vmesnik oddaljenega LAN. Ta dva se nikoli ne ujemata, zato paketa ni mogoče usmeriti na pravi vmesnik na oddaljenem koncu.

Kako napaka izgleda v praksi

Izhod orodja za napako obsega se bere kot napaka usmerjanja ali požarnega zidu, in prav zato ljudje preživijo popoldne v napačnem sloju.

Tretja vrstica porabi največ časa, ker je odjemalec ssh brez izhoda videti kot težava s storitvijo, ki posluša. Če imate kakršen koli način za vstop, preverite oddaljeno stran in potrdite, ali je sshd vezan na vse naslove ali samo na enega.

Uporabite naslov, ki je bil namenjen usmerjanju

Za vse, do česar morate priti skozi tunel, uporabite naslov, ki ga je storitev dobila prav v ta namen: globalni naslov unicast ali naslov unique-local iz fc00::/7, obseg, rezerviran prav za ta notranji primer. Potrdite, da ga poslušalec res veže, in preverite povratno pot ter vsako pravilo požarnega zidu gostitelja.

Poglejte oddaljenega gostitelja, namesto da ugibate. ip -6 addr show našteje obstoječe naslove, ss -6 -ltn pa našteje, kaj posluša demon. Storitev, vezana samo na fe80::, je dosegljiva samo iz lastnega segmenta, kar je običajno privzeta vrednost, ki je nihče ni izbral namenoma in jo je mogoče spremeniti s soglasjem skrbnika.

Ko storitve res ni mogoče znova vezati, premaknite most na aplikacijski sloj namesto na omrežnega. Posrednik na oddaljenem gostitelju, ki posluša na usmerljivem naslovu in se poveže z link-local, reši težavo brez razširitve katerega koli segmenta:

socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80

Tu območje sedi na pravi strani, na gostitelju, ki res ima eth0 na tej povezavi. Vaš odjemalec govori z fd00:1:2::10, ki se usmerja normalno, posrednik pa izvede link-local skok lokalno. Ista zvijača deluje za spletni vmesnik naprave ali star BMC, ki oglašuje samo naslov link-local.

Kdaj je mostenje res odgovor, in kaj preveriti

Nekatere namestitve res potrebujejo en skupni segment: napravo, ki govori samo odkrivanje link-local, aparat, odvisen od multicast, laboratorij, ki poustvari ravni LAN. To je težava Layer 2 in zahteva odgovor Layer 2, na primer napravo tap, premosteno na oddaljeni vmesnik, ali odjemalski izdelek z izrecnim mostnim načinom. Stane vas promet broadcast in multicast, ki prečka tunel, plus odkrivanje sosedov, ki mora delovati od konca do konca.

Temu se ne približujte z dodajanjem fe80::/64 usmerjenemu profilu. To ustvari najslabše stanje: konfiguracija je videti končana, usmerjevalna tabela prikazuje vnos, vsak paket pa se še vedno zavrže nekje med dvema skladoma, ki se oba obnašata pravilno.

Preverite z vmesnikom, ne s pingom. ip -6 addr show tun0 pove, ali je povezava tunela oblikovala lasten naslov link-local, ip -6 route get fe80::1%tun0 pa pove, kaj bi jedro v resnici naredilo s ciljem z obsegom. Ko jedro pravi, da je cilj na tem vmesniku nedosegljiv, nobena nastavitev tunela tega ne bo spremenila, in čas je, da prenehate urejati profil.

Kratko zaporedje, ki reši vprašanje:

• Preberite naslov na oddaljenem gostitelju in opazite, ali je fe80:: ali usmerljiva predpona.
• Če je fe80::, znova vežite storitev, naredite posrednika na tem gostitelju ali premostite segment; če je usmerljiv, popravite pot, požarni zid ali naslov vezave.
• Območje preverite vsakič, ko znova testirate, ker kopirani ukaz običajno obdrži napačen vmesnik.

Viri: RFC 4291, arhitektura naslavljanja IPv6.