ISA 3 patas: funciona pero ¿por qué?

08/07/2004 - 08:20 por Beemer | Informe spam
Buenos días, quería consultaros una duda de concepto:
Tengo desde hace meses un ISA de dos patas que se encarga de que una
delegación entre por VPN PPTP en la central mediante un ADSL. En la pata
exterior está el router ADSL y en la interior la red privada, que está dada
de alta completa en la LAT. Todo funciona correctamente.

Peo ayer, con el fín de que una empresa hermana, que se ha instalado en el
mismo edificio de la central, acceda a determinados servicios de uno de los
servidores, añadí una tercera tarjeta a este mismo ISA, conectada a la red
de la empresa Hermana. Y empecé a probar configuraciones:
1-)Si añadía la red completa Hermana a la LAT, ISA consideraba que era
interna y no había comunicación entre ellas.
2-)Si no añadía la red Hermana a la LAT, ISA la consideraba externa.
Entonces puse un filtro de paquetes (pasa-todo para probar) con
origen Local el servidor en central que ofrece el servicio y remoto la red
Hermana completa: No funciona.
Si cambiaba el origen a la interfaz externa del ISA si funcionaba,
pero Hermana accedía a toda la red Central, no solo al servidor concreto,
como se deseaba.
Esto mismo ocurría si Local era una red que incluyera al NIC de
Central en el ISA.
3-)La solución: Cambié la IP del NIC del ISA para Hermana a la 245 (clase C)
e incluí en la LAT las direcciones 1-253 (Es decir toda excepto la propia
NIC del ISA)
Probé el filtro de paquetes anterior, es decir Local el servidor de
Central que ofrece el servicio y Remoto Toda la red Hermana (la clase C
entera, incluyendo la pata del ISA): Funciona exactamente como se desea.
Limité el filtro al puerto concreto del servicio prestado por el
servidor y funcionó correctamente, Hermana solo puede ver en Central a ese
servidor por ese puerto y Central no ve en absoluto a Hermana.


Y aquí viene la pregunta: Esta solución reconozco que la encontrá a tanteo,
y después de pasarme la noche sin dormir, sigo sin comprender porque
funciona. Si alguien lo entiende, me gustaría que me lo explicase, porque no
me quedo agusto, como supongo que le pasaría a cualquiera de vosotros.
Por otro lado, ¿por que no funcionaba la solución 2-1? Aquí pienso que
probablemente era una cuestión de NAT, aunque cometí la torpeza de no hacer
unos netstat -na en ambos extremos para verificar que veía cada cual, si
IP's reales o la de la para del ISA cuando al abrir en 2-2 a una red
superior empezaba a funcionar.

Perdón por la extensión, pero es dificil concentrar en menos líneas seis
horas de quebradero de cabeza (sin contar toda la noche pensando).

Un saludo.
beemer
 

Leer las respuestas

#1 Ivan [MS MVP]
08/07/2004 - 09:14 | Informe spam
Si vas a instalar en el ISA un tercer adaptador solo tienes dos opciones,
que la direccion IP de ese adaptador pertenezca a la red interna (su
direccion esta incluida en la LAT) o usar una configuracion Three-homed DMZ,
no hay mas opciones.
En el primer caso, el rango de direcciones de ambos interfaces internos debe
ser distinto y, si quieres que se pueda establecer la comunicacion entre
ambos rangos debes habilitar el IP routing. En este caso puedes hacer uso
del filtrado de RRAS y limitar al acceso entre ambas subredes.
En el segundo caso, Three-homed DMZ, los rangos de direcciones IP de los
tres interfaces, deben ser distintos y tambien debes habilitar el IP routing
para permitir la comunicacion entre el interface externo-DMZ. La relacion
entre redes es de esta forma:
Interna-DMZ= NAT
Interna-Externa=NAT
DMZ-Externa=Routing

La pregunta seria: que rangos de direcciones estas usando en cada uno de los
interfaces y que rangos estan en la LAT ? en funcion de esto, la forma de
permitir la comunicacion entre las distintas subredes cambia muchisimo.
1-El tercer adaptador esta incluido en la LAT: en este caso la otra subred
debe poder acceder sin ningun tipo de restriccion siempre y cuando el IP
routing este habilitado en el ISA y la unica forma de controlar el acceso es
usando el filtrado de RRAS, algo como esto:
http://www.isaserver.org/tutorials/...urity.html
2-El tercer adaptador no esta incluido en la LAT: en este caso tenemos una
three-homed DMZ y la forma de permitir el trafico entre la subred DMZ y la
red interna es empleando reglas de publicacion, los filtros solo sirven para
permitir el trafico entre la DMZ y el propio servidor ISA y entre la red
externa/DMZ.

La solucion 2-1 no funciona porque debes permitir el acceso con reglas de
publicacion, no con filtros. La solucion que estas usando actualmente no me
parece correcta a priori. Necesitaria ver los rangos de direcciones de cada
interface y el contenido de la LAT.

Un saludo.
Ivan
MS MVP ISA Server


"Beemer" escribió en el mensaje
news:
Buenos días, quería consultaros una duda de concepto:
Tengo desde hace meses un ISA de dos patas que se encarga de que una
delegación entre por VPN PPTP en la central mediante un ADSL. En la pata
exterior está el router ADSL y en la interior la red privada, que está


dada
de alta completa en la LAT. Todo funciona correctamente.

Peo ayer, con el fín de que una empresa hermana, que se ha instalado en el
mismo edificio de la central, acceda a determinados servicios de uno de


los
servidores, añadí una tercera tarjeta a este mismo ISA, conectada a la red
de la empresa Hermana. Y empecé a probar configuraciones:
1-)Si añadía la red completa Hermana a la LAT, ISA consideraba que era
interna y no había comunicación entre ellas.
2-)Si no añadía la red Hermana a la LAT, ISA la consideraba externa.
Entonces puse un filtro de paquetes (pasa-todo para probar) con
origen Local el servidor en central que ofrece el servicio y remoto la red
Hermana completa: No funciona.
Si cambiaba el origen a la interfaz externa del ISA si funcionaba,
pero Hermana accedía a toda la red Central, no solo al servidor concreto,
como se deseaba.
Esto mismo ocurría si Local era una red que incluyera al NIC de
Central en el ISA.
3-)La solución: Cambié la IP del NIC del ISA para Hermana a la 245 (clase


C)
e incluí en la LAT las direcciones 1-253 (Es decir toda excepto la propia
NIC del ISA)
Probé el filtro de paquetes anterior, es decir Local el servidor


de
Central que ofrece el servicio y Remoto Toda la red Hermana (la clase C
entera, incluyendo la pata del ISA): Funciona exactamente como se desea.
Limité el filtro al puerto concreto del servicio prestado por el
servidor y funcionó correctamente, Hermana solo puede ver en Central a ese
servidor por ese puerto y Central no ve en absoluto a Hermana.


Y aquí viene la pregunta: Esta solución reconozco que la encontrá a


tanteo,
y después de pasarme la noche sin dormir, sigo sin comprender porque
funciona. Si alguien lo entiende, me gustaría que me lo explicase, porque


no
me quedo agusto, como supongo que le pasaría a cualquiera de vosotros.
Por otro lado, ¿por que no funcionaba la solución 2-1? Aquí pienso que
probablemente era una cuestión de NAT, aunque cometí la torpeza de no


hacer
unos netstat -na en ambos extremos para verificar que veía cada cual, si
IP's reales o la de la para del ISA cuando al abrir en 2-2 a una red
superior empezaba a funcionar.

Perdón por la extensión, pero es dificil concentrar en menos líneas seis
horas de quebradero de cabeza (sin contar toda la noche pensando).

Un saludo.
beemer


Preguntas similares