Un prefixo público para os clientes VPN: que é o que realmente rompe

Un conxunto de clientes escollido porque os números parecen ordenados é unha ruta esperando a ser instalada. O prefixo non ten que ser privado para que a VPN funcione, e usar un bloque que pertence a outra persoa tampouco expón automaticamente os teus usuarios a internet. O que fai é que esas direccións signifiquen algo distinto mentres o túnel está activo, e despois signifiquen outra cousa cando cae. Percorre as cinco comprobacións seguintes en orde e detente onde a resposta sexa «asignado noutro sitio».

Asignar non é anunciar

Pór unha dirección nunha interface de túnel non a anuncia a internet. A accesibilidade pública necesita unha ruta, un camiño autorizado e un provedor disposto a transportala, e nada diso aparece porque un cliente recibise a dirección dun conxunto. A política da devasa e a autorización do hóspede son outra vez decisións separadas.

Por iso o risco non é o que a maioría supón. O prefixo prestado non fai accesibles os teus clientes; fai que os destinos doutra persoa non sexan accesibles desde os teus clientes, o que é un fallo distinto cun propietario distinto. Ninguén é atacado e ningún anuncio escapa. Un usuario simplemente non pode abrir un sitio que onte funcionaba, e o servizo de asistencia non ten motivo para sospeitar do conxunto da VPN.

A distinción importa ao escoller un conxunto. Se a túa única preocupación fose a exposición a internet, un bloque público parecería seguro porque nada o anuncia. A preocupación é a ruta local que o cliente instala para ese prefixo, e esa ruta instálase tanto se alguén máis pode vela como se non.

Que captura realmente a ruta do cliente

Cando o túnel se levanta, o cliente recibe unha ruta para o prefixo do conxunto, e esa ruta gaña á ruta por defecto para cada destino dentro del. Unha petición a un hóspede lexítimo dese bloque agora vai á VPN en lugar de a internet. Que falle, se colgue ou chegue ao servidor equivocado depende do que faga o teu lado con ela.

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

Executa a consulta co túnel levantado e de novo con el caído. A dirección significa unha cousa no primeiro caso e algo completamente distinto no segundo, e calquera aplicación que cachease unha conexión ou unha resolución de nome durante esa transición comportarase de forma inconsistente. Esa inconsistencia é máis difícil de soportar que un fallo limpo, porque depende do momento. Un usuario que se reconecta no momento equivocado ten unha experiencia distinta da de quen non o fai.

Tamén por iso unha dirección IP coñecida non é proba de identidade. Mantén a validación de certificado e de nome de servidor para o destino real, porque a dirección numérica á que chegaches hai cinco minutos pode pertencer agora a outra conversa.

Compara o conxunto con todas as redes que coñezas

RFC 1918 reserva tres bloques para uso privado: 192.168.0.0/16, 172.16.0.0/12 e 10.0.0.0/8. Millóns de organizacións separadas reutilízanos, así que privado é unha afirmación sobre a asignación e nunca unha promesa de que ninguén máis escolleu os mesmos números.

Compara o conxunto candidato coas LAN de oficina, as VPC da nube, outros conxuntos de VPN, as ligazóns de socios e os rangos que os traballadores remotos probablemente teñan na casa. O caso doméstico non é motivo para inventar un prefixo estraño; é motivo para manter o conxunto pequeno e documentado.

Coordina a asignación con quen posúe o encamiñamento e rexistra o camiño de volta no mesmo lugar. Un conxunto ao que ninguén pode encamiñar de volta é un conxunto que se redescubrirá durante unha incidencia. Pon o conxunto no mesmo documento que os rangos dos sitios, non nunha configuración de cliente que só editou unha persoa. O documento é o que fai evitable a seguinte colisión.

Cando o direccionamento público é a resposta correcta

As organizacións con espazo global asignado correctamente poden sen dúbida construír un conxunto de VPN con direccións públicas, e algunhas fano a propósito para evitar a tradución. Ese deseño segue necesitando encamiñamento, validación de orixe, regras de acceso e autenticación de clientes; a asignación non achega nada diso.

O que si achega é unicidade, a propiedade da que carece o prefixo prestado. Se posúes o bloque, a ruta que instala o teu cliente apunta a direccións que son xenuinamente túas, e o significado non cambia cando o túnel cae.

Non engadas NAT automaticamente para compensar unha elección de conxunto. Un deseño privado encamiñado con rutas de volta explícitas é máis limpo que unha tradución aplicada porque o direccionamento nunca se planificou, e IPv6 necesita o seu propio plan deliberado en lugar dunha copia das suposicións de IPv4.

Retira un conxunto malo sen perder o acceso

Se o conxunto xa está despregado, fai inventario antes de cambialo: reservas de direccións, rutas instaladas, rexistros DNS que resolven dentro do bloque, ámbitos da devasa e as aplicacións que dependen deles. Despois programa o cambio co mesmo coidado que calquera outro cambio de encamiñamento. Anúnciao ás persoas que o notarán, porque as súas sesións caerán cando o conxunto se mova. Un cambio silencioso no direccionamento dos clientes xera tíckets de asistencia que parecen non ter relación co traballo.

Conserva un camiño de recuperación que non dependa do conxunto que estás retirando, porque o momento en que o retiras é o momento en que o teu acceso remoto pode desaparecer con el. Valida despois ambas as direccións: os destinos privados previstos seguen funcionando, e os destinos de internet que antes se capturaban agora resolven aos seus verdadeiros propietarios.

O que queres é un conxunto que o equipo de rede poida asignar, encamiñar e retirar como unha soa cousa coherente. Un formato de dirección por si só non establece nin seguridade nin conectividade.