GitLab은 브리지 인터페이스에서 SSHD와 공존합니다.

GitLab은 브리지 인터페이스에서 SSHD와 공존합니다.

배경

Docker를 사용하는 서버를 Podman으로 변환하려고 합니다. 지금까지 모든 서비스(총 15개)를 시스템 작업으로 변환하고 문제 없이 실행할 수 있었습니다. 이 과정에서 브리지 장치( )를 생성하고 여기에 br0물리적 인터페이스( eno1)와 포드의 인터페이스를 추가했습니다. 드라이버를 사용하여 실행 중인 다른 컨테이너를 브리지에 veth연결합니다 . 지금까지 모든 것이 예상대로 작동하고 있습니다.bindmacvlan

질문

이제 컨테이너에서 GitLab을 시작하려고 하며 표준 포트 22 및 443을 사용하려고 합니다. 이러한 포트는 1024보다 낮기 때문에 이 컨테이너를 루트로 호출한 다음 다른 사용자로 전환해야 합니다(공식 컨테이너는 gitlab-ce총 8명의 다른 사용자를 사용합니다). 컨테이너를 시작하려고 할 때마다 다음 오류가 발생합니다.

podman[1161766]: Error: cannot listen on the TCP port: listen tcp4 :22: bind: address already in use

특정 IP 주소만 수신하도록 sshd를 구성했기 때문에 이는 혼란스럽습니다 br0(물리적 호스트의 주소는 /24 >= 100이고, 컨테이너의 주소는 4에서 99 사이의 /24입니다).

ListenAddress 192.168.1.104

그런 다음 netstat를 사용하여 다음을 확인합니다.

tcp        0      0 192.168.1.104:22        0.0.0.0:*               LISTEN      695475/sshd

컨테이너는 FE:ED:DE:AD:BE:EF호스트 시스템과 다른 MAC( ) 및 IP( )로 시작하도록 구성됩니다.192.168.1.15

질문

포트 22를 사용하는 또 다른 것은 무엇입니까?

실패하면 netstat가 포트 22를 사용하는 sshd만 표시한다면 어떻게 범인을 찾을 수 있습니까?

내가 아는 한 이것이 작동해야합니다. 컨테이너가 내부적으로 루트가 아닌 사용자로 전환하더라도 루트 컨텍스트에서 OCI 런타임이 호출되므로 네트워크 인터페이스를 구성하려고 할 때 포트에 바인딩할 수 있어야 합니다. 이는 문제 없이 포트 53에 바인딩할 수 있는 DNS 컨테이너에 의해 추가로 확인됩니다.

관련 정보