다중 IP 호스트에서 아웃 바운드 연결을위한 IP 주소 지정


15

내 서버 중 하나 (Debian 5.0.6)에는 동일한 인터페이스에 두 개의 공용 ip 주소가 있습니다. 이것은 몇 달 동안 잘 작동했지만 갑자기 나가는 연결에 "잘못된"IP 주소를 사용하고 있습니다. 역방향 조회가 일치하지 않아 이메일에 스팸 포인트가 발생하기 때문에 이는 문제입니다.

eth0      Link encap:Ethernet  Hardware Adresse 00:1b:21:14:8e:9c  
          inet Adresse:81.169.180.51  Bcast:81.169.180.51  Maske:255.255.255.255
          inet6-Adresse: fe80::21b:21ff:fe14:8e9c/64 Gültigkeitsbereich:Verbindung

eth0:0    Link encap:Ethernet  Hardware Adresse 00:1b:21:14:8e:9c  
          inet Adresse:85.214.157.120  Bcast:85.214.157.120  Maske:255.255.255.255


Kernel-IP-Routentabelle
Destination     Router          Genmask         Flags Metric Ref    Use Iface
81.169.180.1    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
0.0.0.0         81.169.180.1    0.0.0.0         UG    0      0        0 eth0

현재 아웃 바운드 연결에 85.214.157.120을 사용하고 있습니다. 81.169.180.51을 사용하려면 어떻게해야합니까?

편집 : 255.255.255.255의 넷 마스크는 호스팅 회사의 설명서 및 DHCP 응답과 일치합니다. /etc/init.d/networking restart를 여러 번 호출하면 결국 아웃 바운드 연결을위한 올바른 ip-address가 생깁니다. 그러나 그것은 분명히 안정적인 솔루션이 아닙니다. /편집하다

편집 2 : 호스트 경로가 내 문제와 관련이 없도록 로컬 테스트 네트워크를 설정했습니다.

eth0      inet Adresse:192.168.0.2  Bcast:192.168.0.255  Maske:255.255.255.0
eth0:0    inet Adresse:192.168.0.3  Bcast:192.168.0.255  Maske:255.255.255.0

192.168.0.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0        192.168.0.1     0.0.0.0         UG    0      0        0 eth0

누구든지 소스 ip 주소 192.168.0.2가 아웃 바운드 tcp 연결에 사용되는지 확인하는 방법을 알고 있다면 고맙겠습니다. / 편집 2

답변:


24

기본 업데이트 :

ip route change default via 81.169.180.1 src 81.169.180.51

구성 확인 :

ip route list

1
재부팅 후이를 영구적으로 만드는 방법은 무엇입니까?
dezhi

3

bindbn의 대답은 좋지만 약간의 합병증을 발견했습니다.

1) bindbn이 말한대로 "ip route list"를 확인해야합니다. 목록의 다른 규칙이 기본 경로보다 우선 할 수 있습니다. 해당 규칙을 삭제하거나 약간 다른 규칙을 만들어야합니다.

2) ip 명령을 통해 수행 된 모든 변경 사항은 다음에 다시 부팅 할 때까지만 작동합니다. 이 답변은 소스 정책 라우팅 규칙을 영구적으로 추가하여 영구 유지하는 방법을 설명합니다.

요약하면, "up"또는 "post-up"행으로 실행해야하는 ip route 명령을 / etc / network / interfaces에 추가 할 수 있습니다. 해당 "아래쪽"줄을 추가하여 경로를 제거 할 수 있습니다.


1

바꿔보십시오

 allow-hotplug eth0

 auto eth0

물리적 인터페이스가 먼저 나타나도록해야합니다. eth0 : 0에 대한 allow-hotplug 항목을 변경하거나 변경하지 않아도됩니다.


1

호기심에서 IP 주소의 넷 마스크가 255.255.255.255 인 이유는 무엇입니까? 그것은 전체 주소가 네트워크라는 것을 의미하기 때문에 실제로 실현 가능하지 않습니다. 호스트를위한 공간이 없습니다. 브로드 캐스트 주소가 호스트 IP와 동일하다는 사실도 걱정되지만 넷 마스크 문제로 인한 것일 수 있습니다. 오히려 넷 마스크는 255.255.255.0이어야합니다.

동일한 서브넷에 두 개의 호스트를 제공하기 위해 수행 되었습니까? 각 인터페이스가 다른 서브넷에 있도록 간단하게 변경하는 것이 좋습니다. 255.255.255.128은 eth0과 게이트웨이 (81.169.180.1)를 동일한 서브넷에두고 eth0 : 0을 별도의 서브넷에 둡니다. 그러나 이는 eth0이 81.169.180.1-81.169.180.127 과만 통신 할 수 있음을 의미합니다. eth0 : 0은 129-254에서 시작합니다. 그러나 그것은 현재 설정이 왜 작동하는지 전혀 알 수 없습니다.

자, 이로 인해 위에서보고있는 문제가 발생합니까? 직접 링크를 볼 수 없지만 가능합니다.
확실히 내가 조정할 것입니다. 그래도 도움이되지 않으면 왜 이런 식으로 설정했는지 설명 할 수 있습니다.


편집 : 이 호스트에서 정상적으로 작동합니까, 아니면 다른 시스템 / OS입니까? 무엇이 바뀌었을 지 아십니까? 내가 묻는 이유는 Linux가 실제로 동일한 서브넷에 두 개의 인터페이스를 갖고 싶지 않기 때문입니다. 내 네트워크 에서이 작업을 수행하려고하면 화를 냈습니다. 네트워크 서비스를 재부팅 / 다시 시작할 때까지 올바른 IP에서이 작업을 수행했을 가능성이 높습니다. 그런 다음 잘못된 인터페이스를 사용하여 나타났습니다. 참조 : http://anders.com/cms/258

ifdowneth0 : 0을 시도한 다음 경로를 추가 한 다음 다시 시도 할 수도 있습니다 ifup. 올바른 IP가 사용되도록 보장 할 수 있습니다.

수동으로 추가하면 도움 이 dev eth0 수 있지만 경로가 올바르게 완료된 것처럼 나타납니다.


추가 편집 : 데비안의 최신 IP 관리 도구를 사용해보십시오 iproute 2. ( Secondary link )
인터페이스를 가져 오는 라인을 따라 보입니다 . ip link set eth0 up

ip addr add 192.168.0.2/24 dev ethe0
ip addr add 192.168.0.3/24 dev eth0

그런 다음
ip route add 10.0.0.0/16 via 192.168.0.2


--Christopher Karel을 사용 하여 라우팅 테이블을 설정하십시오.


255.255.255.255의 넷 마스크는 호스팅 회사의 문서 및 DHCP 응답과 모두 일치합니다. Google에 따르면 지점 간 네트워크에 255.255.255.255가있는 것이 일반적입니다. 내가 알 수있는 한, 호스팅 회사는 동일한 계층 2 브로드 캐스트 도메인에 신뢰할 수없는 호스트가있을 수있는 보안 위험을 감안할 때 포인트 투 포인트 네트워크를 사용하는 것은 다소 어리석은 일입니다.
Hendrik Brummermann

Wolfgangsz가 위에서 말했듯이 / 32는 점대 점 링크의 표준이 아닙니다. / 31을 수행 할 수 있지만 브로드 캐스트 및 네트워크 식별자를 제거합니다. 위에서 언급 한 '호스트 라우트'는 라우팅 테이블에서 사용되는 것을 나타냅니다. 예 : 네트워크가 아닌 특정 호스트에 대한 경로입니다. 따라서 라우팅 프로토콜 인 OSPF에 링크 한 RFC에서 발생합니다. 즉, ISP가 OS를 사용하여 지시한다고 확신하면 유지하십시오.
Christopher Karel

좋아, 몇 가지 수정 사항은 원래 문제에 도움이 될 수 있습니다.
Christopher Karel

-1

현재 설정이 실제로 작동하지 않아야합니다. 두 인터페이스의 넷 마스크는 255.255.255.255이므로 게이트웨이를위한 공간이 없습니다. 그러나 의미있는 트래픽을 전달하려면 서버에 게이트웨이가 필요합니다. 두 개의 공용 IP 주소를 제공하는 ISP는 두 IP 주소 모두에 대한 넷 마스크 및 게이트웨이 설정도 제공해야합니다.

예 (이것은 내 개인 서버이며 IP 주소는 실제입니다) :

커널 IP 라우팅 테이블
대상 게이트웨이 Genmask 플래그 지표 참조 사용 Iface
217.10.144.208 0.0.0.0 255.255.255.248 U 0 eth0
0.0.0.0 217.10.144.209 0.0.0.0 UG 0 eth0

서버 자체는 217.10.144.210에 있으며 게이트웨이와 동일한 서브넷에 있습니다 (그렇지 않으면 트래픽을 라우팅 할 수 없음). 아마도 ISP는 다른 고객들에게도 동일한 서브넷을 제공하고있을 것입니다.

해당 서버에 있고 게이트웨이에 핑을 수행하는 경우 "호스트에 대한 경로 없음"메시지가 표시되어야합니다.

ISP에 문의하여 올바른 설정을 얻은 다음 인터페이스 구성을 업데이트하고 네트워킹을 다시 시작한 후 다시 확인하십시오.


2
255.255.255.255의 넷 마스크는 호스팅 회사의 문서 및 DHCP 응답과 모두 일치합니다. Google에 따르면 지점 간 네트워크에 255.255.255.255가있는 것이 일반적입니다. 내가 알 수있는 한, 호스팅 회사는 동일한 계층 2 브로드 캐스트 도메인에 신뢰할 수없는 호스트가있을 수있는 보안 위험을 감안할 때 포인트 투 포인트 네트워크를 사용하는 것은 다소 어리석은 일입니다.
Hendrik Brummermann

지점 간 네트워크가있는 경우 넷 마스크는 255.255.255.252입니다. 이를 통해 두 개의 엔드 포인트를 구성하는 두 개의 호스트 (네트워크 주소 및 브로드 캐스트 주소)가 허용됩니다. 이러한 종류의 연결에 대한 일반적인 시나리오입니다. 귀하의 경우 다른 호스트는 다른 세계의 관문이 될 것입니다. 나는 당신이 구글에서 파는 것을 정말로 신경 쓰지 않지만, 이것이 TCP / IP 네트워킹이 작동하는 방식입니다. 그리고 그것은 분명히 당신을 위해 작동하지 않습니다. 나는 당신에게 결론을 내립니다.
wolfgangsz

고맙지 만이 부분은 완벽하게 작동합니다. :이 공식 인터넷 표준에 "호스트 경로"라고합니다 그런데 rfc-editor.org/rfc/rfc2328.txt
헨드릭 Brummermann

ifconfig eth0 192.168.0.2 mask 255.255.255.0 / ifconfig eth0 : 1 192.168.0.3 mask 255.255.255.0 / route add default gw 192.168.0.1
Hendrik Brummermann
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.