Minkä IPv6-lähteen VPN-pyyntö valitsee ja miksi sillä on väliä
Monta IPv6-osoitetta omaava isäntä valitsee lähteen ennen reitin hakua. Käy läpi järjestetyt säännöt, mahdollinen sovituksen sidonta ja vastapuolen paluupolitiikka.
Lisäät VPN-osoitteen ja odotit pyynnön käyttävän sitä, mutta palvelin kirjasi yhä vanhaa etuliitettä. Mikään tunnelissa ei epäonnistunut; isäntä teki lähdeosoitteen valinnan ennen kuin se edes katsoi reittiä, jota tuijotit. IPv6-lähteen valinta on erillinen järjestetty kilpailu isännän ehdokasosoitteiden kesken, ja pisimmälle sopiva etuliite on vain yksi sääntö sen loppupäässä. Halutun tuloksen saaminen tarkoittaa tietämistä, mikä sääntö on jo voittanut. Säännöt itsessään ovat tylsiä ja täsmällisiä, ja juuri siksi ne kannattaa lukea järjestyksessä.
Kaksi hakua, ei yksi
Kohteen valinta määrää seuraavan hypyn ja lähtevän rajapinnan. Sen jälkeen lähteen valinta määrää, mikä isännän osoitteista näkyy otsakkeessa, ja näihin kahteen kysymykseen vastaavat eri mekanismit, vaikka molemmat käyttävät etuliitteitä. Isännällä, jolla on fyysinen osoite, väliaikainen osoite ja VPN-osoite, on kolme ehdokasta mille tahansa kohteelle, eikä VPN:tä kohti menevä reitti ehdota kolmatta automaattisesti.
Siksi oikea reitti ja väärä lähde elävät niin helposti rinnakkain, ja siksi sama pyyntö voi käyttäytyä eri tavoin selaimesta ja pakotetusta sidonnasta. Käsittele kahta hakua erillisinä, kunnes sinulla on todiste, joka yhdistää ne.
Lue säännöt järjestettynä kilpailuna
RFC 6724 luettelee säännöt järjestyksessä, ja kukin purkaa vain edellisten jättämän tasapelin. Lähtevän rajapinnan suositus ja tunnisteen täsmääminen tulevat selvästi ennen etuliitteen vertailua, joten reitin käyttämän rajapinnan osoite on jo saanut edun, jota parempi etuliiteosuma ei voi pyyhkiä pois. Myös vanhentuminen ja laajuus osallistuvat, ja siksi vanhentunut osoite lakkaa joskus tulemasta valituksi ilman, että kukaan muuttaa käytäntöä.
Käytännön luenta on, että voittajasta ei voi päätellä pelkän kohteen perusteella. Listaa ehdokkaat, käy säännöt järjestyksessä läpi ja katso, missä päätös oikeasti tehtiin.
Huomaa myös, että tämä on ongelman lähdepuolisko. Kahden etuliitevertailun sekoittaminen tuottaa selityksiä, jotka kuulostavat tiukilta ja ennustavat väärän osoitteen. Sano, mitä vertailua tarkoitat aina kun käytät sanaa etuliite tiketissä.
Sovituksen sidonta muuttaa kysymystä
Sovitus voi pyytää tiettyä lähdeosoitetta, ja kelvollinen nimenomainen valinta siirtää kysymyksen siitä, mitä osoitetta isäntä suosisi, siihen, pääseekö tuo osoite kohteeseen ja takaisin. Työkalut, jotka sitoutuvat lähteeseen tai pyytävät lisätietoja valitusta osoitteesta, paljastavat tämän suoraan, ja ne ovat nopein tapa todistaa, mitä osoitetta yhteys todella käytti. Tämä koe on parempi kuin reititystaulukon kolmas lukeminen, koska se kertoo, mitä ydin päätti, eikä sitä, mitä sinä konfiguroit. Toista se muutoksen jälkeen ja vertaa kahta vastausta.
Tämä tekee lähdesidonnasta sekä diagnostiikkatyökalun että kiertotien: sido VPN-osoite ja seuraa, onnistuuko pyyntö. Jos onnistuu, polku on kunnossa ja valinta oli ongelma. Jos ei, ongelma oli alusta asti paluupolku tai vastapuolen käytäntö.
Varmista, että vastapuoli hyväksyy tuon lähteen
Minkä isäntä valitseekin, sen on sovittava VPN:n suojattuun laajuuteen sekä vastapuolen paluureittiin ja käyttösääntöihin. Valitsimien ulkopuolinen lähde voi matkata tunneliin ja pudota vastapuolella, mikä näyttää yksisuuntaiselta vialta ja vieritetään reitityksen syyksi. Vertaa valittua sisäistä lähdettä suojalaajuuteen ennen kuin kosket salausasetuksiin, koska tilan vaihtaminen ei valitse ehdokasosoitteiden välillä.
Pidä myös ulompi päätepisteosoite erillään päättelyssäsi. Se yksilöi VPN-osapuolten välisen kuljetuksen eikä ole sisällä olevan sovituspaketin lähde.
Päätä neljällä havainnolla
Kirjaa käytetty kohde, kelvolliset paikalliset lähteet, tosiasiassa valittu lähde ja tehollinen lähtevä polku. Neljä riviä riittää selittämään melkein minkä tahansa tapauksen, ja niitä voi verrata toimivan ja vikaantuneen isännän välillä käymättä teoriaa uudelleen läpi. Valintavaiheeseen käytä käyttöjärjestelmän omaa tuettua näkymää äläkä standardin nimeä, koska toteutukset lisäävät omia paikallisia mieltymyksiään.
Kun vastaus yhä yllättää sinut, järjestys tekee jotain, mitä mielikuvasi ei tee, ja korjaus on muuttaa syötteitä eikä väitellä algoritmin kanssa. Kirjoita neljä havaintoa tikettiin, niin seuraava lukija voi toistaa johtopäätöksesi.