Firewall Friendly VPN V5R4

la fois le client et le serveur. Outre le respect des standards IETF, i5 a également résolu certaines difficultés techniques sur les serveurs que IETF a laissés à l’implantation locale. Voyons cela plus en détail.

Plusieurs clients peuvent envoyer des données au serveur simultanément, et les clients cachés derrière les pare-feu peuvent avoir des adresses IP en double, entraînant des conflits. Dans des environnements réseau compliqués, les conflits dus à des adresses IP et/ou des ports en double peuvent provenir de diverses sources. Comme le montre la figure 5, les passerelles locales (GW1 et GW3) derrière le parefeu N1 et N2 peuvent avoir des adresses IP en double. Tout comme d’ailleurs les clients situés derrière différentes passerelles.

Quand les paquets entrants atteignent le serveur, certaines de leurs identités sont éliminées après avoir été traitées. Après que les paquets entrants soient arrivés au serveur, l’IP source et le port source (c’est-à-dire le port source UDP provenant de l’entête d’encapsulation UDP), les identificateurs critiques pour les clients derrière NAT sont éliminés pendant la désencapsulation UDP. Si un mode tunnel est utilisé pour le cryptage, l’information de passerelle est éliminée pendant le décryptage. Si certaines de ces identités ne sont pas sauvegardées dans le processus entrant ou ne peuvent pas être correctement restaurées dans le processus sortant, les paquets sortants à partir du serveur ne peuvent pas être envoyés au bon client.

System i résout avec bonheur ce problème et le serveur peut traiter des connexions VPN simultanées provenant de clients multiples derrière des pare-feu quand le trafic TCP/UDP s’écoule, comme le montre la figure 5. Pour obtenir le même niveau de simultanéité de connexion pour d’autres genres de trafic, il est conseillé d’utiliser L2TP/VPN ensemble, entre les clients et le serveur.

À cause du NAT et du processus de cryptage, le serveur a du mal à travailler avec les protocoles de communication de bout en bout (comme TCP). Quand le client crypte un paquet TCP (comme dans la moitié supérieure de la figure 4), le total de contrôle TCP est basé sur les adresses IP du client et du serveur. Le paquet passe alors par toutes les étapes sortantes que montre la figure 4. Après l’étape 5, le paquet a l’adresse IP de l’unité NAT comme son adresse IP source. Si le cryptage/décryptage utilise le mode transport, le total de contrôle TCP échoue sur le serveur. Le serveur vérifie que le paquet vient de l’origine authentifiée (le client) et que l’IP source est changé correctement après NAT. Le réseau réajuste le total de contrôle TCP pour corriger les discordances entre l’adresse IP source originale et l’adresse après NAT. Avec la solution Firewall Friendly VPN d’i5, TCP fonctionne normalement en mode transport IPsec.