Miksi IPv6-naapureiden löytäminen epäonnistuu reititetyn VPN:n yli

IPv6-naapureiden löytäminen kuuluu linkille, ja reititetty tunneli on kahden linkin välinen raja. Yksi lause selittää lähes jokaisen raportin etäisestä isännästä, joka vastaa osoitteensa kautta eikä löydy millään muulla tavalla. Tarkista testattavan osoitteen laajuus ennen kuin tarkistat tunnelin. Linkkikohtainen osoite on mielekäs vain omalla linkillään, ja kysytyn solmun multicast-ryhmä on rajattu samalla tavalla. Kumpikaan ei ylitä reititintä, minkä vuoksi ping yleiseen osoitteeseen voi onnistua, vaikka saman isännän löytäminen ei onnistu.

Laajuus tulee ennen kokoonpanoa

Naapurikysely ja -ilmoitus kantavat 255 hypyn rajan eikä niitä välitetä eteenpäin, suunnittelun mukaan. Tunnelisi ja etäisen LAN-verkon välissä oleva reititin välittää IPv6-paketteja eikä välitä naapuriviestejä sen puolesta. Siksi tunnelin rajapinnan naapurivälimuisti sisältää vastapuolen ja vähän muuta, mikä on oikeaa käytöstä eikä korjattava virhe.

Linkkikohtainen osoite, kuten fe80::-merkintä, on myös vyöhykesidonnainen, ja sama teksti voi nimetä eri isännän eri linkillä. Sellaisen testaaminen tunnelin toiselta puolelta ei todista muuta kuin että osoite on monitulkintainen.

Ansana on olettamus, että etuliite on linkillä

Isäntä, joka uskoo etuliitteen olevan linkillä, lähettää naapurikyselyn sen sijaan, että antaisi paketin reitittimelleen, ja tämä koskee myös etäiselle sivustolle reititettyä /64:ää. Kun tällainen etuliite saapuu linkillä olevana, isäntä kysyy paikalliselta linkiltä isäntää, joka asuu muualla, eikä mikään vastaa. Reititä jotain pienempää etäiselle isännälle tai lopeta etuliite reitittimessä, joka vastaa sen puolesta.

Yhtä palvelua varten /128 on vähiten yllättävä järjestely, ja se poistaa monitulkintaisuuden kokonaan. Naapureiden löytämisen määrittely kuvailee viestijoukon ja linkillä-olemisen lipun, joka ratkaisee tämän.

Sillaus muuttaa sääntöjä tarkoituksella

Kun tunneli kuljettaa Ethernet-kehyksiä, etäinen ja paikallinen segmentti tulevat yhdeksi linkiksi, multicast saavuttaa molemmat puolet ja naapureiden löytäminen käyttäytyy kuin kytkimessä. Seuraukset tulevat mukana: broadcast- ja multicast-tulva, päällekkäisten osoitteiden tunnistus sillan yli ja reitittimen ilmoitukset, jotka vuotavat segmenttiin, jonka ei pitäisi niitä nähdä. Vikatilanteen alue kattaa nyt myös kaksi toimipaikkaa. Mikään tästä ei puhu sillausta vastaan, ja jokainen kohta on syy sillata tarkoituksella eikä sattumalta.

Profiilin vaihtaminen TUN:sta TAP:iin, jotta löytäminen ilmestyisi, on väärä toimintojen järjestys. Palvelimen, asiakkaan ja osoitekaavan on oltava yhtä mieltä, eivätkä mobiiliasiakkaat tarjoa TAP-rajapintaa lainkaan, joten sellainen suunnittelu toimii kannettavassa ja epäonnistuu puhelimessa. Naapurivälityspalvelimet ja -toistimet ovat erillisiä mekanismeja omine vaatimuksineen, ja ne kuuluvat verkonvalvojan dokumentoituun järjestelyyn eivätkä sovelluksen asetuksiin.

Testaa osoitteella, jota sovellus käyttää

Vahvista reitti komennolla ip -6 route get, tarkista naapurimerkintä komennolla ip -6 neigh ja vahvista sitten palvelu reititetyn polun yli. DNS ja paluupolku ovat erillisiä tarkistuksia, eikä terve naapurimerkintä todista kumpaakaan.

Jos sovellus vaatii linkkikohtaista tai löytämiseen perustuvaa kohdetta, se on suunnittelukeskustelu eikä viritysharjoitus, koska mikään asiakasasetus ei saa linkkiin rajattua mekanismia toimimaan reitittimen yli.

Kirjaa, kumpi suunnittelu sinulla on

Kirjaa ennen tapahtumaa, onko ratkaisu reititetty vai sillattu, koska kaksi käyttöönottoa vastaavat näihin kysymyksiin eri tavalla eikä päivystäjän pitäisi päätellä sitä profiilista.

Viestijoukon lukeminen kerran poistaa kiusauksen selittää linkin laajuuden ominaisuus VPN-viaksi, mikä on tämän alueen kallein väärä diagnoosi.