Les posts de travail Linux perdent par intermittence les connections internet

Il y a environ trois mois, un phénomène étrange s'est produit dans notre réseau.

Tout d'abord, permettez-moi de décrire la layout du réseau (seuls les détails que je pense que je serai autorisé à divulguer):

  • Nous avons un routeur qui établit une connection VPN sur Internet au réseau de notre client.
  • Checkpoint est utilisé pour la connection VPN
  • Je ne connais pas le model exact du routeur. Mais nos administrateurs informatiques s'y réfèrent en tant que "pare-feu Nokia"
  • Les posts de travail définissent leur passerelle vers l'adresse IP du routeur et leur donnent access à Internet et VPN.

Donc, il y a le problème:

Il y a environ quatre mois, les posts de travail Linux perdent par intermittence des connections Internet et VPN. Cela n'arrive pas aux posts de travail Windows. Le problème ne semble affecter que ceux qui s'exécutent sous Linux.

Nous pouvons voir que les packages sont envoyés à la passerelle mais aucune réponse n'est reçue. Cela dure environ 3-5 minutes, puis Internet et la connectivité VPN est rétablie. Nous ne voyons aucun motif sur l'événement. Ce problème se reproduit à intervalles allant de quelques secondes à quelques heures.

Pour écarter les posts de travail Linux comme étant le problème, nous avons essayé de passer quelques-uns d'entre eux à une passerelle différente. Un routeur simple (appelons-le GateWay-B). Le problème ne se produit pas lorsqu'une passerelle différente est utilisée.

Une chose que j'ai fait était de configurer les tables IP afin que:

  • Tous les packages liés aux posts de travail via le VPN, utilisez la passerelle "Nokia / checkpoint"
  • Tous les autres packages utilisent une autre passerelle; GateWay-B.

Avec cela, je ne perds plus la connection internet. Cependant, la connection VPN rest intermittente.

Question:

Est-ce que quelqu'un a une idée du problème? Est-il possible pour une passerelle de déterminer le operating system d'où provient un package entrant?

    Cela semble potentiellement une certaine confusion dans le cache arp.

    Une possibilité est que si le «pare-feu Nokia» fait partie d'une paire haute disponibilité (HA), des events de basculement ou d'équilibrage de charge peuvent se produire. S'il existe une paire HA et que l'un d'entre eux devient le pare-feu actif, le post de travail Linux peut continuer à envoyer des requests au mauvais pare-feu en raison d'une input de cache arp incorrecte.

    Vous pouvez facilement tester cela la prochaine fois que vous perdez la connectivité au site VPN. Assurez-vous que le packageage iproute installé sur le post de travail Linux. Exécuter ip neigh flush dev eth0 (en substituant l'interface correcte). Cela va temporairement effacer le cache arp jusqu'à ce qu'il repeuple, potentiellement avec l'adresse matérielle du pare-feu qui transmet correctement le trafic.

    Si vous pouvez déterminer quelle adresse matérielle transmet correctement le trafic, vous pouvez l'append en tant que mappage statique arp (bien que cela puisse potentiellement interrompre tout HA ou l'équilibrage de charge effectué par les pare-feu).

    En fin de count, cela devrait être indiqué au groupe responsable de la maintenance et de la configuration des pare-feu afin qu'il puisse être résolu.