다음과 같은 라우팅 테이블이 있다고 가정해 보겠습니다.
ffgrt@srv28:~$ ip -4 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet 14.2.13.24/32 scope global lo
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
inet 210.41.21.8/27 brd 210.41.21.31 scope global ens3
valid_lft forever preferred_lft forever
ffgrt@srv28:~$
ffgrt@srv28:~$ ip r
default via 210.41.21.30 dev ens3 onlink
210.41.21.0/27 dev ens3 proto kernel scope link src 210.41.21.8
ffgrt@srv28:~$
14.2.13.24
서버에서 연결을 설정할 때 언제 루프백 인터페이스에 구성된 주소를 소스 주소로 사용합니까? 적어도 따르면본 소스 주소 선택 가이드, 14.2.13.24
이 주소는 다음과 같은 이유로 수동으로 바인딩하는 경우에만 선택해야 합니다.
210.41.21.0/27
네트워크 에 연결하면 커널은src
선택된 라우팅 경로의 힌트를 사용합니다.210.41.21.8
제 경우에는- 이 이외의 다른 네트워크에 연결하면
210.41.21.0/27
커널은 대상 주소 또는 다음 홉 라우터와 동일한 네트워크에 있는 인터페이스에 구성된 첫 번째 주소를 선택합니다. 다음 홉 라우터는 via를 통해 도달할 수ens3
있고 구성ens3
만 되어 있으므로 사용됩니다.210.41.21.8
210.41.21.8
인터페이스에 구성된 IPv4 주소는 수동으로 바인딩할 때만 나가는 연결의 소스 주소로 사용됩니까 lo
?
답변1
왜 작동하는가?
리눅스, 약한 사용호스트 모델, 모든 인터페이스에 할당된 모든 IP 주소를 전체 호스트에서 사용할 수 있도록 하므로 다른 인터페이스에서도 볼 수 있습니다.
따라서 다른 라우팅 조건이 IP 주소에 도달하도록 허용하는 경우 루프백 인터페이스에 IP 주소를 할당하는 것이 작동할 수 있습니다(예: 장애 조치 IP 주소를 제공하는 데이터 센터의 라우터에 분명히 관련되지 않은 IP 주소에 대한 추가 경로가 정의되어 있음). IP 주소에 접근 가능하도록 만드세요. 호스트에 추가할 수 있습니다).
귀하의 경우에는 다음과 같은 일이 발생합니다(기본 인터페이스가 다음과 같다고 가정).이더넷 0게이트웨이는MyGW):
1학기:
# ip address add 14.2.13.24/32 dev lo
term2(이전 명령보다 먼저 실행):
$ ip -4 monitor
1: lo inet 14.2.13.24/32 scope global lo
valid_lft forever preferred_lft forever
local 14.2.13.24 dev lo table local proto kernel scope host src 14.2.13.24
^C
$ ip route get from 14.2.13.24 8.8.8.8
8.8.8.8 from 14.2.13.24 via mygw dev eth0 uid 1000
$ ip route get from 8.8.8.8 iif eth0 14.2.13.24
local 14.2.13.24 from 8.8.8.8 dev lo
cache <local> iif eth0
라우팅은 다음과 같은 경우 양방향으로 작동할 수도 있습니다.MyGW이 트래픽은 라우팅될 수도 있습니다.
이 IP 주소를 다음에 할당하십시오.루오호스트에 다른 IP 주소를 추가하기만 하면 됩니다. 장점은 기본 인터페이스를 닫았다가 열 때 사라지지 않고 해당 주소를 할당할 수 있는 인터페이스를 추측할 필요가 없으므로 일부 스크립팅이 단순화된다는 것입니다.루오항상 사용 가능하며 일반적으로 사용 가능합니다.
바인딩 없이 이 주소를 사용하는 방법
OP가 이미 작성한 것처럼 선택한 경로는 대상에 도달하는 데 사용되는 인터페이스의 기본 IP 주소를 사용하기 때문에 이 주소는 기본적으로 사용되지 않습니다.루오이 인터페이스는 절대 아닙니다(묵시적 소스인 14.2.13.24 자체는 제외).
해당 주소를 전체 또는 일부 대상의 소스로 선택하도록 라우팅을 조정할 수 있습니다.
대상의 예:
# ip route add 8.8.8.8 via mygw dev eth0 src 14.2.13.24
8.8.8.8로 전송된 패킷은 다른 IP 주소에 바인딩되지 않는 한 기본적으로 14.2.13.24로 설정됩니다. 기존 경로를 바꾸거나 덮어쓰고 이 주소를 중요한 곳마다 기본 소스로 사용할 수 있습니다.
애플리케이션이 여러 주소를 처리하는 방법
어떤 경로도 이 주소를 소스로 선택하지 않으면 클라이언트로서 명시적으로 이 주소에 바인딩하여 이 주소에서 트래픽을 보내야 합니다.바인딩(2)예를 들어 사용하기 전에연결(2).
서버(리스닝 서비스)로서 다음 사항에 따라 달라집니다.
TCP 서비스는 추가 작업 없이 평소대로 실행됩니다. 즉, 연결이 수신된 IP 주소에서 응답합니다.
UDP 서비스에는 추가적인 주의가 필요합니다. 이는 주소에만 국한되지 않습니다.루오그러나 이는 할당된 인터페이스가 아닌 다른 인터페이스에서 연결할 수 있는 IP 주소가 일부 이상 있는 모든 멀티홈 시스템에 적용됩니다.
해당 주소에 바인딩하고 해당 주소에 대한 패킷만 수신할 수 있으며 응답은 바인딩된 주소를 소스로 사용합니다. 명시적 바인딩이 없으면 기본 인터페이스의 주소가 선택되고(예: 14.2.13.24 대신 210.41.21.8) 원래 클라이언트는 해당 주소가 쿼리와 일치하지 않기 때문에 응답을 거부합니다.
여전히 바인딩을 선택하는 경우INADDR_ANY, 그러면 수신된 데이터 패킷의 주소를 미리 알 수 없으며(예: 210.41.21.8 또는 14.2.13.24?) 커널은 기본적으로 기본 인터페이스의 IP 주소를 응답으로 선택합니다. 그런 다음 애플리케이션은 다르게 작동해야 합니다. Linux에서는 다음과 같이 설정해야 합니다.IP_PKTINFOUDP 소켓에 대한 옵션(사용setockopt(2)) 그런 다음 사용메시지 수신(2)보조 정보를 받다in_pktinfo받은 현지 주소를 알려주세요. 그런 다음 애플리케이션은 다음을 사용하여 이 정보의 일부를 재사용할 수 있습니다.메시지 보내기(2)(소켓을 바인딩하지 않고) 보낼 소스 주소를 커널에 알려줍니다. 복잡합니다. 예를 들면 다음과 같습니다.UDP 소켓의 소스 IP 설정. (*BSD에서는IP_RECVDSTADDR같은 방법으로 사용됩니다).
답변2
에 나가는 연결이 없습니다 lo
. 이는 소스 주소가 될 수 없습니다. 다른 장치는 연결되어 있지 않습니다.
제가 생각할 수 있는 유일한 사용 사례는 네트워크/다른 서버가 있고 14.2.13.24
동일한 서버 소프트웨어가 현재 장치에서 실행되고 있는 경우입니다. 온라인 서버에서 실험하지 않고 구성을 테스트하려고 합니다. 서버의 주소를 lo
로컬 서버에 할당하고 요청을 통하지 않고 해당 서버로 보냅니다 ens3
(그리고 이에 대한 라우팅을 설정해야 합니다). 그런 다음 테스트를 위해 DNS 항목(또는 /etc/hosts
)을 변경하지 않고 로컬로 연결할 수 있습니다.
로컬에서 테스트를 마친 후 설정을 실제 설정으로 전송하고 14.2.13.24
주소를 제거하면 lo
(희망적으로) 작동할 것입니다.