shorewall na resolução de problemas do servidor proxy debian

1

A configuração é: debian proxy-server - > roteador linsys - > servidor interno do ubuntu

O problema é: Eu posso acessar o servidor web ubuntu (apache2) digitando 192.168.1.128 em um navegador no meu proxy debian. No entanto, minha regra de encaminhamento do tipo shorewall não passa por nenhuma das seguintes regras:

#Web/DNAT        net             loc:192.168.1.128
#DNAT           net             loc:192.168.1.128:80    tcp     80      -       70.90.XXX.XX

Informações adicionais:

Eu tenho o servidor ubuntu interno aceitando todas as conexões agora para fins de depuração (também tenho o shorewall instalado)

recortado da saída do 'shorewall show log' (na máquina debian):

Feb  1 19:37:15 fw2loc:ACCEPT:IN= OUT=eth1 SRC=192.168.1.137 DST=224.0.0.251 LEN=104     TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=84 
Feb  1 19:40:31 fw2loc:ACCEPT:IN= OUT=eth1 SRC=192.168.1.137 DST=224.0.0.251 LEN=104 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=84 

saída de 'shorewall show nat' (na máquina debian):

Chain PREROUTING (policy ACCEPT 235 packets, 74689 bytes)
pkts bytes target     prot opt in     out     source               destination         
12   724 net_dnat   all  --  eth0   *       0.0.0.0/0            0.0.0.0/0           

Chain POSTROUTING (policy ACCEPT 8 packets, 670 bytes)
pkts bytes target     prot opt in     out     source               destination         
3   242 eth0_masq  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 7 packets, 611 bytes)
pkts bytes target     prot opt in     out     source               destination         

Chain eth0_masq (1 references)
pkts bytes target     prot opt in     out     source               destination         
1    69 MASQUERADE  all  --  *      *       192.168.1.0/24       0.0.0.0/0           

Chain net_dnat (1 references)
pkts bytes target     prot opt in     out     source               destination         
2   128 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp         dpt:80 to:192.168.1.128 
0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443 to:192.168.1.128 

EDITAR:

Devo mencionar também que depois de verificar os logs do apache na máquina do ubuntu, nenhum dos pedidos parece estar fazendo isso. Quando faço uma solicitação da LAN, recebo uma entrada no log de acesso, mas ao fazer uma solicitação de fora da lan por meio do proxy, não recebo nada.

Saída de 'iptables -vnL' no proxy:

22  1280 TCPMSS     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x02 TCPMSS clamp to PMTU 
22  1280 eth0_fwd   all  --  eth0   *       0.0.0.0/0            0.0.0.0/0           
22  1280 dynamic    all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID,NEW 
22  1280 smurfs     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID,NEW 
22  1280 tcpflags   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           
22  1280 net2loc    all  --  *      eth1    0.0.0.0/0            0.0.0.0/0           
1    60 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           multiport dports 80,443 
22  1280 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.128       tcp dpt:80 

Não tenho certeza do que fazer com isso ...

Estou começando a me perguntar se há um problema fundamental em tentar passar pelo roteador Linksys e se eu deveria apenas ir debian - > o Ubuntu com um crossover ...

EDIT 2

Parece que os pacotes estão sendo encaminhados corretamente (acho que é isso que a saída do 'shorewall show nat' fez por nós)

Saída de 'tcpdump -n -i porta 80'

interface pública:

20:15:40.458118 IP 71.182.212.251.57261 > 70.90.XXX.XXX.80: S 2834662754:2834662754(0) win 65535 <mss 1452,nop,wscale 3,nop,nop,timestamp 25163236 0,sackOK,eol>

interface privada:

20: 15: 45, 405347, IP 71.182.212.251.57261 > 192.168.1.128.80: S 2834662754: 2834662754 (0) ganhar 65535

Depois de alguns dos pacotes acima, ele se transforma em:

20:16:17.623882 IP 71.182.212.251.57254 > 70.90.XXX.XXX.80: S 1673429824:1673429824(0) win 65535 <mss 1452,sackOK,eol>

e

20:16:17.623917 IP 71.182.212.251.57254 > 192.168.1.128.80: S 1673429824:1673429824(0) win 65535 <mss 1452,sackOK,eol>
    
por Hersheezy 02.02.2011 / 01:53

3 respostas

1

Qual host é definido como um gateway padrão no seu servidor Ubuntu? Se não é seu servidor Debian proxy, você deve adicionar outra regra ao / etc / shorewal / masq:

eth1:192.168.1.128         0.0.0.0/0       192.168.1.137       tcp     80

Eu assumo que seu NIC de LAN do proxy Debian é eth1 e seu endereço IP do servidor Debian é 192.168.1.137. Basicamente, o problema aqui é que a regra DNAT não altera um endereço IP de origem em pacotes encaminhados, portanto, seu servidor Ubuntu tenta responder diretamente a um originador de solicitação, que está fora de sua LAN. Ele usa um gateway padrão para realizar a comunicação, então a resposta nunca chega à caixa do Debian. Essa regra adicional altera o IP de origem para o IP da própria caixa de proxy, portanto, isso deve ajudar. De qualquer forma, provavelmente não é o que você quer, porque o Apache no Ubuntu irá gravar o IP do Debian como um IP do cliente para acessar os logs para cada requisição.

    
por 02.02.2011 / 03:09
1

Antes de tudo, suponho que o sinal # antes de cada regra não esteja presente nos arquivos de configuração (ele comenta essa linha, tornando-a inútil).

Tente monitorar seu tráfego de rede no servidor proxy nas duas interfaces, pública e privada. Do lado público:

 # tcpdump -n -i <public interface> port 80

No lado privado:

 # tcpdump -n -i <private interface> port 80 and host 192.168.1.128

Ao fazer solicitações do mundo exterior, você não vê nenhum tráfego no lado privado, então você deve checar:

O kernel permite encaminhar o tráfego (deve ser um):

cat /proc/sys/net/ipv4/ip_forward

Se retornar 0:

echo 1 > /proc/sys/net/ipv4/ip_forward

Política padrão para a cadeia FORWARD na tabela de filtros

iptables -nL | grep 'Chain FORWARD'

(de acordo com as informações que você forneceu, em vez de FORWARD você deve vê-lo na rede net2loc)

Se a política padrão for REJECT / DROP, procure uma regra na cadeia FORWARD que permita encaminhar o tráfego para o servidor HTTP:

iptables -vnL FORWARD | grep 192.168.1.128

(novamente, se nada significativo aparecer no FORWARD, verifique net2loc).

Se isso não retornar uma linha (e a política for REJECT / DROP), você não terá a regra que lhe permite encaminhar o tráfego ... verifique novamente a configuração do shorewall. Defina o loc log como info no arquivo de configuração da política, force uma regra:

iptables -A net2loc -i <public iface> -o <private iface> \
--dst 192.168.1.128 -p tcp --dport 80 -j ACCEPT

E veja o que acontece.

A alternativa, ao fazer solicitações de um local externo, e vê-lo no lado privado, significa que algo está errado (verifique a política de encaminhamento do roteador Linksys, rotas etc.).

Eu não faria o que o @Alex recomenda como é arriscado. Você perde todos os traços de quem está acessando o serviço, portanto, você perde estatísticas. Se houver algum ataque em seu site, é impossível determinar de onde ele está vindo, apenas observando os logs do seu servidor da Web e muitas outras razões. Geralmente, SNAT das redes públicas para destinos particulares é altamente desencorajado.

    
por 03.02.2011 / 03:16
0

Ok, as coisas parecem estar se comportando agora com uma configuração um pouco diferente:

Agora eu só vou ao proxy do Debian - > Servidor Ubuntu (não mais roteador linksys). Eu decidi não usar o roteador de qualquer maneira, porque é isso que estamos usando para o nosso escritório sem fio. Ter o que é suposto ser um servidor seguro ligado ao roteador do escritório parece ser uma jogada não tão inteligente da minha parte.

Resumo das alterações:

Deu as interfaces privadas de ambas as máquinas addrs IP locais estáticos com o seguinte

iface eth0 inet static
     ipaddress 192.168.1.128 #the other one got 192.168.1.137
     netmask 255.255.255.255
     network 192.168.1.0

dispositivos de rede reiniciados

reiniciado shorewall

O Shorewall parece estar indo bem e meus logs do apache são informativos (eles não dizem apenas que todos os pedidos são provenientes da máquina debian)

Obrigado a todos pela ajuda, usei tudo o que foi postado aqui para chegar ao que espero ser uma solução aceitável.

    
por 06.02.2011 / 20:44