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


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.


 


 

Comments (0)