☰

127.xxx 시리즈의 연결 문제

tag-icon • tag-icon networking linux-networking linux-kernel ip-routing loopback
127.xxx 시리즈의 연결 문제

스택 교환의 네트워크 엔지니어링에서 이것을 물었고 여기로 리디렉션되었습니다.

아래 구성을 가진 두 대의 서버가 있습니다

서버1:

eno1: 127.15.0.1/16 scope global
eno2: 5.0.0.1/24

서버2:

lo: 127.0.0.1/16 (it had /8. I changed the subnet mask using 'ip addr del 127.0.0.1/8 dev lo; ip addr add 127.0.0.1/16 dev lo')
eno2: 5.0.0.2/24

server1의 eno1은 완전히 다른 L2 네트워크에 연결되어 있으며 완전히 격리되어 있습니다.

두 서버의 eno2 인터페이스는 동일한 L2 네트워크에 연결됩니다. 이제 server2에서 127.15.0.1에 액세스해야 합니다.

Server1은 오래 전에 배포되었으며 어떤 종류의 구성도 변경할 수 있는 권한이 없습니다. 왜 어떤 사람이 전역 범위의 127.xxx 서브넷을 사용했는지 모르겠습니다. 유효한 구성인지는 확실하지 않지만 계속해서 사용해야 합니다. 나는 server2를 완벽하게 제어할 수 있으며 무엇이든 변경할 수 있습니다.

두 서버 모두 Linux 기반입니다.

5.0.0.1 <-> 5.0.0.2 간의 연결성이 좋습니다.

내 첫 번째 시도는 아래와 같이 server2에 경로를 추가하는 것이었습니다.

ip r은 server2에서 5.0.0.1 ping 127.15.0.1을 통해 127.15.0.1/32를 추가합니다. server2의 tcpdump에서 ping 요청 및 응답을 볼 수 있지만 ping 명령은 100% 손실을 표시합니다.

rp_filters를 비활성화했습니다.

sysctl.cnf:

net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.lo.rp_filter=0
net.ipv4.conf.eno2.rp_filter=0

sysctl.conf 업데이트 후 재부팅

그리고 나는 iptables를 플러시했습니다. (iptables -F)

같은 결과. 나는 server2가 127.xxx 시리즈를 사용하는 것을 좋아하지 않을 것이라고 생각했습니다. 그래서 서버 2에 아래 규칙을 추가했습니다.

iptables -t nat -A OUTPUT  -d 5.0.0.1 -j DNAT --to-destination 127.15.0.1

이 규칙은 패킷의 목적지가 5.0.0.1인 경우 대상 IP를 127.15.0.1로 대체해야 합니다.

server2에서 5.0.0.1로 핑을 보냈습니다. Iptables는 대상 IP를 127.15.0.1로 대체했습니다(server1 tcpdump에서 확인됨). Server1이 응답했지만 응답이 다시 삭제되었습니다.

이 시점에서 아이디어가 부족했습니다. 유지 관리를 위해 server1을 중단하고 127.15.0.1/26을 192.168.1.1/16으로 교체했습니다. 이 경우에는 연결이 제대로 작동했습니다(iptable 유무에 관계없이). 이제 문제는 127.xxx 사용으로 인해 문제가 발생하는 것입니까? 그렇다면 탈출구가 있나요?? 그렇지 않다면 무엇을 더 시도해 볼 수 있나요?

참고: 이 구성은 이전에도 작동했습니다. 우리는 최근에 server2(오래된 Linux가 있음)를 잃어버렸고 처음부터 새로 구축하고 있습니다. 또한 Windows는 루프백 이외의 인터페이스에 127.xxx를 사용하는 것을 허용하지 않습니다. Linux가 lo가 아닌 인터페이스에서 왜 이를 허용하는지 잘 모르겠습니다. 근거가 있을 수도 있겠네요!

요약하면 다음과 같은 질문이 있습니다.

  1. Windows는 127.xxx를 구성하려고 할 때 구성을 완전히 거부하지만 Linux는 전역 범위에서도 이를 허용합니다. 이것에 대한 사용 사례가 있습니까?
  2. 이 경우 server2는 127.xxx로 향하는 요청을 보내고 server1은 실제로 응답을 다시 보냅니다. 127.xxx만 있는 경우호스트 내부, 왜 링크를 통해 패킷을 보내는 걸까요??

답변1

Linux sysctl 플래그는 다음 위치에 있습니다.

/sys/net/ipv4/conf/*/route_localnet

그러한 패킷에 대한 합리적인 처리를 비활성화하는 것을 허용합니다.

Route_localnet - 부울

라우팅하는 동안 루프백 주소를 화성의 소스 또는 목적지로 간주하지 마십시오. 이를 통해 로컬 라우팅 목적으로 127/8을 사용할 수 있습니다. 기본값은 거짓

제정신인 사람 중 그런 일을 하는 사람은 거의 없기 때문에 요즘에는 이것이 작동할 수도 있고 작동하지 않을 수도 있습니다(저는 몇 년 전에 마지막으로 테스트했습니다).

아무거나 할당해주세요이 목적으로 예약됨(아마도 링크 로컬이지만 호스트 내부는 아님) 또는소유문제의 인터페이스에 대한 IP 공간.이 이상한 설정을 계속하면 특히 쉬운 대안이 있을 때 더 많은 문제가 발생할 뿐입니다.

관련 정보