IPv6-verkeer wat die VPN omseil: vind die lekkende roete

Twee toetsbladsye stem nie ooreen nie: die een rapporteer die verskaffer se adres deur die tonnel, die tweede rapporteer jou huisprefiks, en die voor-die-hand-liggende gevolgtrekking is dat die VPN lek. Daardie gevolgtrekking slaan ’n stap oor, want die twee verslae het twee verskillende roeteringsbesluite uitgeoefen en net een daarvan was veronderstel om die tonnel binne te gaan. Die gaping is gewoonlik werklik, en dit is ’n dekkingsprobleem eerder as ’n stukkende tonnel. Drie vrae beslis dit: watter vloei werklik uitgegaan het, watter roete die kern daarvoor gekies het, en watter gedrag die kliënt bedoel het.

Werk in daardie volgorde. Om hulle uit volgorde te beantwoord lewer ’n lang argument oor of die kliënt foutief is, terwyl die werklike antwoord is dat niks ooit ’n IPv6-roete geïnstalleer het nie.

Watter vloei werklik uitgegaan het, en op watter adapter

Begin met ’n toets wat die familie noem wat dit gebruik het, en skryf dan die toepassing, die toegangsnetwerk, die profiel wat geld en of die verbinding hoegenaamd IPv6 bied neer. Daardie vier feite is wat twee lopies vergelykbaar maak, en die vierde is die een wat mense vergeet: ’n netwerk sonder ’n v6-prefiks kan nie v6 lek nie, en ’n netwerk wat later een byvoeg, verander die antwoord.

Stuur een versoek per familie eerder as om ’n bladsy te laai en die resultaat te lees. ’n Enkele bladsy kan v6- en v4-bronne meng, ’n agtergrondproses kan anders optree as die oortjie voor jou, en ’n gekasde antwoord kan die netwerkverandering wat jy probeer toets, oorleef. Bepaal die bestemming wat jy toets en noteer dit, sodat ’n herhaallopie dieselfde ding meet.

Lees van die roete wat die kern gekies het

Die roetetabel beantwoord die vraag wat die blaaier nie kan nie. Vra die stelsel waar ’n spesifieke bestemming sou heen gaan, en sluit beleidsreëls sowel as die sigbare verstek in, want elkeen kan dit oorheers:

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

’n Meer spesifieke prefiks is die gewone rede waarom een bestemming buite die tonnel sit terwyl alles anders binne bly, en ’n beleidsreël kan dieselfde ding doen teen ’n hoër prioriteit as enige roete. Lees ook die metriek, want twee inskrywings vir dieselfde prefiks word deur metriek beslis eerder as deur hulle volgorde op die skerm. Op Windows is die ekwivalente lys Get-NetRoute -AddressFamily IPv6, gesorteer volgens metriek om by die beslissingsorde te pas. ’n Reël wat in die tabel korrek lyk, kan steeds verloor teen ’n beleidsreël met ’n laer nommer, en daarom hoort die reëllisting in dieselfde asem as die roetelys.

Waar die kliënt se IPv6-beleid vandaan kom

’n Kliënt kan gebou word om v6 deur die tonnel te dra, om dit te weier, of om ’n genoemde uitsondering toe te laat, en daardie drie bedoelings lewer drie verskillende korrekte resultate. Lees die profiel en die kliënt se eie dokumentasie voordat jy ’n waarneming ’n lek noem, want ’n kliënt wat v6 blokkeer terwyl die bedryfstelsel steeds buurontdekking op die fisiese skakel stuur, tree op soos ontwerp.

’n Toepassing wat doelbewus van die tonnel uitgesluit is, is ’n ander geval as ’n familie wat die tonnel nooit gedra het nie. Die eerste is ’n besluit oor een program, die tweede is ’n gaping in dekking, en die herstel verskil dienooreenkomstig. Lees die kliënt se lys van uitgeslote programme voordat jy na ’n roete soek wat nooit bedoel was om te bestaan nie.

Noukeurige waarneming, wanneer die tabel nie ooreenstem nie

Wanneer die roete-opsoek dubbelsinnig is, kan een koppelvlakwaarneming op die gasheer dit besleg, maar net as dit op die vraag gerig is. Verkeer na die VPN-eindpunt self sal per ontwerp die fisiese adapter kruis; wat saak maak, is of die toepassingvloei, wat heeltemal elders geadresseer is, ook daar verskyn. Filter die opname na die bestemming wat jy toets eerder as om alles te versamel.

’n Breë opname stel baie meer persoonlike verkeer bloot as wat die een vraag vereis. Dit beantwoord ook die vraag minder duidelik, want die vloei waaroor jy jou bekommer, kom begrawe in ’n stroom onverwante verbindings aan. Filter na die getoetste bestemming, stop ná ’n handvol pakkette en verwyder die opname.

Drie maniere om die gaping te sluit

Dra die familie deur die tonnel, blokkeer dit by die kliënt wanneer die tonnel dit nie kan dra nie, of teken ’n doelbewuste uitsondering op met ’n eienaar en ’n hersieningsdatum. Elkeen is verdedigbaar, en die een ding wat nie verdedigbaar is nie, is om die keuse implisiet te laat, want ’n implisiete keuse is wat die lek werklik is. As die tonnel glad geen v6-uitgang het nie, is om v6 by die kliënt te weier beide eerlik en toetsbaar. Wat saak maak, is dat die keuse geskryf word waar die volgende persoon dit sal vind, nie ses maande later uit gedrag afgelei nie.

Herhaal die kontrole ná ’n herverbinding en ná beweging tussen netwerke, want ’n roete wat vir die vorige skakel geïnstalleer is, kan die verandering oorleef. Teken dan die bestemming, die gekose roete, die kliëntbeleid en die familie wat die toets gebruik het op, sodat die volgende persoon ’n besluit lees in plaas daarvan om dit weer af te lei. RFC 7359 dokumenteer dubbelstapellekking as ’n ontwerpkwessie eerder as ’n fout, en dit is die verwysing om aan te haal wanneer iemand beweer dat ’n werkende v4-tonnel alles dek.