VNC e IPTABLES en suse11

Imagen de mikeMTY

Forums: 

usamos un sever corriendo SUSE 11 con squid, tengo IPTABLES por defecto denegando todo el trafico de entrada y salida, y solo tengo habilitados los puertos que necesito, surgio la necesidad de hablitar el acceso al escritorio remoto via browser, solo para mi PC, habri los siguientes puertos:


Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT udp -- 172.21.44.50 172.21.44.250 udp spts:1024:65535 dpt:5801
ACCEPT tcp -- 172.21.44.50 172.21.44.250 tcp spts:1024:65535 dpt:5801
ACCEPT tcp -- 172.21.44.50 172.21.44.250 tcp spts:1024:65535 dpt:5901
ACCEPT udp -- 172.21.44.50 172.21.44.250 udp spts:1024:65535 dpt:5901
ACCEPT tcp -- 172.21.44.50 172.21.44.250 tcp spts:1024:65535 dpt:5900
ACCEPT udp -- 172.21.44.50 172.21.44.250 udp spts:1024:65535 dpt:5900

Chain OUTPUT (policy DROP)
target prot opt source destination
ACCEPT tcp -- 172.21.44.250 172.21.44.50 tcp spt:5801 dpts:1024:65535
ACCEPT udp -- 172.21.44.250 172.21.44.50 udp spt:5801 dpts:1024:65535
ACCEPT tcp -- 172.21.44.250 172.21.44.50 tcp spt:5901 dpts:1024:65535
ACCEPT udp -- 172.21.44.250 172.21.44.50 udp spt:5901 dpts:1024:65535
ACCEPT tcp -- 172.21.44.250 172.21.44.50 tcp spt:5900 dpts:1024:65535
ACCEPT udp -- 172.21.44.250 172.21.44.50 udp spt:5900 dpts:1024:65535

pongo en mi browser http://172.21.44.250:5801/ y me comienza a habrir el escritorio remoto, pero despues de unos momentos de solo quedarce procesando la peticion, no logra mostrarme los elementos del escritorio y me aparece la leyenda "Network error: remote side closed conexion" y un boton de "login again", borro las reglas del iptables y me conecto sin ningun problema...

me faltan puertos, que podra suceder, por que no me permitira hacer la conexion....
gracias

Permitir tráfico a través de

Imagen de acl

Permitir tráfico a través de la interfaz lo no es lo mismo que usar -s o -d 127.0.0.1, pues es normal que paquetes con dirección de origen y destino distintos a 127.0.0.0/8 pasen por ella. El kernel transporta paquetes de interfaces locales a través de lo sin cambiar su dirección de origen o destino. (Haz un tcpdump -i lo tcp port 80 y luego abre una conexión al puerto 80 a tu ip local-pero-no-127 para que lo veas). Los paquetes de tu Xvnc pasan a través de lo con la dirección de la interfaz eth0 y por tanto no llegan a corresponder con tu regla de arriba, lo que hace que se pierdan.

como mencionas habilite las

Imagen de mikeMTY

como mencionas habilite las reglas de la siguiente manera:

iptables -A OUTPUT -o lo -p tcp -j ACCEPT
iptables -A OUTPUT -o lo -p udp -j ACCEPT

iptables -A INPUT -i lo -p tcp-j ACCEPT
iptables -A INPUT -i lo -p udp -j ACCEPT

funciono correctamente y de manera mas clara, quedo reafirmado que no es lo mismo poner "lo" a "127.0.0.1" ya que al tomar la ip de eth0 no eran reconocido por la regla, exelente, es bueno llegar a una conclusion satisfactoria de una cuestion de este tipo, ya que se reafirman mas los terminologia de estos problemas, buenas respuestas acl tanks por el seguimiento

:)

A las órdenes, hermano.

Imagen de acl

A las órdenes, hermano. Siempre es bueno deshacerse de las dudas y tener los conceptos claros. Así puedes tener soluciones más robustas a tus problemas.

Por ejemplo, un problema evidente en la regla anterior que tenías era que podía hacer que cualquier paquete con solo tener dirección de origen en tu máquina podía pasarse toda tu infraestructura de filtrado de paquetes.

Por cierto, yo dejaría pasar icmp por lo también. No veo un beneficio inmediato y obvio, pero me gusta tener mi interfaz lo abierta y sin restricciones.

Páginas