IPv6-liikenne VPN:n ohi: vuotavan reitin löytäminen

Kaksi testisivua ovat eri mieltä: toinen ilmoittaa palveluntarjoajan osoitteen tunnelin läpi, toinen ilmoittaa kotiverkkosi etuliitteen, ja ilmeinen johtopäätös on, että VPN vuotaa. Tämä johtopäätös hyppää yhden vaiheen yli, koska kaksi raporttia käytti kahta eri reitityspäätöstä ja vain toisen niistä oli tarkoitus mennä tunneliin. Aukko on yleensä todellinen, ja se on kattavuusongelma eikä rikkinäinen tunneli. Kolme kysymystä ratkaisee sen: mikä virta todella lähti, minkä reitin ydin valitsi sille ja mitä käyttäytymistä asiakas tarkoitti.

Työskentele siinä järjestyksessä. Niihin vastaaminen väärässä järjestyksessä tuottaa pitkän väittelyn siitä, onko asiakas viallinen, kun oikea vastaus on, ettei IPv6-reittiä koskaan asennettu.

Mikä virta todella lähti ja miltä verkkosovittimelta

Aloita testillä, joka nimeää käytetyn perheen, ja kirjaa sitten sovellus, käyttöverkko, voimassa oleva profiili ja se, tarjoaako yhteys ylipäätään IPv6:ta. Nämä neljä tosiasiaa tekevät kahdesta ajosta vertailukelpoisia, ja neljännen ihmiset unohtavat: verkko, jolla ei ole v6-etuliitettä, ei voi vuotaa v6:ta, ja verkko, joka lisää sellaisen myöhemmin, muuttaa vastausta.

Lähetä yksi pyyntö perhettä kohden sen sijaan, että lataat sivun ja luet sen tuloksen. Yksi sivu voi sekoittaa v6- ja v4-resursseja, taustaprosessi voi käyttäytyä eri tavoin kuin edessäsi oleva välilehti, ja välimuistiin tallennettu vastaus voi elää pidempään kuin testaamasi verkkomuutos. Kiinnitä testattava kohde ja kirjaa se, jotta toistettu ajo mittaa samaa asiaa.

Ytimen valitseman reitin lukeminen

Reititystaulu vastaa kysymykseen, johon selain ei pysty. Kysy järjestelmältä, mihin tietty kohde menisi, ja sisällytä sekä käytäntösäännöt että näkyvä oletusreitti, sillä kumpi tahansa voi ohittaa sen:

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

Tarkempi etuliite on tavallinen syy siihen, että yksi kohde jää tunnelin ulkopuolelle, kun kaikki muu pysyy sisällä, ja käytäntösääntö voi tehdä saman korkeammalla prioriteetilla kuin mikään reitti. Lue myös metriikka, sillä kaksi saman etuliitteen merkintää ratkeaa metriikan eikä näytön järjestyksen perusteella. Windowsissa vastaava listaus on Get-NetRoute -AddressFamily IPv6, lajiteltuna metriikan mukaan päätösjärjestyksen mukaisesti. Taulukossa oikealta näyttävä sääntö voi silti hävitä pienemmälle käytäntösäännölle, minkä vuoksi sääntölistaus kuuluu samaan hengenvetoon reittilistauksen kanssa.

Mistä asiakkaan IPv6-käytäntö tulee

Asiakas voidaan rakentaa kuljettamaan v6:ta tunnelin läpi, kieltäytymään siitä tai sallimaan nimetyn poikkeuksen, ja nämä kolme aikomusta tuottavat kolme erilaista oikeaa tulosta. Lue profiili ja asiakkaan oma dokumentaatio ennen kuin kutsut havaintoa vuodoksi, sillä asiakas, joka estää v6:n, kun käyttöjärjestelmä lähettää yhä naapurin löytämistä fyysisellä linkillä, käyttäytyy suunnittelun mukaisesti.

Sovellus, joka on tarkoituksella jätetty tunnelin ulkopuolelle, on eri tapaus kuin perhe, jota tunneli ei koskaan kuljettanut. Ensimmäinen on päätös yhdestä ohjelmasta, toinen on aukko kattavuudessa, ja korjaus eroaa vastaavasti. Lue asiakkaan luettelo pois suljetuista ohjelmista ennen kuin etsit reittiä, jota ei ollut tarkoitus koskaan olla olemassa.

Kapea havainnointi, kun taulukko on eri mieltä

Kun reittihaku on monitulkintainen, yksi liitäntähavainto isännällä voi ratkaista sen, mutta vain jos se kohdistuu kysymykseen. Liikenne itse VPN-päätepisteeseen ylittää fyysisen sovittimen suunnittelun mukaan; ratkaisevaa on, näkyykö myös sovellusvirta, joka on osoitettu aivan muualle, siellä. Suodata kaappaus testattavaan kohteeseen sen sijaan, että keräisit kaiken.

Laaja kaappaus paljastaa paljon enemmän henkilökohtaista liikennettä kuin yksi kysymys vaatii. Se myös vastaa kysymykseen epäselvemmin, koska sinua kiinnostava virta saapuu hautautuneena asiaankuulumattomien yhteyksien virtaan. Suodata testattuun kohteeseen, pysähdy muutaman paketin jälkeen ja poista kaappaus.

Kolme tapaa sulkea aukko

Kuljeta perhe tunnelin läpi, estä se asiakkaassa, kun tunneli ei voi kuljettaa sitä, tai kirjaa tarkoituksellinen poikkeus omistajan ja tarkistuspäivän kanssa. Jokainen on puolustettavissa, ja ainoa, mitä ei voi puolustaa, on jättää valinta implisiittiseksi, sillä implisiittinen valinta on juuri se, mitä vuoto on. Jos tunnelissa ei ole lainkaan v6-uloskäyntiä, v6:n kieltäminen asiakkaassa on sekä rehellistä että testattavaa. Ratkaisevaa on, että valinta on kirjoitettu sinne, mistä seuraava ihminen sen löytää, ei päätelty käyttäytymisestä kuusi kuukautta myöhemmin.

Toista tarkistus uudelleenyhdistämisen jälkeen ja verkkojen välillä siirtymisen jälkeen, sillä edelliselle linkille asennettu reitti voi säilyä muutoksen yli. Kirjaa sitten kohde, valittu reitti, asiakkaan käytäntö ja testin käyttämä perhe, jotta seuraava ihminen lukee päätöksen sen sijaan, että johtaisi sen uudelleen. RFC 7359 dokumentoi kaksoispinon vuodon suunnitteluongelmana eikä vikana, ja se on viite, johon vedotaan, kun joku väittää toimivan v4-tunnelin kattavan kaiken.