Miks IPv6 naabrite avastamine läbi marsruuditud VPN-i ei toimi

IPv6 naabrite avastamine kuulub lingi juurde ja marsruuditud tunnel on kahe lingi vaheline piir. See üks lause seletab peaaegu iga raportit kaugest hostist, mis vastab aadressi järgi ja mida ei leia mitte millegi muuga. Enne tunnelit kontrolli selle aadressi ulatust, mida testid. Lingil kohalik aadress on mõttekas ainult oma lingil ja küsitud sõlme multicast-grupp on samamoodi piiratud. Kumbki ei ületa marsruuterit, mistõttu võib ping globaalsele aadressile õnnestuda, samal ajal kui sama hosti avastamine ei toimi.

Ulatus tuleb enne seadistust

Naabripäring ja naabriteade kannavad hüppe piirangut 255 ning neid ei edastata, projekteeritult. Marsruuter sinu tunneli ja kaugema LAN-i vahel edastab IPv6 pakette ega vahenda naabriteateid selle nimel. Nii sisaldab tunneli liidese naabrite vahemälu partnerit ja vähe muud, mis on õige käitumine, mitte parandamist vajav defekt.

Lingil kohalik aadress, näiteks kirje fe80::, on samuti tsooniulatusega ja sama tekst võib teisel lingil tähistada teist hosti. Selle testimine tunneli teiselt poolt ei tõesta muud, kui et aadress on mitmetähenduslik.

Lõks on eeldus, et prefiks on lingil

Host, kes usub, et prefiks on lingil, saadab naabripäringu selle asemel, et pakett oma marsruuterile anda, ja see hõlmab kaugesse kohta marsruuditud /64-t. Kui selline prefiks saabub lingil olevana, küsib host kohalikult lingilt hosti, kes elab mujal, ja mitte keegi ei vasta. Marsruudi kaugemale hostile midagi väiksemat või lõpeta prefiks marsruuteril, mis selle eest vastab.

/128 ühe teenuse jaoks on kõige vähem üllatav lahendus ja see kõrvaldab mitmetähenduslikkuse täielikult. Naabrite avastamise spetsifikatsioon kirjeldab sõnumite kogumit ja lingil-oleku lippu, mis selle otsustab.

Sildamine muudab reegleid meelega

Kui tunnel kannab Etherneti kaadreid, saavad kaugemast ja kohalikust segmendist üks link, multicast jõuab mõlemale poole ja naabrite avastamine käitub nagu kommutaatoril. Tagajärjed tulevad koos sellega: broadcast- ja multicast-üleujutus, duplikaatadresside tuvastamine üle silla ja marsruuteri teated, mis lekivad segmenti, mis neid näha ei tohiks. Rikke domeen hõlmab nüüd kahte asukohta. Miski sellest ei ole sildamise vastuargument ja iga punkt on põhjus sildata meelega, mitte juhuslikult.

Profiili vahetamine TUN-ilt TAP-ile, et avastamine ilmuma hakkaks, on vale toimingute järjekord. Server, klient ja aadressiplaan peavad ühtima ning mobiilikliendid ei paku TAP-liidest üldse, seega selline lahendus töötab sülearvutis ja ebaõnnestub telefonis. Naabriproxy'd ja naabrireleed on eraldi mehhanismid oma nõuetega ning kuuluvad võrguadministraatori dokumenteeritud korraldusse, mitte rakenduse seadetesse.

Testi aadressiga, mida rakendus kasutab

Kinnita marsruut käsuga ip -6 route get, vaata naabrikirjet käsuga ip -6 neigh ja seejärel kinnita teenus marsruuditud teel. DNS ja tagasitee on eraldi kontrollid ning terve naabrikirje ei tõesta kumbagi.

Kui rakendus nõuab lingil kohalikku või avastamisel põhinevat sihtkohta, on see projekteerimisvestlus, mitte häälestusharjutus, sest ükski kliendiseade ei tee lingiga piiratud mehhanismi marsruuteri kaudu toimivaks.

Kirjuta üles, milline projekt sul on

Märgi enne juhtumit, kas lahendus on marsruuditud või sildatud, sest kaks juurutust vastavad neile küsimustele erinevalt ja valves olev insener ei peaks seda profiilist tuletama.

Sõnumite kogumi üks lugemine eemaldab kiusatuse seletada lingiulatuse omadust VPN-i veana, mis on selles valdkonnas kõige kallim vale diagnoos.