Oman /64:n jakaminen ei reititä IPv6-liikennettä VPN-asiakkaille

Asiakas näyttää julkisen IPv6-osoitteen, kättely on valmis, eikä internetistä tule mitään takaisin. Poolin asetus näyttää oikealta, koska se on oikea; osoite on kelvollinen ja tunneli kuljettaa sitä. Epäonnistuva asia on toimitus, ja toimitus riippuu päätöksestä, joka on tehty VPN-palvelimen yläpuolella ja johon mikään asiakaspään asetus ei voi vaikuttaa.

Myytti: pala /64:stäsi on jo saavutettavissa

Tarina on houkutteleva: palvelimella on julkinen /64, leikkaa se kahtia, anna toinen puoli VPN-poolille, ja ne asiakkaat ovat nyt internetissä. Etuliitteen jakaminen todella jakaa osoitteita ilman törmäyksiä. Se ei kuitenkaan muuta sitä, miten ylävirran verkko päättää, mihin yhdelle näistä osoitteista osoitettu paketti menee.

IPv6:lla ei ole oletuskäännöskerrosta, johon nojata, joten paluupolun on oltava olemassa reitityksenä tai linkkitason toimituksena. Asiakkaan tunneliosoitteeseen osoitettu paketti saapuu ylävirran reitittimelle, ja tämä reititin tekee edelleenlähetyspäätöksen omasta taulustaan. Jos taulu osoittaa fyysiseen linkkiin, paketti menee sinne riippumatta siitä, mitä VPN-palvelimesi uskoo.

Se on koko vika: eteenpäin suunta toimii, koska palvelimesi lähettää sen, ja paluusuunta kuolee yhden hypyn päässä, koska ylävirta ei koskaan oppinut, että asiakas on olemassa.

Mitä linkillä toimittaminen todella vaatii

Kun ylävirta pitää koko /64:ää fyysisellä linkillä olevana, se ratkaisee jokaisen kohdeosoitteen naapureiden löytämisellä. Se lähettää pyynnön kyseiselle linkille ja odottaa, että osoitteen omistaja vastaa. Tunnelissa oleva VPN-asiakas ei ole kyseisellä linkillä eikä voi vastata, joten pyyntö jää vastaamatta ja paketti pudotetaan.

/65:n leikkaaminen ei muuta tätä odotusta. Ylävirta kohtelee aluetta edelleen linkillä olevana, koska ainoa asia, joka muuttaisi sen mielen, on reitti tai välityspalvelin, joka vastaa asiakkaan puolesta. Kumpikaan ei ilmesty, koska muokkasit VPN-asetuksia. Juuri tämä aukko selittää, miksi pooli voi toimia täydellisesti omien asiakkaidensa välillä ja olla silti saavuttamaton kaikkialta muualta.

Välityspalvelimen naapureiden löytäminen on mekanismi, joka voi yhdistää kaksi maailmaa. Yhdyskäytävä vastaa pyyntöihin niistä tietyistä asiakasosoitteista, jotka se omistaa, ja välittää liikenteen tunneliin. Se toimii, ja se on rajattava täsmälleen näihin osoitteisiin elinkaarella, joka seuraa poolia, koska sellaisen osoitteen puolesta vastaaminen, jota et enää palvele, muuttaa jonkun muun liikenteen mustaksi aukoksi. Jotkut ylävirrat eivät hyväksy välityspalvelinvastauksia, joita ne eivät odottaneet, joten tämä suunnittelu tarvitsee myös palveluntarjoajan suostumuksen.

Mitä reititetty toimitus vaatii

Siistimpi suunnittelu on allokaatio, jonka ylävirta todella reitittää yhdyskäytävällesi. Se voi olla delegoitu etuliite tai staattinen reitti pienemmälle lohkolle, ja vaatimus on sama kummassakin tapauksessa: ylävirran taulun on osoitettava palvelimeesi asiakasalueen osalta. Sitten paluuliikenne saapuu yhdyskäytävälle ja yhdyskäytävä välittää sen tunneliin.

Reititetty toimitus poistaa naapureiden löytämisen kysymyksen kokonaan, minkä vuoksi se kannattaa pyytää palveluntarjoajalta ennen kuin rakentaa mitään nerokasta. Pyydä reitti kirjallisesti ja varmista, että seuraava hyppy on osoite, johon ylävirta todella yltää.

Molemmat suunnitelmat tarvitsevat edelleen IPv6-edelleenlähetyksen käyttöön yhdyskäytävällä ja palomuurisäännöt, jotka sallivat välitetyn virran molempiin suuntiin. Toimitus on edellytys, ei korvike, loppumatkalle. Toimiva reitti, jonka edelleenlähetys on pois päältä, tuottaa täsmälleen saman hiljaisuuden kuin puuttuva reitti, joten tarkista molemmat ennen kuin suunnittelet mitään uudelleen.

Kaksi itsenäistä reittiä, jotka on saatava oikein

Poolin etuliite ja asiakkaan oma oletusreitti ovat erillisiä asetuksia, ja niiden sekoittaminen tuottaa osittaisen yhteyden, joka näyttää rikkinäiseltä tunnelilta. Pooli kertoo palvelimelle, mitkä osoitteet jaetaan. Asiakkaan reitit päättävät, mihin kohteisiin asiakas ylipäätään lähettää liikennettä tunneliin.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

Yllä oleva etuliite on dokumentaatiotilaa, ja uudelleenohjaus koskee vain IPv6:ta, mikä on juuri se, mitä kaksoispinon käyttöönotto usein haluaa, kun IPv6-toimitusta vielä korjataan. IPv4-uudelleenohjaus ei luo IPv6-kattavuutta, eikä kumpikaan asetus edellytä toista.

Pidä IPv6:n tarvitsema ohjausliikenne toimivana riippumatta siitä, mitä käytäntöä sovellat. Packet Too Big -viestit ovat klassinen uhri palomuurista, joka sallii vain TCP:n ja UDP:n, ja niiden pudottaminen tuottaa yhteyksiä, jotka muodostuvat ja sitten pysähtyvät suuremmissa siirroissa.

Reitittimen ilmoitukset ovat kolmas liikkuva osa. Jos yhdyskäytävä alkaa ilmoittaa ylälinkillä, se voi muuttaa sitä, mitä asiakkaat ja naapurit uskovat linkin etuliitteistä, mikä voi hiljaa kumota juuri dokumentoimasi suunnittelun.

Kirjaa suunnittelu, jotta uudelleenrakennus toistaa sen

Kirjoita kolme kohdetta erikseen: asiakkaan allokaatio, asiakkaan kohdereitti ja ylävirran toimitustapa allokaatiolle. Lukija, jolla on kaikki kolme, voi rakentaa käyttöönoton uudelleen; lukija, jolla on vain poolin asetus, toistaa alkuperäisen virheen.

Testaa sitten paluusuunta nimenomaisesti paketilla, jonka on tultava takaisin ulkopuolelta. openvpn(8)-käsikirja kattaa asetukset server-ipv6 ja redirect, ja palveluntarjoajasi reititysvahvistus kattaa sen puolen, jota käsikirja ei voi.