☰

지정된 인터페이스를 통해 IP 주소에 대한 트래픽 라우팅

tag-icon • tag-icon networking routing
지정된 인터페이스를 통해 IP 주소에 대한 트래픽 라우팅

고정 IP 주소(192.168.1.86)를 가진 장치가 있습니다. 또한 192.168.1.x를 사용하는 DHCP 네트워크가 있는데 해당 네트워크에서 192.168.1.86만 유지하는 것을 허용하지 않습니다. 메인 네트워크 및 고정 주소 장치와 통신할 수 있어야 하는 머신(브리지라고 함)이 있습니다.

A에는 두 개의 네트워크 어댑터가 있으므로 지금까지 수행한 작업은 DHCP를 사용하여 기본 네트워크와 통신하도록 인터페이스 하나를 구성하고 고정 주소 장치와 통신하도록 수동으로 다른 인터페이스를 구성하는 것뿐입니다. 그런 다음 한 인터페이스를 활성화하고 다른 인터페이스를 비활성화하여 언제든지 둘 중 하나와 통신할 수 있습니다. 이것은 분명히 매우 투박하고 때때로 좌절스럽기까지 합니다.

인터페이스를 수동으로 활성화/비활성화하지 않고 이 작업을 수행할 수 있지만 192.168.1.86에 대한 모든 트래픽을 하나의 인터페이스로 자동으로 보내고 다른 주소로의 트래픽은 다른 인터페이스에서 전송되기를 원합니다. 예, 그렇게 할 수 있다면 해당 브리지 머신은 더 이상 메인 네트워크의 192.168.1.86과 통신할 수 없게 된다는 것을 알고 있습니다. 저는 괜찮습니다. 보너스로,회의브리지 머신을 통해 인터넷과 통신할 수 있는 고정 주소 장치를 얻을 수 있다면 좋을 것 같습니다.

이는 정적 경로여야 하는 것처럼 보이지만 전체 서브넷이 아닌 하나의 특정 주소에 대해 정적 경로를 설정하는 방법(또는 가능한지 여부)을 잘 모르겠습니다(특히 해당 주소가 서브넷 내부에 있고 다른 인터페이스에서 처리됨)

그렇다면 192.168.1.86에 대한 트래픽을 하나의 인터페이스로 보내고 다른 주소에 대한 트래픽을 다른 인터페이스로 보내도록 브리지를 어떻게 구성할 수 있습니까?

브리지 머신(나머지 네트워크와 고정 주소 장치에 연결된 머신)은 CentOS 7을 실행하고 있습니다.

답변1

다음 명령을 사용하여 192.168.1.86에 호스트 경로를 추가합니다.

ip route add 192.168.1.86/32 dev eth1

여기서 eth1은 장치가 연결된 인터페이스입니다. 이 경로는 일반 192.168.1.0/24 경로보다 더 구체적이며 장치와 통신할 때 선택됩니다. 다른 호스트의 경우 일반 경로가 적용됩니다.

답변2

192.168.1.86 호스트에 추가 주소를 할당할 수 있는 경우 다음과 같이 처리할 수 있습니다.

현재 인터페이스 설정 목록을 얻으려면 192.168.1.86에서 "ifconfig -a"를 사용하십시오. 예:

# ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.86  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 00:21:f6:41:94:37  txqueuelen 1000  (Ethernet)
        RX packets 68267884  bytes 20871214051 (19.4 GiB)
        RX errors 0  dropped 3485  overruns 0  frame 0
        TX packets 5758238  bytes 843203020 (804.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1  (Local Loopback)
        RX packets 1663  bytes 508496 (496.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1663  bytes 508496 (496.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions

제 경우에는 eth0을 인터페이스로 사용합니다. lo(루프백) 인터페이스를 무시할 수 있습니다.

이 인터페이스에 주소를 추가하려면 다른 "하위" 인터페이스를 구성하고 주소와 넷마스크를 할당하면 됩니다. 예를 들어:

# ifconfig eth0:1 10.33.33.33 netmask 255.255.255.0 up

그러면 "eth0:1"이라는 새 인터페이스가 생성됩니다.

# ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.86  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 00:21:f6:41:94:37  txqueuelen 1000  (Ethernet)
        RX packets 68268140  bytes 20871241191 (19.4 GiB)
        RX errors 0  dropped 3485  overruns 0  frame 0
        TX packets 5758341  bytes 843217718 (804.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.33.33.33  netmask 255.255.255.0  broadcast 10.33.33.255
        ether 00:21:f6:41:94:37  txqueuelen 1000  (Ethernet)

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1  (Local Loopback)
        RX packets 1663  bytes 508496 (496.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1663  bytes 508496 (496.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

그런 다음 "브리지" 호스트에서 192.168.1.86 호스트와 통신해야 하는 인터페이스에 대해 해당 인터페이스가 10.33.33.x 네트워크(이 예에서는)에도 있도록 구성합니다(예: 10.33.33.1). .

이 시점에서는 더 이상 192.168.1.86 주소를 통해 192.168.1.86 호스트를 참조하지 않습니다. 이제 10.33.33.33을 통해 액세스할 수 있습니다.

이렇게 하면 "브리지된" 호스트의 두 인터페이스 모두에서 동일한 네트워크를 갖는 문제가 제거됩니다.

192.168.1.86 호스트에서 추가 인터페이스 정의를 영구적으로 만들려면 /etc/sysconfig/network-scripts에 ifcfg-eth0:1이라는 파일을 추가할 수 있습니다. 이 파일에는 다음과 유사한 내용이 포함될 수 있습니다.

TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
NAME=eth0
DEVICE=eth0:1
ONBOOT=yes
IPADDR=10.33.33.33
PREFIX=24

내 경우 인터페이스는 eth0입니다. 귀하의 의견은 다를 수 있으므로 필요에 따라 추정하십시오. 또한 내 예에서는 네트워크 10.33.33.x를 사용했지만 지정한 네트워크가 환경의 다른 곳과 충돌하지 않는지 확인해야 합니다. 일반적으로 10.xxx 네트워크는 매우 안전하므로 사용하지 않는 서브넷을 선택하세요.

정적 라우팅을 사용하라는 Johan의 제안은 간단하고 간단합니다. 브리지 호스트의 양쪽에서 동일한 네트워크를 참조해야 하는 혼란스러운 상황이 발생하지만 작동해야 합니다. 위의 제안은 실용적인 관점에서 "추악한" 이중 네트워크 문제를 제거하는 데 도움이 될 것입니다. 둘 중 하나가 귀하의 딜레마를 해결해야 합니다.

관련 정보