IPv6-adresser erstatter ikke din VPN: gå tilbage til den oprindelige opgave

Åbn klientens statusside, se en global IPv6-adresse, og fristelsen er at konkludere, at tunnelen er blevet valgfri. Siden viser en adresse, ikke en krypteringsgrænse, ikke en privat routingtabel og ikke en adgangsbeslutning. En VPN varetager normalt tre opgaver på én gang, og IPv6 berører kun den om at dele knappe adresser. At følge én tjeneste fra klienten til lytteren er den eneste måde at se, hvilken opgave der overlever ændringen.

Navngiv opgaven, før du fjerner værktøjet

Folk siger “VPN”, når de mener en af tre ordninger, og de tre fejler af forskellige grunde. At nå én applikation, som ét team udgiver, er et applikationsadgangsproblem. At tilslutte sig et bestemt sæt private netværk, så flere lokaliteter kan nå hinanden, er et routingforhold. At holde et stabilt administrativt lag over infrastruktur, du ikke helt kontrollerer, er en driftsordning med sin egen adresseplan.

IPv6 fjerner en hindring for adressedeling i den første ordning og gør der reel nytte, fordi en direkte adresse kan erstatte en oversætter. For de to andre ændrer det intet, da kravet aldrig var adressemangel. Skriv ned, hvilken af de tre du faktisk kører, før du rører en konfiguration.

En offentlig adresse er ikke kryptering

En adresse med globalt omfang fortæller, hvor en vært kan nås; den siger intet om, hvorvidt trafikken, der ankommer dertil, er krypteret eller godkendt. Sikkerhedsdiskussionen i RFC 8504 adskiller understøttelse af IPsec-implementering fra det bredere valg mellem IPsec, TLS, SSH og andre tilgange, og det er netop den forskel, der forsvinder, når adresserbarhed læses som beskyttelse. En stak, der understøtter en mekanisme, har kun bevist, at mekanismen er tilgængelig, aldrig at dette flow gik gennem den. For IPsec specifikt afgør den forhandlede association og den trafik, den udvælger, hvad der er beskyttet, og en adressefamilie er en egenskab ved pakken, ikke en politik for den.

Tilgængelighed er igen et særskilt spørgsmål. En offentlig adresse får ikke uopfordret trafik til at ankomme, fordi ruten, firewallen og lytteren hver har en stemme, og at fjerne NAT fjerner ét filter, ikke dem alle. Beslut, hvilken af de tre tunnelen stod i stedet for, hvis nogen.

Hvad laget stadig leverer

Et lag fortsætter med at gøre sig fortjent til sin plads i tre situationer. Fjernbrugere kan have brug for et bestemt sæt ruter i stedet for én applikation, to lokaliteter kan have brug for en aftale om privat tilgængelighed, og operatører kan ønske adressering, der ikke ændrer sig, når adgangsudbyderen gør. Ingen af de tre handler om manglen på IPv4-adresser.

Globale adresser gør det ikke vedligeholdelsesfrit. En ryddelig indre plan sikrer ikke, at det ydre endepunkt fortsat svarer, efter at udbyderen har ændret det, og godkendelse, genopkobling og navneopdateringer kræver stadig en ejer. Beslut, hvordan det gendannes, før noget slukkes.

Følg den tjeneste, der bliver offentlig

Start på værten, og list hvad der faktisk lytter, for den applikation, du godkendte, er sjældent det eneste på maskinen. ss -lntup udskriver hver TCP- og UDP-lytter med sin bind-adresse og tilføjer den ejende proces, hvor dine rettigheder tillader det, hvilket med et blik viser, om en administrativ grænseflade sidder på en jokeradresse eller kun på loopback. Hvis din stak holder IPv6-sockets adskilt, gentag sådan: ss -6 -lntup.

Klassificér derefter hver linje efter publikum. En applikationsport med egen godkendelse og transportsikkerhed kan være fin på en offentlig adresse, mens en administrativ grænseflade, et metrikendepunkt og en databaseport normalt ikke er. Én godkendt applikation er en vurdering af netop den applikation, aldrig tilladelse til at blotlægge hver tjeneste, der deler værten. Bind-adressen på hver linje fortæller, om eksponeringen allerede findes, eller om ændringen, du planlægger, ville skabe den.

To tests, beslut så hvad der skal slukkes

Før du fjerner et lag, besvar to spørgsmål på papir. For det første, kræver behovet privat routing, altså tilgængelighed, som en offentlig adresse ikke indebærer, og som adgangsudbyderen ikke tilbyder? For det andet, kræver det en beskyttelsesgrænse, altså kryptering og godkendelse på et flow, der ellers ville krydse en ubetroet vej åbent? Hvis begge svar er nej for den tjeneste, er tunnelen en kandidat til fjernelse; hvis ét af dem er ja, bliver den.

Kør den samme test over IPv4 og IPv6 hver for sig på en dual-stack-klient fordi beskyttet IPv4-trafik intet siger om IPv6-vejen. En global IPv6-adresse på en statusside er ikke bevis på en lækage, og en manglende er ikke bevis på beskyttelse. Sluk kun de tjenester, hvor begge svar er skrevet ned og stadig er nej, og notér i ændringsloggen, hvilket spørgsmål der afgjorde det.