Centraliza o acceso VPN dos socios sen unir os socios

A proposta é razoable: cinco túneles de socios repartidos nunha ducia de portátiles, cinco conxuntos de versións de cliente, cinco guións de asistencia e un enxeñeiro que sabe como encaixan. Levalos a un nivel de acceso controlado resolve a dispersión de puntos finais. Tamén crea un obxecto novo na túa arquitectura, un servizo de acceso compartido que agora necesita o seu propio modelo de autorización, e o fallo que todos subestiman é un aparello central con todos os túneles activados que se converte en silencio nunha rede de tránsito entre organizacións que nunca aceptaron ser veciñas. Ese risco é unha decisión de deseño, non algo que o hardware faga por si só. O traballo de abaixo é como manteño a comodidade sen aceptar o efecto secundario accidental.

Comeza polo contrato que cada socio xa asinou

Antes de calquera configuración, confirma que o socio permite secasí unha pasarela compartida ou unha conexión de sitio. Unha conta persoal de acceso remoto, un requisito de postura do dispositivo ou un fluxo interactivo de MFA poden non ser transferibles a un túnel compartido sen supervisión, e agrupar empregados detrás dunha identidade de cliente copiada é o tipo de atallo que sobrevive ata que o socio audita os seus rexistros. Para cada conexión permitida, anota os rangos de destino, os dominios DNS privados, as fontes internas autorizadas, o responsable da autenticación e que debe ocorrer cando falle o túnel. Pide ao socio que confirme por escrito a conexión compartida, incluídos os rangos de orixe que aceptará. A aprobación verbal adoita cambiar de significado a semana en que rota o seu equipo de seguridade.

Ese rexistro é o entregable. Se non podes escribilo para un socio, ese socio non está listo para centralizarse.

Enruta por contexto, non só por destino

Dous socios acabarán usando o mesmo rango privado, porque cada organización escolle do mesmo espazo RFC 1918. Unha única táboa de enrutamento corrente non pode escoller o socio correcto só cun enderezo de destino, así que os rangos solapados necesitan contextos de enrutamento separados ou outro deseño acordado. O modelo de dominio de reenvío de RFC 4364 explica por que importa esa separación, e un despregamento non necesita executar MPLS para esixir a mesma propiedade á súa plataforma de pasarela.

Pregunta á plataforma algo directo: poden dous socios compartir un prefixo de destino e aínda así distinguirse por que contexto de empregado chegou a sesión? Se a resposta é non, esa restrición dá forma ao deseño máis que calquera lista de funcións dun provedor.

Onde a resposta é si, o contexto de enrutamento pasa a ser o que documentas e probas, porque é invisible nun traceroute.

Decide que escribe o empregado e que rexistra o socio

Parte do traballo de socios encaixa nun proxy de aplicacións ou nun espazo de traballo remoto aberto dentro do contexto dese socio. Outro traballo necesita acceso de rede enrutado desde un segmento de empregados aprobado, e ambos producen enderezos de orixe distintos e rastros de auditoría distintos no extremo remoto. Un enderezo de orixe traducido compartido pode satisfacer unha lista de permitidos mentres oculta que dispositivo fixo que, así que conserva un rexistro fiable de empregado a sesión e mantén a autenticación da aplicación no seu sitio en lugar de tratar o enderezo da pasarela como unha identidade, o cal é cómodo xusto ata o momento en que o socio pregunta quen o fixo.

Despois percorre unha tarefa real desde o lado do empregado: que preme, que se lle pide e que vería o socio se pedise unha entrada de rexistro. Se ese percorrido non é reproducible, o deseño non está rematado.

Denega explicitamente o tránsito entre socios

O hardware compartido nunca debería implicar confianza compartida. Engade a denegación como unha regra deliberada cun responsable con nome, non como un accidente de configuración ausente, e proba en ambas direccións cunha petición que doutro xeito tería éxito. A proba importa porque un permiso que só falta pode restauralo o seguinte enxeñeiro que engada unha ruta para arranxar unha queixa non relacionada.

Escribe a denegación no rexistro do socio xunto aos permisos, para que a intención sobreviva aos cambios de persoal.

Opérao como un servizo compartido, non como un portátil máis grande

A renovación de túneles, a rotación de credenciais, a capacidade e a substitución da pasarela pasan agora a ser cambios de servizo compartido, o que significa que necesitan un calendario e unha vía de comunicación que os portátiles individuais nunca esixiron. Un certificado de socio que caduca un sábado xa non é a caída dun usuario; son todas as sesións dese socio á vez.

Acepta o nivel só cando unha petición denegada entre socios falla exactamente como se pretendía e unha petición permitida dun empregado chega ao destino correcto coa orixe correcta. Quitar o conflito de portátiles mantendo intacta a fronteira de cada socio é todo o obxectivo; un deseño no que cada prefixo remoto é alcanzable desde cada escritorio só moveu o problema.

Mantén unha táboa pequena de socio, contexto, rangos permitidos e responsable. Será o primeiro que alguén pida durante un incidente.