Et offentlig prefiks for VPN-klienter: hva det faktisk ødelegger

En klientpool valgt fordi tallene ser ryddige ut, er en rute som venter på å bli installert. Prefikset trenger ikke være privat for at VPN-en skal virke, og bruk av en blokk som tilhører noen andre eksponerer heller ikke brukerne dine for internett automatisk. Det det gjør, er å få disse adressene til å bety noe annet så lenge tunnelen er oppe, og deretter noe annet igjen når den faller. Gå gjennom de fem kontrollene nedenfor i rekkefølge og stopp der svaret er «tildelt et annet sted».

Tildeling er ikke annonsering

Å sette en adresse på et tunellgrensesnitt annonserer den ikke til internettet. Offentlig tilgjengelighet krever en rute, en autorisert vei og en leverandør som er villig til å bære den, og ingen av disse oppstår fordi en klient fikk adressen fra en pool. Brannmurpolicy og vertsautorisasjon er igjen separate beslutninger.

Derfor er risikoen ikke det folk flest antar. Det lånte prefikset gjør ikke klientene dine tilgjengelige; det gjør noen andres destinasjoner utilgjengelige fra klientene dine, noe som er en annen feil med en annen eier. Ingen blir angrepet, og ingen annonsering slipper ut. En bruker kan rett og slett ikke åpne et nettsted som fungerte i går, og brukerstøtten har ingen grunn til å mistenke VPN-poolen.

Forskjellen betyr noe når du velger en pool. Hvis den eneste bekymringen var eksponering mot internettet, ville en offentlig blokk se trygg ut fordi ingenting annonserer den. Bekymringen er den lokale ruten klienten installerer for prefikset, og den ruten installeres uansett om noen andre kan se den.

Hva klientruten faktisk fanger opp

Når tunnelen kommer opp, mottar klienten en rute for poolens prefiks, og den ruten vinner over standardruten for hver destinasjon innenfor. En forespørsel til en legitim vert i den blokken går nå til VPN-en i stedet for internettet. Om den feiler, henger eller når feil server, avhenger av hva din side gjør med den.

ip route get 198.51.100.20
ip -br addr show tun0
traceroute -n 198.51.100.20

Kjør oppslaget med tunnelen oppe og igjen med den nede. Adressen betyr én ting i det første tilfellet og noe helt annet i det andre, og enhver applikasjon som har bufret en tilkobling eller et navneoppslag over den overgangen, vil oppføre seg inkonsekvent. Den inkonsistensen er vanskeligere å støtte enn en ren feil, fordi den avhenger av tidspunktet. En bruker som kobler til på nytt i feil øyeblikk, får en annen opplevelse enn en som ikke gjør det.

Det er også derfor en kjent IP-adresse ikke er bevis på identitet. Behold sertifikat- og servernavnvalidering for den ekte destinasjonen, for den numeriske adressen du nådde for fem minutter siden, kan nå tilhøre en annen samtale.

Sammenlign poolen med hvert nettverk du kjenner

RFC 1918 setter av tre blokker til privat bruk: 192.168.0.0/16, 172.16.0.0/12 og 10.0.0.0/8. Millioner av separate organisasjoner gjenbruker dem, så privat er en uttalelse om tildeling og aldri et løfte om at ingen andre har valgt de samme tallene.

Sammenlign kandidatpoolen med kontor-LAN-er, sky-VPC-er, andre VPN-pooler, partnerlenker og områdene fjernarbeidere sannsynligvis har hjemme. Hjemmetilfellet er ikke grunn til å finne opp et merkelig prefiks; det er grunn til å holde poolen liten og dokumentert.

Koordiner tildelingen med den som eier rutingen, og registrer returveien på samme sted. En pool ingen kan rute tilbake til, er en pool som blir gjenoppdaget under et utfall. Sett poolen i samme dokument som nettstedområdene, ikke i en klientkonfigurasjon som bare én person har redigert. Dokumentet er det som gjør den neste kollisjonen unngåelig.

Når offentlig adressering er det riktige svaret

Organisasjoner med riktig tildelt globalt rom kan absolutt bygge en offentlig adressert VPN-pool, og noen gjør det bevisst for å unngå oversettelse. Det designet trenger fortsatt ruting, kildevalidering, tilgangsregler og klientautentisering; tildelingen leverer ingen av dem.

Det den leverer, er unikhet, egenskapen det lånte prefikset mangler. Hvis du eier blokken, peker ruten klienten din installerer på adresser som virkelig er dine, og betydningen endres ikke når tunnelen faller.

Ikke legg til NAT automatisk for å kompensere for et poolet valg. Et rutet privat design med eksplisitte returruter er renere enn oversettelse anvendt fordi adresseringen aldri ble planlagt, og IPv6 trenger sin egen bevisste plan i stedet for en kopi av IPv4-antakelsene.

Fas ut en dårlig pool uten å miste tilgang

Hvis poolen allerede er utrullet, lag en oversikt før du endrer den: adressereservasjoner, installerte ruter, DNS-oppføringer som løses inn i blokken, brannmursomfang og applikasjonene som avhenger av dem. Deretter planlegger du endringen med samme omhu som enhver annen rutings-overgang. Annonser den til menneskene som vil merke det, for sesjonene deres vil falle når poolen flytter seg. En stille endring av klientadressering genererer støttebilletter som ser ut til å ikke ha noe med arbeidet å gjøre.

Bevar en gjenopprettingsvei som ikke avhenger av poolen du fjerner, for øyeblikket du trekker den tilbake, er øyeblikket der fjern tilgang kan forsvinne med den. Valider deretter begge retninger: de tiltenkte private destinasjonene fungerer fortsatt, og internettdestinasjonene som tidligere ble fanget opp, løses nå til sine ekte eiere.

Det du vil ha, er en pool som nettverksteamet kan tildele, rute og fase ut som én sammenhengende ting. Et adresseformat alene etablerer verken sikkerhet eller tilkobling.