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.