![호스트 루프백을 수신하는 서비스를 LXC 게스트와 공유할 수 있는 방법이 있습니까?](https://linux55.com/image/36717/%ED%98%B8%EC%8A%A4%ED%8A%B8%20%EB%A3%A8%ED%94%84%EB%B0%B1%EC%9D%84%20%EC%88%98%EC%8B%A0%ED%95%98%EB%8A%94%20%EC%84%9C%EB%B9%84%EC%8A%A4%EB%A5%BC%20LXC%20%EA%B2%8C%EC%8A%A4%ED%8A%B8%EC%99%80%20%EA%B3%B5%EC%9C%A0%ED%95%A0%20%EC%88%98%20%EC%9E%88%EB%8A%94%20%EB%B0%A9%EB%B2%95%EC%9D%B4%20%EC%9E%88%EC%8A%B5%EB%8B%88%EA%B9%8C%3F.png)
LXC 게스트에게 서비스를 제공하려고 하는데 호스트에게 서비스를 노출시키고 싶지 않습니다. 또한 서비스에 대한 방화벽 규칙을 설정하고 싶지 않으므로 루프백이 가장 간단한 솔루션인 것 같습니다.
lo
바인드 마운트 디렉터리와 유사하게 LXC 게스트와 공유되는 서비스 수신(루프백) 방법이 있습니까 ?
답변1
목표를 달성하는 방법에는 여러 가지가 있습니다.
게스트가 가상 네트워크를 공유하는 경우(즉, 물리적 인터페이스에 브리지되는 것이 아님) 쉽습니다. 해당 인터페이스를 수신하도록 서비스에 지시하거나 새 게스트를 생성하여 서비스를 호스팅하도록 하세요.
게스트가 에 브리지되는 경우에도 ethX
가상 게스트 + 호스트 전용 인터페이스 생성을 고려할 수 있습니다. 이 캡슐화는 모든 유형의 서비스(내부 메일 서버, 데이터베이스 서버, 로컬 DNS 등)에 적합하기 때문입니다.
(분명히 어떤 이유로든 이 접근 방식을 포기했습니다: 방화벽 규칙)
lo
각 lxc 호스트에는 고유한 호스트가 있는데 제 생각에는 괜찮습니다 .
내 lxc 게스트는 모두 가상 인터페이스를 공유하고, 공용 인터넷에 노출되어야 하는 각 서비스에 대해 호스트의 iptables에 포트 전달 규칙을 만듭니다. 나는 호스트 자체에서 가능한 한 적은 수의 서비스를 실행하려고 노력합니다. 이렇게 하면 해커가 실수로 서비스를 노출할 가능성이 거의 없습니다.
완전성을 위해 내 구성은 다음과 같습니다.
내 interfaces
파일(Debian 안정):
auto br0
iface br0 inet static
bridge_maxwait 0
bridge_fd 0
bridge_ports dummy0
address 192.168.x.1
netmask 255.255.255.0
# if there are lxc clients that need a public IP, add something like this (a.b.c.d being the public IP) and set the client's `lxc.network.ipv4` config parameter to the same address:
#post-up route add a.b.c.d dev br0
클라이언트 구성의 관련 부분:
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.veth.pair = lxc-apache # each client gets their own .pair name
lxc.network.ipv4 = 192.168.x.y/24 # ... and of course their own address
답변2
또 다른 옵션은 마운트 unix domian 소켓을 바인딩하는 것입니다.
예를 들어 Linux 외부에서 fcgiwrap을 실행하고 컨테이너 내부에 소켓이 포함된 디렉터리를 마운트할 수 있습니다.
lxc.mount.entry = /mnt/outer /var/lib/lxc/mylxc/rootfs/mnt/outer none bind,create=dir 0 0
이를 통해 컨테이너는 잘못 구성된 방화벽으로 인해 실수로 인터넷에 노출될 위험 없이 Linux 외부 서비스에 액세스할 수 있습니다.
데이터가 한 방향으로만 흐르도록 하려면 fifo 소켓을 사용할 수 있습니다.