현재 문제

현재 문제

저는 systemd-nspawn 컨테이너(Debian 9, 호스트도 Debian 9)를 실행 중이고 VirtualEthernet=yes일부 포트(예 Port=tcp:443:443: . 즉, 웹 서버는 컨테이너에서 실행되며 외부에서 액세스할 수 있어야 합니다.

방화벽을 활성화하면 ufw처음에는 잘 작동하는 것처럼 보이지만 몇 시간이 지나면 외부 세계가 컨테이너(각각 웹 서버)에 연결하지 못할 수도 있습니다. 이렇게 하면 ufw disable몇 초 후에 모든 것이 정상으로 돌아갑니다. 즉, 모든 것이 정상이지만 방화벽이 없습니다.

답변1

현재 문제

systemd-nspawn포트 전달 기능을 갖춘 웹 서버를 실행하는 컨테이너가 있습니다 . 잠시 후 비활성화할 때까지 더 이상 네트워크 연결이 불가능합니다 ufw. 몇 가지 조사를 했고 그 중 하나가 문제 해결에 도움이 되기를 바랍니다.

가능한 해결책

댓글로 남겨주신 피드백을 바탕으로 더 많은 조사를 했습니다. 브리지 인터페이스가 표준이 아닌 것 같다고 말씀하셨지만 systemd-nspawn컨테이너 구축에 관해 제가 읽은 모든 가이드에는 브리지 가상 인터페이스 설정이 포함되어 있습니다.

#1 Systemd의 네트워크가 올바른지 확인

따르다이 가이드, 나는 그들이 네트워크에 특별한 주의를 기울이고 있다고 언급한 것을 발견했습니다. systemd-nspawn컨테이너는 이에 의존 하므로 systemd호스트와 컨테이너가 올바른 네트워크를 사용하고 있는지 확인해야 합니다.

호스트에서 루트(sudo)로 다음 명령을 실행합니다.

systemctl disable network
systemctl disable networking
systemctl disable NetworkManager
systemctl enable systemd-networkd

systemd-networkd이제 서버가 네트워킹 에 사용되고 있는지 확인합니다 .

networkctl status lo

● 1: lo
   Link File: /lib/systemd/network/99-default.link
Network File: n/a
        Type: loopback
       State: carrier (unmanaged)
     Address: 127.0.0.1
              ::1

/lib/systemd/network/99-default.link을 사용하고 있는지 확인하려면 네트워크가 네트워크와 연결되어 있어야 합니다 systemd-networkd.

여기에서 네트워크 인터페이스를 만듭니다. 장치 이름을 올바르게 사용하십시오.

cat > /etc/systemd/network/[nameOfNetworkDevice].network <<EOF
[Match]
Name=[nameOfNetworkDevice]

[Network]
Bridge=br0
IPForward=1
EOF

이전에 사용한 인터페이스와 일치하도록 브리지 인터페이스를 만듭니다.br0

cat > /etc/systemd/network/br0.netdev <<EOF
[NetDev]
Name=br0
Kind=bridge
EOF

이제 브리지 인터페이스용 네트워크를 생성합니다.

cat > /etc/systemd/network/br0.network <<EOF
[Match]
Name=br0

[Network]
DHCP=ipv4
EOF

이제 네트워크를 다시 시작하고 sysV init 구성을 이동하여 충돌을 피하십시오.

systemctl restart systemd-networkd
mv /etc/network/interfaces /etc/network/interfaces.bak

systemd-resolved서비스를 시작합니다 .

systemctl enable systemd-resolved
systemctl start systemd-resolved
ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

다음으로 네트워크 연결 및 확인 서비스를 테스트합니다. 가장 쉬운 방법은 를 사용하는 것입니다 ping stackexchange.com. 이제 모든 것이 정상으로 돌아갑니다.

마지막으로 부팅 시 컨테이너가 시작되는지 확인하려고 합니다.

systemctl enable machines.target

금후관광 가이드컨테이너를 만드는 방법에 대한 설명은 계속해서 다루지 않겠습니다.

이제 이 모든 작업을 수행할 필요는 없지만 호스트 시스템에서 네트워크 구성이 설정된 방식 간의 충돌로 인해 문제가 발생할 수 있다는 점을 명심하십시오. 이러한 단계를 통해 호스트는 네트워크에 연결되고 충돌 없이 컨테이너에 브리지될 수 있습니다.

#2 컨테이너가 터지고 있습니다

몇 가지 문제를 발견했습니다(1,2,[) 네트워크 연결이 간헐적으로 끊어지는 컨테이너와 관련하여 GitHub에서 제기되었습니다.

따라서 다음 휴식 시간이 귀하에게 적용되는지 확인하십시오.

1

데비안에서 깨진 것들

도메인 명 시스템

/etc/init.d/dnsmasq스크립트는 항상 dnsmasq 명령줄에 자체 옵션을 삽입하고 구성을 중단합니다.

systemd는 IPTables 통합을 비활성화합니다(버그 #787480)

이는 포트 전달 옵션 아래의 이 멋진 옵션이 IPMasquerade=yes작동하지 않으며 NAT 활성화 및 포트 전달 수행과 같은 이전 iptables 규칙을 사용해야 함을 의미합니다.systemd-networkdort=tcp:80:80iptables -t nat -A POSTROUTING -s 172.23.0.0/24 -j MASQUERADEiptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -m addrtype --dst-type LOCAL -j DNAT --to-destination 172.23.0.2:80

최신 버전의 데비안을 완전히 최신 상태로 유지하고 있다면 이러한 상황을 피하고 dns솔루션이 재정의되었는지 확인해야 합니다.

2

iptables가 플러시되지 않았는지 확인하세요. 이 사용자가 사용하는 전략 apf은 iptables를 지워 새로운 iptables를 생성하는 것입니다. 을(를) 사용하고 있지만 ufw여전히 알아둘 가치가 있는 가능성입니다. 네트워크가 끊어지면 컨테이너에 더 이상 iptables 규칙이 없나요?

이는 다시 docker와 관련이 있지만 systemd-nspawn아마도 동일한 제한 사항이 있을 수 있습니다.맨페이지를 확인하세요포트 전달을 시작한 방식에 문제가 있는지 확인하십시오. 잠시 후 연결이 끊어지는 이유는 방화벽 규칙이나 포트 전달 등에 일종의 속도 제한이나 연결 제한이 있기 때문일 수 있습니다.

#3 호스팅하는 곳이 노트북인가요, 아니면 VPS인가요?

~에 따르면이 스택 오버플로 게시물사용자 Maduraiveeran은 어떤 이유로 iptables 혼란을 일으키는 자동화된 프로세스를 실행하는 VPS를 사용하고 있습니다. 호스팅이 VPS에 있는 경우에도 동일한 문제가 발생할 수 있습니다.

랩톱을 사용하는 경우 dhcp다른 네트워크 장치가 구성된 방식에 따라 Wi-Fi와 이더넷 간을 전환하거나 한 무선 액세스 포인트에서 다른 무선 액세스 포인트로 전환할 때 연결이 끊어지거나 장치 이름이 바뀔 수 있습니다. 네트워크에 문제를 일으키는 일종의 에너지 절약 계획이 있을 수 있습니다.

기타 참고사항

나는 포함한다첫 번째 블로그 링크nspawn처음부터 컨테이너를 만드는 방법을 보여주기 위해 컨테이너에 대한 정보를 찾았습니다 .

그러나 호스트 포트 전달을 위한 iptables 스크립트도 찾았습니다.같은 웹사이트에서. #1이 도움이 되지 않는다면 그럴 수도 있습니다.

결론적으로

결국 저는 컨테이너 전문가는 아니지만 올바른 방향을 알려드렸기를 바랍니다. 컨테이너가 네트워크 구성을 얻는 방법에 대한 문제 해결부터 시작하세요. 그런 다음 ufw이 구성(포트 전달, 컨테이너 가상 인터페이스 등)을 지원하는지 확인하세요. 그런 다음 컨테이너가 올바르게 구축되었는지 확인합니다(포트 전달 없이 네트워크를 구성할 수 있습니까? 예를 들어 다른 서비스도 작동합니까 ssh?). 원하는 기능 세트와 기능이 이미 포함되어 있는 사전 구축된 웹 서버 솔루션을 사용하는 것이 더 나을 수도 있습니다. LXC또는 docker또는 rancher또는 을 시도하기 위해 문을 두드리지 마십시오 sandstorm. systemd-nspawn오늘 이전에는 컨테이너에 대해 많이 들어본 적이 없었습니다. 지원을 받으려면 더 많이 지원되거나 최소한 채택된 솔루션을 사용해야 할 수도 있습니다.

나는 다음을 포함한다자세한 내용은 nspawn 맨페이지 링크를 참조하세요.

이 답변에 대해 질문이나 문의사항이 있으면 댓글을 남겨주세요. 명령을 시도하기 전에 제가 제공하는 각 링크를 주의 깊게 읽어 보시기 바랍니다. 오해를 바로잡고 게시물을 개선할 수 있도록 피드백을 보내주셔서 감사합니다. 필요한 경우 답변을 업데이트할 수 있습니다.

행운을 빌어요!

답변2

이 문제에 대한 빠른 수정

이는 실제로 라우팅 규칙이기 때문에

우리가 해야 할 일은 ufw에게 모든 전달을 허용하도록 요청하는 것뿐입니다.

해결 방법 1: 모든 전달 허용

/etc/default/ufw 파일을 편집하고 DROP에서 ACCEPT로 변경합니다.

DEFAULT_FORWARD_POLICY="DROP"
<--to-->
DEFAULT_FORWARD_POLICY="ACCEPT"

그러면 ufw는 전달을 허용합니다

해결 방법 2:

ufw가 모든 인터페이스에서 전달을 허용하도록 허용하는 대신 특정 인터페이스만 라우팅하려는 경우 수락 규칙을 수동으로 추가할 수 있습니다.

예를 들어 내 호스트의 Vnet 인터페이스는 ve-tsingkwai이고 기본 네트워크 인터페이스는 enp5s0입니다.

내가 하고 싶은 일은

$ tsingkwai@mylaptoplol Sat Jul 16 [16|09] at ~ ->
>>> ufw route allow in on enp5s0 out on ve-tsingkwai

관련 정보