잘못된 도구를 사용하고 있을 수도 있지만 네트워크 네임스페이스는 거의 이상적인 선택인 것 같습니다.
청취 인터페이스나 주소를 지정할 수 없는 프로그램이 3개 있습니다("0.0.0.0"에서만 청취). 나는 이러한 서비스를 netns에 넣어 내부 주소(예: 192.168.3.0/24)만 볼 수 있도록 하여 외부 트래픽을 수신하지 못하도록 하고 싶습니다.
나는 "Local"이라는 netns를 만들고 기본 및 로컬 ns를 확장하는 veth를 만들었습니다. 예를 들면 다음과 같습니다.
ip link add veth1 type veth peer name vpe1
2개의 다른 물리적 인터페이스와 함께 veth1을 로컬 브리지(br0)에 바인딩했습니다. "brctl show br0"은 이제 eth0, eth5 및 veth1의 3개 인터페이스를 표시합니다.
다음으로 로컬 네트워크의 vpe1의 IP를 "129"로 설정했습니다. 테스트 결과 다른 호스트와 Local-ns의 bash-shell에서 ping을 실행할 수 있는 것으로 나타났습니다.오직로컬 네트워크의 호스트를 ping하는 기능.
하지만, progs(그 중 하나는 xinetd)는 서버의 로컬 네트워크 주소(브리지 주소 192.168.3.1)에 대한 호출을 제공하도록 설계되었습니다. "로컬 전용" 네임스페이스에 다른 IP가 있어도 "서버"의 서비스에 응답하지 않습니다.
몇 가지 다른 옵션을 시도했습니다. 먼저 네임스페이스 내의 "vpe1" IP에 동일한 호스트 이름을 부여한 다음 동일한 IP를 부여해 보았습니다. 아무것도 작동하지 않았거나 효과가 없었습니다.
개념적으로는 기본 네임스페이스를 복제한 다음 외부 인터페이스를 제거하는 서브넷을 갖는 것을 생각합니다. 이전에 모든 인터페이스를 볼 때와 마찬가지로 해당 프로세스가 로컬 인터페이스와 서비스 요청만 볼 수 있도록 합니다. 네임스페이스).
비록 이것이~인 것 같다프로세스 그룹에 서버 인터페이스의 다양한 논리적 보기를 제공하기 위한 별도의 네임스페이스를 위한 이상적인 장소로서 netns가 단순히 다른 "보기"('bind/named-speak' 사용)를 제공하도록 하는 방법을 모르겠습니다. 그 "고객".
Linux의 네트워크 네임스페이스를 사용하여 이를 달성할 수 있습니까? 아니면 이를 달성하기 위해 뭔가를 놓치고 있는 걸까요? 네임스페이스가 이러한 유형의 "세분화"를 제공하지 않는 경우 기본 네임스페이스에서 클라이언트 프로그램을 에뮬레이트하기 위해 많은 iptable 라우팅 없이 이를 제공할 수 있습니까?
감사해요! 아☆아
답변1
간단히 말해서 Linux 네트워크 네임스페이스는 격리된 IP 스택입니다. 네트워크 네임스페이스와 같은 가상적인 것들은 잊어버리고 자문해 보십시오. 라우터, 호스트, 브리지 박스 및 이더넷 케이블을 사용하여 작업을 어떻게 해결할 수 있습니까? 물리적 설정이 있는 경우 거의 자연스럽게 가상 트윈으로 변환됩니다. 그러나 패킷 필터링 규칙을 잊지 마십시오. 이것이 핵심이 될 수 있습니다.
나는 당신의 임무가 정확히 무엇인지 완전히 이해하지 못합니다. 그러나 한 가지가 내 관심을 끌었습니다. 물리적 네트워크 인터페이스를 연결하는 브리지와 다른 네트워크 네임스페이스(IP 스택)에 연결하는 Veth 케이블이 전혀 원하는 것이 아닐 수도 있기 때문입니다. 이는 누구나 브리지를 통해 전체 레이어 2 액세스 권한을 가질 수 있음을 의미합니다. 이 수준에서는 IP 주소가 중요하지 않습니다. 별도의 네트워크 네임스페이스에 전체 직접 네트워크 액세스 권한을 부여할 수 있습니다. 그 자체로는 아무런 문제가 없습니다(사실 저는 개인적으로 그것이 매우 도움이 되는 몇몇 상황을 알고 있습니다). 하지만 이것이 당신이 원하는 상황입니까?