Deux cartes réseau et routage entre les interfaces
J'ai un problème avec un serveur Ubuntu qui exécute deux cartes réseau sur deux sous-réseaux différents et qui tourne entre eux. Nous utilisons un serveur Nginx en tant que proxy inverse avec un sous-réseau public et un sous-réseau privé.
Nous courons le serveur Ubuntu 15.04.
Voici la configuration:
eth0 Link encap:Ethernet HWaddr 00:50:56:88:6e:91
inet addr:89.21.20.14 Bcast:89.21.20.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fe88:6e91/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:89152 errors:0 dropped:0 overruns:0 frame:0
TX packets:1729 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5552124 (5.5 MB) TX bytes:286442 (286.4 KB)
eth1 Link encap:Ethernet HWaddr 00:50:56:88:16:0b
inet addr:10.150.200.50 Bcast:10.150.200.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fe88:160b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:549 errors:0 dropped:0 overruns:0 frame:0
TX packets:22 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:53395 (53.3 KB) TX bytes:1908 (1.9 KB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:160 errors:0 dropped:0 overruns:0 frame:0
TX packets:160 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:12960 (12.9 KB) TX bytes:12960 (12.9 KB)
J'ai la passerelle sur eth0.
Lorsque j'essaie d'envoyer un ping 89.21.20.14 à partir d'un serveur sur un sous-réseau 10.150.200.xx, il ne fonctionne pas et je ne peux pas communiquer avec lui. Le trafic frappe eth0 comme je peux le voir sur
Sudo tcpdump -i eth0 proto \\icmp
J’ai aussi essayé de faire la même chose depuis un serveur en 89.21.20.xx et un accès/ping 10.150.200.50, mais cela ne se fait pas non plus. Quand je lance tcpdump, je peux voir les pings frapper eth1
Le problème est que nous avons des sites Web fonctionnant sur les serveurs Web de sous-réseaux privés et qu'ils référencent des domaines qui pointent vers les adresses IP publiques sur 89.21.20.xx et ne peuvent donc pas communiquer avec les sites/applications.
Je pense que c’est un problème de routage, mais vous ne savez pas trop par où commencer?
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 89.21.24.1 0.0.0.0 UG 0 0 0 eth0
10.150.200.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
89.21.20.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 89.21.20.1 0.0.0.0 UG 0 0 0 eth0
10.150.200.0 * 255.255.255.0 U 0 0 0 eth1
localnet * 255.255.255.0 U 0 0 0 eth0
Vous indiquez dans les commentaires que vous ne voulez pas traverser le sous-réseau. Vous avez déjà ceci, alors, avec l'impossibilité d'atteindre eth0 de eth1 et vice-versa, votre problème est donc déjà résolu.
Si vous avez une autre question, cependant, vous devez être plus précis avec ce que vous demandez. (Le proxy inverse se produit de manière transparente, vous ne pourrez pas atteindre eth0 à partir de eth1 ou vice-versa, non sans passer par nginx sur le serveur proxy inverse).
Le ci-dessous est conservé pour des raisons historiques.
Je suis curieux de savoir pourquoi ceci est étiqueté nginx , parce que ce n'est pas un problème de NGINX, mais que vous essayez de passer de l'intérieur (eth1 et du sous-réseau interne) à l'extérieur (eth0 et Internet public) sans routeur (ni système configuré en tant que routeur) ni règle permettant à votre "serveur" d'agir en tant que proxy de l'intérieur -> à l'extérieur (ce qui n'est PAS un proxy inverse) .
NGINX n'est pas un proxy ou un routeur. Un proxy inverse dira "OK, alors envoyez cette demande au backend, abc." Ensuite, il sera écrit "ABC: Envoyez-moi la réponse", ce qui enverra la demande initiale faite de l'extérieur au serveur interne. Cela vous donne alors la réponse du backend 'abc' sur le serveur nginx. Cela est renvoyé par nginx au client demandeur.
Un proxy inverse fonctionne également uniquement à l'extérieur -> à l'intérieur. Ce diagramme montre essentiellement à quoi ça ressemble de l'extérieur à l'intérieur:
Le chemin inverse fonctionne, mais uniquement parce que le système de proxy inverse (nginx) attend la réponse du serveur, puis renvoie ces données au navigateur Web ou au client distant qui effectue la demande d'informations et attend une réponse.
Le chemin inverse, cependant, ne vous permet PAS de passer de eth1 sur le proxy inverse à eth0 sur le proxy inverse via le système de proxy distant. Ce n'est pas ainsi que fonctionne le routage IP. cherchez à obtenir, vous avez besoin d’un routeur réel capable de gérer la traversée du réseau depuis les adresses IP internes vers l’extérieur, puis de revenir à l’adresse IP publique de eth0 sur la boîte de proxy inverse, donc cela ressemblerait à ceci:
La traversée de données ici, alors, proviendrait des boîtes internes, du routeur auquel elles sont connectées, d’Internet, puis d’Internet vers votre boîte eth0. (Le moyen le plus simple d’expliquer cela bien sûr).
Cependant, votre boîte de proxy inverse et non == double un routeur, elle ne fonctionne donc pas comme vous le pensez .
D'un autre côté:
Vous ne recevez pas de ping depuis interne (qui passe à eth1) à eth0 directement, qui se trouve sur un sous-réseau complètement différent sauf si vous passez par un routeur réel et que vous sortez puis revenez dedans. Sauf si vous configurez votre serveur sur lequel nginx est également un routeur, ce qui, d'après vos commentaires, semble ne pas être le cas. Donc, ceci "n'est pas capable de faire un ping à travers des interfaces et des sous-réseaux" est comportement attendu .