Freigeben über

Isolando Problemas onde o ISA Server Parece ser o Culpado – Sessão 2

  • Artikel

Por: Yuri Diógenes

1. Introdução

Na sessão passada vimos inicialmente o quão importante é o entendimento do problema antes mesmo de prosseguir com a obtenção de dados. Os questionamentos também fazem parte deste trabalho inicial, que por sua vez é um elemento fundamental na hora da resolução do problema.

Nesta sessão dois iremos sobre um outro cenário onde o servidor ISA parecia ser de fato o culpado pelo problema, porém após o levantamento correto das informações do ambiente e do software de terceiros em uso, foi possível observar que o ISA não estava causando de fato o problema.

Vejamos então do que se trata.

2. Cenário – Não é Possível Estabelecer uma Conexão VPN Site-to-Site entre o Servidor ISA e um Firewall de Terceiros

Neste cenário a empresa tem uma parceria com uma outra empresa e ambas precisam trocar informações via rede. Para fazer isso de forma segura usando a Internet eles resolveram criar uma VPN Site-to-Site. A empresa tinha um servidor ISA e o parceiro usava uma solução de terceiros para VPN, foi acordado que a conexão entre eles seria realizada via protocolo PPTP e que todo o tráfego dentro do túnel VPN seria liberado.

Durante o levantamento das informações foi também visto que a topologia em uso era a mostrada abaixo:

 

Figura 1 – Topologia levantada pelo administrador dos servidores Windows

O cliente da empresa que tem o servidor ISA já fez toda configuração da VPN usando o artigo oficial que descreve passo a passo como implementar este tipo de configuração no lado do servidor ISA.

No lado do Parceiro foi verificado que ele tem outras empresas conectadas neste concentrador VPN sem nenhum problema. O parceiro diz que não há problema de configuração no lado dele pois ele está usando o mesmo modelo que tem para outras empresas.

Após verificar todo o histórico e também a topologia apresentada as seguintes perguntas foram feita ao cliente:

· O modem também funciona como roteador?

o Resposta: Sim.

· O seu modem implementa lista de controle de acesso (ACL)?

o Resposta: Não Sei

· O modem também funciona como firewall?

o Resposta: Não Sei.

Como é possível observar uma das tarefas do engenheiro de suporte também é ajudar ao cliente a entender melhor o próprio ambiente J.

3.2. Coletas

A coleta deverá ser basicamente a mesma usada na Sessão 1 mostrada semana passada (ver item 3.2. do Artigo Isolando Problemas onde o ISA Server Parece ser o Culpado – Sessão 1). Adicionalmente, para este tipo de cenário também é importante usar uma outra ferramenta de teste que é o PPTP Ping. O PPTP ping é formado pelos seguintes utilitários:

  • PPTPCLNT – versão cliente que vai ser usada para enviar os testes PPTP.
  • PPTPSRV – versão servidor que vai ser usada para assegurar que o servidor esteja ouvindo conexões PPTP.

Dentro de um cenário normal o que esperamos é que quando o cliente PPTP envie uma tentativa de conexão para o servidor PPTP então tenhamos a validação que o protocolo 47 (GRE - Generic Route Encapsulation) e a porta TCP 1723 estejam corretamente liberadas e acessíveis no lado do servidor.

Nota: Para maiores informações sobre o protocolo 47 ver o artigo “VPN Tunnels - GRE Protocol 47 Packet Description and Use” no Microsoft Technet.

Segue abaixo um exemplo de um tráfego correto com o uso do PPTP Ping:

Figura 2 – Teste com PPTP Ping – Lado Cliente.

Figura 3 – Teste com PPTP Ping – Lado do Servidor.

Para efetuar o download do PPTP Ping você precisa instalar as ferramentas de suporte do Windows XP SP2 em um cliente e copiar os executáveis (pptpclnt.exe e pptpsrv.exe) para ambos servidores em questão. Neste caso é preciso copiar ambos tanto na empresa quando no parceiro e efetuar o teste em ambas direções, ou seja, hora um vai ser o cliente, hora o outro vai ser. Isso é necessário, pois ambos lados da VPN podem iniciar o pedido de conexão, então os servidores podem agir tanto quanto cliente quanto como servidor.

3.3. Análise

A coleta de dados foi fundamental para a determinação da causa raiz, porém o uso do utilitário PPTP Ping mostrou exatamente o que estava ocorrendo com mais nitidez do ponto de vista técnico. Vejamos a captura:

· O teste inicial foi usando o PPTPSRV no lado do parceiro e o PPTPCLNT no lado do da empresa. É feito um “3 Way Handshake” entre o servidor do parceiro e o servidor da empresa:

192.168.3.4 192.168.3.8 TCP TCP: Flags=.S......, SrcPort=1289, DstPort=1723, Len=0, Seq=640629435, Ack=0, Win=65535 (scale factor not found)

192.168.3.8 192.168.3.4 TCP TCP: Flags=.S..A..., SrcPort=1723, DstPort=1289, Len=0, Seq=4099648897, Ack=640629436, Win=16384 (scale factor not found)

192.168.3.8 TCP TCP: Flags=....A... , SrcPort=1289, DstPort=1723, Len=0, Seq=640629436, Ack=4099648898, Win=65535 (scale factor not found)

· Em seguida a transmissão é feita na porta TCP 1723 e a resposta é feita com sucesso:

192.168.3.4 192.168.3.8 TCP TCP: Flags=...PA..., SrcPort=1289, DstPort=1723, Len=2, Seq=640629436 - 640629438, Ack=4099648898, Win=65535 (scale factor not found)

+ Ethernet: Etype = Internet IP (IPv4)

+ Ipv4: Next Protocol = TCP, Packet ID = 25870, Total IP Length = 42

- Tcp: Flags=...PA..., SrcPort=1289, DstPort=1723, Len=2, Seq=640629436 - 640629438, Ack=4099648898, Win=65535 (scale factor not found)

SrcPort: 1289

DstPort: 1723

SequenceNumber: 640629436 (0x262F3ABC)

AcknowledgementNumber: 4099648898 (0xF45BAD82)

+ DataOffset: 80 (0x50)

+ Flags: ...PA...

Window: 65535 (scale factor not found)

Checksum: 59567 (0xE8AF)

UrgentPointer: 0 (0x0)

PPTPPayload: Binary Large Object (2 Bytes)

192.168.3.8 192.168.3.4 TCP TCP: Flags=...PA..., SrcPort=1723, DstPort=1289, Len=46, Seq=4099648898 - 4099648944, Ack=640629438, Win=65533 (scale factor not found)

+ Ethernet: Etype = Internet IP (IPv4)

+ Ipv4: Next Protocol = TCP, Packet ID = 3079, Total IP Length = 86

- Tcp: Flags=...PA..., SrcPort=1723, DstPort=1289, Len=46, Seq=4099648898 - 4099648944, Ack=640629438, Win=65533 (scale factor not found)

SrcPort: 1723

DstPort: 1289

SequenceNumber: 4099648898 (0xF45BAD82)

AcknowledgementNumber: 640629438 (0x262F3ABE)

+ DataOffset: 80 (0x50)

+ Flags: ...PA...

Window: 65533 (scale factor not found)

Checksum: 64939 (0xFDAB)

UrgentPointer: 0 (0x0)

PPTPPayload: Binary Large Object (46 Bytes)

· A segunda etapa dos testes realizado por esta ferramenta é a tentativa de acesso para o protocolo GRE (47). O resulta é mostrado abaixo:

192.168.3.4 192.168.3.8 GRE GRE: Protocol = 0x6c6c, Flags = .RK.s........... Version 1

+ Ethernet: Etype = Internet IP (IPv4)

+ Ipv4: Next Protocol = GRE, Packet ID = 25873, Total IP Length = 52

- Gre: Protocol = 0x6c6c, Flags = .RK.s........... Version 1

- flags: .RK.s........... Version 1

C: (0...............) Checksum Absent

R: (.1..............) Offset Present

K: (..1.............) Key Present

S: (...0............) Sequence Number Absent

ssr: (....1...........) Strict Source Route Present

Recur: (.....000........) Recursion Control

A: (........0.......) Acknowledgment sequence number Absent

ReservedFlags: (.........1100...)

Version: (.............101) 5

NextProtocol: 0x6c6c

Este pacote é enviado seis vezes do parceiro para o servidor ISA da empresa e o servidor ISA não responde. Revendo os traces do servidor ISA é possível notar que a tentativa de conexão GRE nunca chegou de fato na placa externa do servidor ISA.

4. Conclusão

Após este teste ficou claro que o modem na realidade é muito mais que apenas um simples modem. O cliente revisou a configuração do modem via uma simples interface web disponível no modem e pode ver o mesmo funcionava como roteador e firewall. Porém, o firewall do modem era muito simples e apenas permitia o filtro / mapeamento de portas TCP e UDP, não permitindo a configuração de regras por protocolo (por exemplo pelo protocolo 47 – GRE). Com isso ficou explicado o comportamento mostrado nas capturas de rede, ou seja, vimos que a conexão na porta 1723 TCP acontecia, porém a negociação GRE era iniciada por um lado (parceiro) mas o servidor da empresa nem chegava a receber este pacote.

Este tipo de exemplo é muito importante na prática, como dito anteriormente muitas vezes não é que o cliente esteja tentando ocultar o fato do Modem ter mais funcionalidades, na realidade muitas vezes nem ele mesmo sabe se o Modem (ou outro equipamento) tem tais funcionalidades que podem impactar na comunicação. Por isso é de suma importância que o engenheiro de suporte entre em cena para clarificar o cenário e validar se as informações repassadas estão realmente corretas.

Como recomendação adicional para cenários onde o ISA Server está atrás de um Modem DSL ou Cable Modem veja o artigo “How to use the Windows Server 2003 Routing and Remote Access Service or ISA Server 2006 or ISA Server 2004 with a DSL router for Internet Access” no Microsoft Technet.