Messages récents61
Actus Bouygues / Problème changement IP et IP partagée
« Dernier message par simon le Hier à 15:54:49 »
Ca dépend de la techno VPN utilisée (IPSec, OpenVPN, encapsulation propriétaire dans TLS, etc.), de la configuration des équipements (firewall qui drop les fragments et ICMP parce que le consultant en sécu a dit que c'était "dangereux") et du CG-NAT que tu traverses.
Un classique, c'est le CG-NAT qui ne NAT que TCP/UDP couplé aux concentrateurs IPSec qui ne font pas de nat-t (parce que la case est décochée, ils savent tous le faire): les paquets IPSec sont jetés, NATés que dans un sens, etc. et ca casse.
Un autre, c'est les soucis de MTU et les firewalls qui drop les fragments. Comme l'encapsulation MAP-T diminue la MTU, le CPE fragmente les paquets, les fragments sont NATés par le CG-NAT, mais le firewall de l'entreprise les drop. Comme le MSS clamping n'est pas applicable aux flux UDP, bien souvent, les VPN en font les frais.
Enfin, il y a les pertes de sessions dans les CG-NAT. Parfois parce qu'il reboot, parfois parce qu'il overflow, parce que les timers sont très courts pour, justement, libérer des entrées le plus rapidement possible, parce que le client est migré vers un autre CG-NAT en cours de session, etc. Si le VPN n'est pas configuré pour émettre un keepalive au moins toutes les 30s, ca créé des pertes de connectivité VPN aléatoires.
Ces soucis sont classiques sur le mobile, je ne serai pas étonné que ce soit la même chose sur le fixe (mais je n'ai pas fait de test avec l'implémentation MAP-T de Bouygues. Je le constate par contre fréquemment sur le mobile).
Beaucoup de soucis liés à la diminution de qualité de service d'IPv4 qui serait facilement évités en configurant les endpoints VPN d'entreprise en dual stack.
Et aussi en configurant correctement les firewalls et concentrateurs VPN, mais là... on en demande beaucoup
Un classique, c'est le CG-NAT qui ne NAT que TCP/UDP couplé aux concentrateurs IPSec qui ne font pas de nat-t (parce que la case est décochée, ils savent tous le faire): les paquets IPSec sont jetés, NATés que dans un sens, etc. et ca casse.
Un autre, c'est les soucis de MTU et les firewalls qui drop les fragments. Comme l'encapsulation MAP-T diminue la MTU, le CPE fragmente les paquets, les fragments sont NATés par le CG-NAT, mais le firewall de l'entreprise les drop. Comme le MSS clamping n'est pas applicable aux flux UDP, bien souvent, les VPN en font les frais.
Enfin, il y a les pertes de sessions dans les CG-NAT. Parfois parce qu'il reboot, parfois parce qu'il overflow, parce que les timers sont très courts pour, justement, libérer des entrées le plus rapidement possible, parce que le client est migré vers un autre CG-NAT en cours de session, etc. Si le VPN n'est pas configuré pour émettre un keepalive au moins toutes les 30s, ca créé des pertes de connectivité VPN aléatoires.
Ces soucis sont classiques sur le mobile, je ne serai pas étonné que ce soit la même chose sur le fixe (mais je n'ai pas fait de test avec l'implémentation MAP-T de Bouygues. Je le constate par contre fréquemment sur le mobile).
Beaucoup de soucis liés à la diminution de qualité de service d'IPv4 qui serait facilement évités en configurant les endpoints VPN d'entreprise en dual stack.
Et aussi en configurant correctement les firewalls et concentrateurs VPN, mais là... on en demande beaucoup
Énergie
Technologie mobile 4G
Matériel informatique (réseaux domestiques)