Ett offentligt prefix för VPN-klienter: vad det faktiskt bryter

En klientpool vald för att talen ser prydliga ut är en rutt som väntar på att installeras. Prefixet behöver inte vara privat för att VPN:en ska fungera, och att använda ett block som tillhör någon annan exponerar inte heller dina användare mot internet automatiskt. Det det gör är att få dessa adresser att betyda något annat så länge tunneln är uppe, och sedan något annat igen när den faller. Gå igenom de fem kontrollerna nedan i ordning och stanna där svaret är ”tilldelat någon annanstans”.

Tilldelning är inte annonsering

Att sätta en adress på ett tunnelgränssnitt annonserar inte adressen till internet. Offentlig nåbarhet kräver en rutt, en auktoriserad väg och en leverantör som är villig att bära den, och inget av det uppstår för att en klient fick adressen från en pool. Brandväggspolicy och värdaauktorisering är återigen separata beslut.

Därför är risken inte det folk flest antar. Det lånade prefixet gör inte dina klienter nåbara; det gör någon annans destinationer onåbara från dina klienter, vilket är ett annat fel med en annan ägare. Ingen attackeras och ingen annonsering läcker ut. En användare kan helt enkelt inte öppna en webbplats som fungerade i går, och supporten har ingen anledning att misstänka VPN-poolen.

Skillnaden spelar roll när du väljer pool. Om den enda oron var exponering mot internet skulle ett offentligt block se säkert ut eftersom ingenting annonserar det. Oron är den lokala rutt som klienten installerar för prefixet, och den rutten installeras oavsett om någon annan kan se den.

Vad klientrutten faktiskt fångar upp

När tunneln kommer upp får klienten en rutt för poolens prefix, och den rutten vinner över standardrutten för varje destination inom den. En begäran till en legitim värd i det blocket går nu till VPN:en i stället för internet. Om den misslyckas, hänger eller når fel server beror på vad din sida gör med den.

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

Kör uppslagningen med tunneln uppe och igen med den nere. Adressen betyder en sak i det första fallet och något helt annat i det andra, och varje applikation som har cacheat en anslutning eller en namnmatchning över den övergången kommer att bete sig inkonsekvent. Den inkonsekvensen är svårare att stödja än ett rent fel, eftersom den beror på timing. En användare som återansluter i fel ögonblick får en annan upplevelse än en som inte gör det.

Det är också därför en välkänd IP-adress inte är ett bevis på identitet. Behåll certifikat- och servernamnsvalidering för den riktiga destinationen, eftersom den numeriska adress du nådde för fem minuter sedan nu kan tillhöra ett annat samtal.

Jämför poolen med varje nätverk du känner till

RFC 1918 avsätter tre block för privat bruk: 192.168.0.0/16, 172.16.0.0/12 och 10.0.0.0/8. Miljoner separata organisationer återanvänder dem, så privat är ett påstående om tilldelning och aldrig ett löfte om att ingen annan valt samma nummer.

Jämför kandidatpoolen med kontors-LAN, moln-VPC:er, andra VPN-pooler, partnerlänkar och de intervall distansarbetare sannolikt har hemma. Hemfallet är inte ett skäl att hitta på ett märkligt prefix; det är ett skäl att hålla poolen liten och dokumenterad.

Samordna tilldelningen med den som äger routingen och registrera returvägen på samma ställe. En pool som ingen kan routa tillbaka till är en pool som återupptäcks under ett avbrott. Sätt poolen i samma dokument som platsintervallen, inte i en klientkonfiguration som bara en person har redigerat. Dokumentet är det som gör nästa kollision undvikbar.

När offentlig adressering är rätt svar

Organisationer med korrekt tilldelat globalt utrymme kan absolut bygga en offentligt adresserad VPN-pool, och en del gör det medvetet för att undvika översättning. Den designen behöver fortfarande routing, källvalidering, åtkomstregler och klientautentisering; tilldelningen ger inget av det.

Det den ger är unikhet, egenskapen som det lånade prefixet saknar. Om du äger blocket pekar rutten din klient installerar på adresser som verkligen är dina, och betydelsen ändras inte när tunneln faller.

Lägg inte till NAT automatiskt för att kompensera ett poolval. En routad privat design med explicita returrutter är renare än översättning som tillämpas för att adresseringen aldrig planerades, och IPv6 behöver sin egen medvetna plan i stället för en kopia av IPv4-antagandena.

Avveckla en dålig pool utan att förlora åtkomst

Om poolen redan är utrullad, gör en inventering innan du ändrar den: adressreservationer, installerade rutter, DNS-poster som löser in i blocket, brandväggsomfång och de applikationer som är beroende av dem. Planera sedan ändringen med samma omsorg som varje annan routingövergång. Annonsera den till människorna som kommer att märka den, eftersom deras sessioner faller när poolen flyttas. En tyst ändring av klientadresseringen skapar supportärenden som verkar orelaterade till arbetet.

Bevara en återställningsväg som inte är beroende av poolen du tar bort, eftersom ögonblicket du drar tillbaka den är ögonblicket då din fjärråtkomst kan försvinna med den. Validera sedan båda riktningarna: de avsedda privata destinationerna fungerar fortfarande, och de internetdestinationer som tidigare fångades upp löser nu till sina riktiga ägare.

Det du vill ha är en pool som nätverksteamet kan tilldela, routa och avveckla som en enda sammanhängande sak. Ett adressformat i sig självt etablerar varken säkerhet eller anslutning.