☰

두 개의 NIC 및 인터페이스 간 라우팅

tag-icon • tag-icon networking server dns
두 개의 NIC 및 인터페이스 간 라우팅

두 개의 서로 다른 서브넷에서 두 개의 NIC를 실행하고 그 사이를 라우팅하는 Ubuntu 서버에 문제가 있습니다. 우리는 공용 서브넷과 개인 서브넷이 있는 역방향 프록시로 Nginx 서버를 실행하고 있습니다.

우리는 우분투 서버 15.04를 실행하고 있습니다.

설정은 다음과 같습니다.

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)

eth0에 게이트웨이가 있습니다.

10.150.200.xx 서브넷의 서버에서 89.21.20.14에 ping을 시도하면 작동하지 않고 통신할 수 없습니다. 내가 볼 수 있듯이 트래픽이 eth0에 도달하고 있습니다.

sudo tcpdump -i eth0 proto \\icmp

또한 89.21.20.xx의 서버에서 동일한 작업을 수행하고 10.150.200.50에 액세스/핑하려고 시도했지만 그 중 하나도 진행되지 않았습니다. tcpdump를 실행할 때 eth1에 도달하는 ping을 볼 수 있습니다.

문제는 개인 서브넷 웹 서버에서 실행되는 웹 사이트가 있고 89.21.20.xx의 공용 IP를 가리키는 도메인을 참조하므로 사이트/응용 프로그램과 통신할 수 없다는 것입니다.

일종의 라우팅 문제인 것 같은데 어디서부터 시작해야 할지 잘 모르시나요?

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

답변1

서브넷 순회를 원하지 않는다고 의견에 명시했습니다. 그러면 이미 이 문제가 발생하여 eth0에서 접근할 수 없거나 eth1그 반대의 경우도 마찬가지이므로 문제는 이미 해결되었습니다.

하지만 다른 질문이 있는 경우에는 질문하는 내용을 좀 더 구체적으로 설명해야 합니다. (역방향 프록시는 투명하게 발생하므로 역방향 프록시 서버를 통하지 않고는 그 반대로 eth0접근 할 수 없습니다 .)eth1nginx

아래 내용은 역사적인 이유로 보관됩니다.

태그가 붙은 이유가 궁금합니다., 이는 NGINX 문제가 아니기 때문에 라우터(또는 라우터로 구성된 시스템)가 없거나 라우터 없이 내부 ( eth1및 내부 서브넷 ) 에서 외부( 및 공용 인터넷)로 이동하려고 한 경우입니다. eth0'서버'가 내부에서 외부로 프록시 역할을 하도록 하는 규칙입니다(역방향 프록시가 아님).

NGINX는 프록시나 라우터가 아닙니다. 역방향 프록시는 "좋습니다. 이 요청을 백엔드 abc로 보냅니다."라고 말합니다. 그런 다음 "ABC: Send me the response"라고 말하며 외부에서 이루어진 초기 요청을 내부 서버로 보냅니다. 그런 다음 nginx 서버의 백엔드 'abc'로부터 응답을 받습니다. 이는 nginx에 의해 요청 클라이언트에게 반환됩니다.

역방향 프록시는 외부 -> 내부에서만 작동합니다. 이 다이어그램은 기본적으로 외부에서 내부로 들어가는 모습을 보여줍니다.

서둘러 그린 다이어그램 - Thomas W.

역방향 경로는 작동하지만 역방향 프록시 시스템(nginx)이 백엔드의 응답을 기다린 다음 해당 데이터를 웹 브라우저나 원격 클라이언트에 다시 전달하여 정보를 요청하고 응답을 기대하기 때문입니다.

그러나 역방향 경로는 원격 프록시 시스템을 통해 eth1역방향 프록시 에서 eth0역방향 프록시로 이동하는 것을 허용하지 않습니다. 이는 IP 라우팅이 작동하는 방식이 아니며 달성하려는 목표를 달성하려면 다음이 필요합니다.진짜내부 IP에서 외부로의 네트워크 통과를 처리한 다음 eth0역방향 프록시 상자의 공용 IP 주소로 다시 돌아갈 수 있는 라우터가 있으므로 다음과 같습니다.

라우터 방식, Thomas W.의 또 다른 다이어그램

여기서 데이터 순회는 내부 상자에서 연결된 라우터 상자를 거쳐 인터넷으로 나온 다음 인터넷에서 다시 eth0상자로 이루어집니다. (물론 이것을 설명하는 가장 기본적인 방법입니다).

그러나 역방향 프록시 상자는~ 아니다라우터 역할도 겸하므로 생각한 대로 작동하지 않습니다.

또 다른 참고 사항:

eth1내부(로 이동 ) 에서 eth0직접 ping을 수행할 수 없습니다 .완전히 다른 서브넷실제 라우터를 통과하고 밖으로 나갔다가 다시 들어오지 않는 한. nginx가 있는 서버를 라우터로 설정하지 않는 한, 귀하의 의견에 따르면 그렇지 않은 것 같습니다. 따라서 "인터페이스와 서브넷 간에 ping을 수행할 수 없습니다"는예상되는 동작.

관련 정보