CIDR de grupo en Access Server: enderezos de membros ou rede de recursos

Nun grupo de Access Server dous campos aceptan un CIDR e, a primeira vista, parecen o mesmo tipo de entrada: un describe os enderezos que se entregan aos membros da VPN e o outro describe as redes ás que eses membros poden chegar. Encher o campo equivocado acéptase sen erro, e iso é xustamente o que fai caro o fallo. O primeiro cambia o teu plan de enderezamento do túnel, o segundo decide que destinos están permitidos e ningún implica o outro. Hai ademais un terceiro obxecto que a xente mete entre estes dous, a subrede que está detrás da pasarela dunha sede, e non pertence a ningún dos dous campos.

A mesma sintaxe, preguntas distintas

Pregunta que nomea o valor. Un CIDR de enderezos de membro responde a que enderezos internos reciben os clientes que se conectan, e a maquinaria de asignación consómeo antes de que circule ningún tráfico. Un CIDR de recurso responde a que destinos pode usar este grupo, e as regras de acceso consómeno cando se avalía un paquete. Un é a definición dun pool, o outro é un permiso.

As consecuencias de confundilos son opostas. Unha LAN de destino pegada no campo do pool pode repartir enderezos que xa existen nesa LAN, o que produce un comportamento de enderezos duplicados, ou desprazar o pool de tal xeito que rompa en silencio todas as regras de firewall escritas contra o rango anterior. Un pool pegado nunha regra de acceso non concede nada útil, porque ningún destino vive alí. Os dous erros preséntanse igual: o túnel está arriba pero algo vai mal.

Asignación: o espazo de enderezos dos membros

O pool non debe solaparse con ningunha LAN á que un membro poida chegar nin con ningún outro pool de VPN do despregamento. É unha restrición de planificación, non un axuste do produto: con dúas sedes que usan 10.90.40.0/24 para os membros, un membro dunha sede non pode encamiñar cara á outra sen tradución, e ningunha regra de acceso o arranxa.

O modo de asignación tamén importa. Un pool dinámico entrega a cada membro o seguinte enderezo libre, mentres que unha asignación estática por usuario fíxao. A asignación estática é o que queres cando as regras de firewall ou a monitorización se refiren a membros concretos, e ademais fai visible un cambio do plan de enderezamento: o enderezo fixado segue dentro do novo pool ou xa non está. Le o enderezo de túnel dun membro conectado antes e despois de calquera cambio neste campo.

Permiso: as redes de destino van nas regras de acceso

A alcanzabilidade exprésase nas regras de acceso, que nomean o grupo ou os usuarios, unha rede ou servizo de destino e o método de acceso. Ese último punto é onde morren a maioría das configuracións a medio rematar: unha regra pode encamiñar o tráfico cara ao destino ou aplicarlle NAT, e as dúas cousas piden condicións distintas á rede. Unha ruta encamiñada esixe que o lado do destino saiba devolver o tráfico ao pool da VPN, mentres que unha ruta con NAT agocha os membros detrás dun enderezo no que o destino xa confía. A documentación dos grupos de Access Server mantén a rede do grupo separada das regras de acceso do grupo, e as etiquetas movéronse entre versións.

Un destino permitido segue necesitando unha ruta utilizábel. A regra permite, a ruta entrega, o camiño de volta responde e o servizo no host acepta. Catro cousas, catro sitios onde mirar, e só a primeira vive na regra de acceso. Un permiso en verde cun traceroute morto adoita significar que falta a ruta de volta na pasarela do destino, non que a regra estea mal.

O terceiro obxecto: unha subrede de sede detrás dunha pasarela

Declarar que un cliente concreto é propietario dunha subrede é unha afirmación de encamiñamento sobre unha sede, non unha asignación de enderezos nin un permiso. En termos de Access Server é a configuración de pasarela admitida para unha rede que se conecta, e existe porque un router de sede pode anunciar a LAN que ten detrás. Os membros seguen recibindo enderezos do pool e seguen necesitando unha regra de acceso para usar esa LAN de sede.

Manter os tres separados compensa durante a revisión. Unha subrede de sede rexistrada como espazo de enderezos de membros do grupo parece correcta nunha captura e rompe a asignación para todos os do grupo. Esa mesma subrede anotada só nunha regra de acceso concede acceso sen a declaración de propiedade, así que o tráfico de volta non ten a onde ir. Pon cada obxecto na súa propia columna do deseño e o erro deixa de ser posible.

Como saber cal estás mirando

Le a etiqueta xunto cos seus veciños. Un campo xunto a un modo de asignación, un tamaño de pool ou unha excepción por usuario trata da asignación. Un campo xunto a un selector de grupo, un servizo ou porto e un método de encamiñamento trata do permiso. As versións renomean cousas, pero os veciños quedan máis ou menos no seu sitio, e por iso o texto dunha captura antiga é unha mala guía de navegación.

Despois verifica cun só membro en lugar de con todo o grupo: o seu grupo efectivo, o seu enderezo de túnel asignado e a regra que autoriza o destino pretendido. Confirma a ruta, o NAT ou a ruta encamiñada, o tráfico de volta e o permiso do servizo nesa orde, e cambia só o campo que coincide coa discrepancia demostrada. Mantén despois os rexistros de asignación e de permiso separados, para que un cambio posterior do pool non se lea como un cambio no que o grupo pode alcanzar.