AnonymousCoward
10/06/2015, 17h12
Le vrai problème n'est pas la communication entre les deux serveurs.
Le véritable problème c'est d'avoir un service que les clients peuvent joindre sur plusieurs adresses. Les connexions des clients arrivent sans trop de soucis jusqu'au service mais ensuite, quelle est l'adresse IP utilisée comme adresse d'origine des paquets de réponse ?
Les paquets TCP font partie d'une connexion, liée à l'adresse IP de réception de la demande de connexion. On évite donc le soucis.
Pour l'UDP, par contre, toute réponse se fait, par défaut, à partir de l'IP source pour la route par défaut.
Exemple (simplifié) d'une table de routage sous Linux :
La première ligne nous indique la route par défaut. La seconde ligne nous indique que pour joindre 192.168.1.1 , l'adresse source sera 192.168.1.5 .
Dans le cadre d'un service en UDP, les paquets de réponse auront donc comme origine une adresse IP différente de celle de réception, pour les paquets reçus sur une interface autre que celle pour la route par défaut.
Est-ce réellement un problème ? En tant que tel, un service UDP n'en a rien à cirer de l'adresse IP d'origine d'un paquet.
Mais le gros retard pris sur l'introduction d'IPv6 a rendu le NAT indispensable autant pour les particuliers (sur la box) qu'au niveau des opérateurs avec le CG-NAT. La majeure partie des machines sur Internet est située derrière du NAT.
Or, avec un client derrière du "Port Restricted Cone NAT" (comme le fait Linux), étant donné que le client n'aura jamais communiqué au préalable avec l'adresse IP différente, les paquets UDP provenant de cette IP différente seront dégagés / drop.
Existe-t'il une solution à cela ? Oui mais...
On peut s'arranger pour envoyer un paquet UDP en ayant une adresse IP source/d'origine de notre choix. Mais ce n'est pas pratique a programmer, y compris sous Linux. Une page qui en parle, avec du gros C qui tâche : setting-the-source-ip-for-a-udp-socket
Est-ce que c'est faisable dans ton cas ? Oui mais tu va souffrir comme jamais. Je te le garantis.
--
AnonymousCoward
Le véritable problème c'est d'avoir un service que les clients peuvent joindre sur plusieurs adresses. Les connexions des clients arrivent sans trop de soucis jusqu'au service mais ensuite, quelle est l'adresse IP utilisée comme adresse d'origine des paquets de réponse ?
Les paquets TCP font partie d'une connexion, liée à l'adresse IP de réception de la demande de connexion. On évite donc le soucis.
Pour l'UDP, par contre, toute réponse se fait, par défaut, à partir de l'IP source pour la route par défaut.
Exemple (simplifié) d'une table de routage sous Linux :
Code:
$ ip route show default via 192.168.1.1 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.5
Dans le cadre d'un service en UDP, les paquets de réponse auront donc comme origine une adresse IP différente de celle de réception, pour les paquets reçus sur une interface autre que celle pour la route par défaut.
Est-ce réellement un problème ? En tant que tel, un service UDP n'en a rien à cirer de l'adresse IP d'origine d'un paquet.
Mais le gros retard pris sur l'introduction d'IPv6 a rendu le NAT indispensable autant pour les particuliers (sur la box) qu'au niveau des opérateurs avec le CG-NAT. La majeure partie des machines sur Internet est située derrière du NAT.
Or, avec un client derrière du "Port Restricted Cone NAT" (comme le fait Linux), étant donné que le client n'aura jamais communiqué au préalable avec l'adresse IP différente, les paquets UDP provenant de cette IP différente seront dégagés / drop.
Existe-t'il une solution à cela ? Oui mais...
On peut s'arranger pour envoyer un paquet UDP en ayant une adresse IP source/d'origine de notre choix. Mais ce n'est pas pratique a programmer, y compris sous Linux. Une page qui en parle, avec du gros C qui tâche : setting-the-source-ip-for-a-udp-socket
Est-ce que c'est faisable dans ton cas ? Oui mais tu va souffrir comme jamais. Je te le garantis.
--
AnonymousCoward