IPv6 deaktiveer om 'n VPN-lek reg te maak? Besluit eerder oor die beleid
'n Skakel-plaaslike adres is nie 'n lek nie, en 'n globale IPv6-roete is ook nie een nie. Kies eers tussen blokkeer, dra en los.
'n Adres uit die IPv6-reeks verskyn op 'n toetsblad, die tonnel dra dit duidelik nie, en die internet se gewildste advies is om IPv6 oral te deaktiveer. Daardie opdrag maak die paneel wel stil. Dit verwyder ook 'n protokol waarop die toegangsnetwerk kan staatmaak, en dit laat jou sonder enige idee of die adres 'n werklike lek was, 'n skakel-plaaslike koppelvlakadres, of 'n oplosser wat sy werk doen. Drie toestande bepaal die regte beheer, en net een daarvan lei tot blokkering.
Identifiseer wat die instrument werklik gemeet het
Die mees algemene vals alarm is 'n skakel-plaaslike adres, wat met fe80: begin en op elke IPv6-geskikte koppelvlak bestaan, of die masjien nou oor IPv6 die internet kan bereik of nie. Dit verskyn in koppelvlaklyste en in sommige toepassingsdiagnostiek, en dit se niks oor jou verkeersroete nie.
Die tweede vals alarm is 'n unieke plaaslike adres in fc00::/7, wat 'n private reeks is wat binne 'n netwerk gebruik word. 'n Instrument wat elke adres wat die gasheer het uitdruk, sal dit graag langs die publieke een lys. Enigiemand wat vinnig lees, noem dit 'n lek en spandeer dan 'n uur aan 'n probleem wat nie bestaan nie.
Die derde is glad nie 'n vals alarm nie. 'n Globale adres wat die internet buite die tonnel bereik, is die werklike lek, en dit is die moeite werd om dit te meet voordat jy enigiets besluit:
ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.coAs die eerste opdrag 'n globale adres uitdruk en die derde gee 'n publieke IPv6-adres terug wat nie die tonnel se een is nie, het jy 'n werklike roete buite die tonnel. As die eerste niks behalwe skakel-plaaslike inskrywings uitdruk, was daar nooit 'n lek om reg te maak nie.
Drie toestande bepaal die beheer
Die besluit is nie "IPv6 goed" of "IPv6 sleg" nie. Dit is in watter van drie situasies jy is, en elkeen het 'n ander korrekte antwoord met 'n ander koste as jy dit verkeerd kry.
| Situation | Correct control | Cost if you disable IPv6 instead |
|---|---|---|
| Exit has no IPv6, host does | Block IPv6 deliberately in the tunnel policy | Same visible result, no documentation of intent |
| Exit carries IPv6, host leaks | Route IPv6 into the tunnel and verify | You lose IPv6 reachability entirely |
| Access network is IPv6-only | Change nothing; use the tunnel's IPv6 | Machine loses connectivity completely |
Die eerste ry is wat mense gewoonlik bedoel, en dit is wettig. 'n Kliënt wie se uitgang geen IPv6-steun het nie, moet nie die gasheer se eie IPv6-verkeer stilweg laat uitgaan nie, want dit is die gedokumenteerde dubbelstapel-lek. Die punt is om dit as 'n verklaarde beleid te blokkeer, nie om 'n protokol by die kern te deaktiveer nie. Die sigbare uitkoms is identies en net een van hulle kan later nagesien word.
Die derde ry is waar die algemene advies aktief skadelik word. Mobiele operateurs en sommige tuisverbindings bedryf IPv6-only netwerke met vertaling vir IPv4-bestemmings. Verwyder IPv6 daar en jy verwyder die enigste vervoer wat die netwerk bied, wat 'n veel erger onderbreking veroorsaak as die een wat jy ontfout het.
As die uitgang geen IPv6 het nie, blokkeer dit doelbewus
Verkies die kliënt se eie meganisme, want dit geld presies terwyl die tonnel op is en keer terug wanneer dit afgaan. OpenVPN het 'n opsie hiervoor, en iptables het 'n ekwivalente reël vir ander kliënte:
block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachableDie richtlijn hoort in die profiel; die reël hoort in 'n vuurmuur wat jy kan nagaan en verwyder. Beide faal geslote, wat is wat jy wil hê, en beide is sigbaar in 'n konfigurasie-diff, wat 'n kern-sysctl wat in 'n opstartskrip begrawe is, nie is nie.
Teken aan waarom dit daar is. 'n Blokkeerreël sonder kommentaar word verwyder deur die volgende persoon wat IPv6 vir iets anders nodig het, en dan keer die lek stilweg terug.
As die uitgang IPv6 dra, roete dit en toets beide families
Om IPv6 te dra is die beter antwoord wanneer die bediener dit ondersteun, en dit is nie veel moeiliker nie. Die vereiste is dat die tonnelkoppelvlak 'n adres in daardie familie het en dat die verstekroete daarvoor in die tonnel in wys eerder as uit die fisiese koppelvlak:
ip -6 route get 2606:4700:4700::1111
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
curl -4 -sS --max-time 6 https://ifconfig.coDie roete-opsoek is die deurslaggewende toets: as dit die tonnelkoppelvlak noem, word IPv6-verkeer gedra. Die twee curl-oproepe bevestig dan wat elke familie sien, en om hulle te vergelyk is hoe jy bewys dat beide roetes nou by dieselfde uitgang uitgaan.
Moenie by 'n suksesvolle verbinding stop nie. Herverbind die tonnel en kyk weer, want 'n gestuurde IPv6-roete kan verlore gaan by hervestiging as die bediener dit net in die aanvanklike konfigurasie stuur. Kyk dan na een uitgeslote bestemming, want split-tonnel-reëls is waar die twee families die meeste verskil.
As die toegangsnetwerk net IPv6 is, los dit alleen
Sommige netwerke verskaf net IPv6 en verwag dat die toestel IPv4-dienste bereik deur 'n vertaalmechanisme aan die operateur se kant. Om IPv6 op so 'n masjien te deaktiveer is nie 'n sekuriteitsverbetering nie; dit verwyder die enigste roete na enigiets. Dit is 'n selfveroorsaakte onderbreking ten dienste van 'n toetsuitslag wat niemand nodig gehad het nie.
Die simptoom van om dit verkeerd te kry, is kenmerkend en onaangenaam: die tonnel lyk of dit vestig, naamresolusie werk, en niks laai nie. As jy dit na 'n IPv6-verandering sien, herstel die instelling onmiddellik en gaan voort met die diagnose elders.
Wat jy ook al kies, hou die besluit eksplisiet in die profiel of die vuurmuur, koppel dit aan wat die uitgang werklik ondersteun, en let op die dubbelstapel-gedrag wat die RFC 7359 dubbelstapel-bespreking beskryf. 'n Verklaarde blok is 'n beleid. 'n Gedeaktiveerde protokol is 'n omweg wat niemand kan oudit nie, en hulle lyk identies vanaf die toetsblad.