☰

apipa와의 인터페이스(예: 169.254.xx)

tag-icon • tag-icon networking routing networkmanager internet tcp-ip
apipa와의 인터페이스(예: 169.254.xx)

두 개의 인터페이스(eth0 및 eth1)가 있는 우분투 시스템이 있습니다. Eth0 인터페이스에는 dhcp 주소가 있고 eth1에는 apipa(169.254.xx) 주소가 있습니다. eth1은 연결되어 있지 않으며 eth0은 로컬 네트워크에 연결되어 있습니다. 내 데스크톱(동일한 네트워크에 연결되어 있음)에서 169.254.xx 주소로 ping을 수행하고 scp 등을 수행할 수 있습니다.

어떻게 이럴 수있어? 라우팅이 활성화되지 않았습니다.

답변1

다시 한번 확인하기 위해:APIPAMicrosoft의 원래 명명법이며 다음과 같이 표준화되었습니다.IPv4 링크-로컬 주소의 동적 구성(IPv4LL).

일어날 수 있는 상황은 다음과 같습니다.

  • 데스크탑 자체에는 IPv4LL LAN에 대한 경로가 있으며 아마도 개인 LAN 192.168.1.0/24와 같이 Ubuntu가 사용하는 것과 동일한 DHCP를 통한 보다 "클래식" 경로에 추가될 것입니다.

  • 우분투 자체에는 IPv4LL 주소가 있습니다이더넷 1, 예를 들어 169.254.5.6

  • 데스크톱이 온라인(직접 액세스 가능)이므로 169.254.5.6을 찾는 경우 169.254.5.6에 대한 ARP 요청을 브로드캐스트로 보냅니다.

  • 우분투는 브로드캐스트를 수신합니다. Linux 호스트로서 다음과 같습니다.약한 호스트 모델: 인터페이스에 추가된 IP 주소는 해당 인터페이스가 아닌 호스트에 속합니다. 이는 IPv4에도 해당됩니다.그리고ARP의 경우 문서에 명시된 대로arp_filter환경:

arp_filter- 불리언 값

[...]

0-(기본값) 커널은 다른 인터페이스의 주소로 arp 요청에 응답할 수 있습니다.. 이는 잘못된 것처럼 보일 수도 있지만 성공적인 의사소통 가능성을 높이기 때문에 종종 의미가 있습니다. IP 주소는 특정 인터페이스가 아닌 Linux의 전체 호스트가 소유합니다.이 동작은 로드 밸런싱과 같은 보다 복잡한 설정에서만 문제를 발생시킵니다.

따라서 169.254.5.6에 할당된 ARP 요청에 응답합니다.이더넷 1,하지만 때이더넷 0요청하는 경우 사용이더넷 0이더넷 MAC 주소.

  • 이제 데스크탑은 레이어 2 이더넷 주소를 확인하고 ARP 테이블을 업데이트했으며 대상 MAC 주소가 Ubuntu의 eth0 MAC 주소인 Ubuntu의 169.254.5.6으로 IPv4 ICMP 에코 요청 패킷을 보냈습니다.

  • 약한 호스트 모델을 따르는 Ubuntu는 IPv4 ICMP 에코 응답 요청을 사용합니다. OP가 작동 중이라고 말했기 때문에 이는 다음을 의미합니다.

    • 데스크톱 소스 주소도 IPv4LL이며 Ubuntu에는 169.254.0.0/16 경로도 있습니다.이더넷 0측정항목이 더 낮으므로(동일한 경우 먼저 사용됨) 응답이 오른쪽에 표시됩니다.

    • 또는 데스크탑이 IPv4LL 소스를 사용하여 IPv4LL 주소 169.254.5.6을 쿼리하지 않으므로 Ubuntu의 IP 주소와 동일한 IP 네트워크(DHCP에서 설정)에 있을 가능성이 높습니다.이더넷 0Ubuntu는 오른쪽에서도 응답합니다(라우팅 테이블에 eth0에 192.168.1.0/24와 같은 항목이 있으므로). 이 경우(IPv4LL 소스 없음)는 다음으로 인해 발생합니다.RFC:

동일한 인터페이스에서 IPv4 링크-로컬 주소와 라우팅 가능 주소를 사용할 수 있는 경우
라우팅 가능한 주소는 새로운 통신의 소스 주소 로 선호되어야 합니다., 그러나 IPv4 링크 로컬 주소에서 전송되거나 IPv4 링크 로컬 주소로 전송된
패킷은 여전히 ​​예상대로 전달됩니다.

내가 설명에서 아무것도 놓치지 않았다고 가정하면, 어떤 경우일까요?

물론 이 동작이 완전히 옳은 것은 아닙니다. 각 브로드캐스트 도메인에는 자체 개인 IPv4LL LAN이 있어야 하며 주소를 다른 도메인으로 유출할 수 없기 때문입니다.

이것이 실제로 의미하는 바는 기본 구성을 가진 Linux 호스트가 여러 IPv4LL 네트워크(인터페이스당 하나)에 참여하는 경우 다른 시스템이 자체 IPv4LL 주소를 사용하는 것을 허용하지 않을 수 있다는 것입니다(확실하지 않음, 아래 참조). 또는 같은 쪽에 있지 않더라도 자체 IPv4LL 주소를 전환할 필요가 없습니다.영향 확인. 그러나 실제 애플리케이션에서는 약한 호스트 모델로 인해 기본적으로 위치를 입력하는 169.254.0.0/16에 대한 여러 경로가 있습니다.멀티호밍(잘못된) 구성. 일반적으로 하나의 경로만 작동합니다. 첫 번째 경로는 표시된 경로와 동일합니다 ip route show 169.254.0.0/16. 다른 것들은 유효한 ARP를 가질 수 있지만 유효한 IP 라우팅을 가질 수 없습니다. 이를 위해서는 호스트가 멀티호밍에 대해 올바르게 구성되어야 하며(이 경우 위의 "잘못된" 인터페이스로 전송된 ARP에 대한 응답이 중지되어 문제가 발생하지 않을 수 있음) IPv4LL과의 통합도 도움이 되지 않습니다. 대부분의 경우 링크 로컬 주소를 사용하려면 인터페이스가 포함되어야 하므로 IPv6에서는 이런 일이 발생하지 않습니다.

관련 정보