본문으로 건너뛰기

운영 네트워크에서 Linux 게이트웨이 구성하기

이 가이드는 격리된 인프라로 인해 운영 환경에서 Linux 시스템이 동작하지 않게 만들 수 있는 몇 가지 기본 네트워크 구성 파라미터를 다룹니다. Linux 배포판에 따라 다음 주제에 대해 서로 다른 서비스를 사용할 수 있다는 점에 유의하십시오. 따라서 아래에 나열된 일부 명령은 실행되지 않을 수 있습니다. 이 섹션은 네이티브 Debian 12 (bookworm) OS 버전이 설치된 Raspberry Pi를 예시로 작성되었습니다.

정보

SEW 팀과의 지원 통화 전에, 세션 중 화면 공유를 위해 사용자의 컴퓨터에서 Linux 장치로 SSH 접속이 가능한지 확인하십시오.

다음은 연결을 방해할 수 있는 일반적인 영역의 목록입니다.

DNS 서버​

도메인 네임 시스템(DNS) 서버는 인터넷을 통한 통신을 원활하게 하기 위해 도메인 이름을 IP 주소로 확인합니다. 올바른 DNS 구성은 네트워크 환경에서 동작하는 Linux 시스템에 매우 중요합니다. DNS 문제 해결에는 ping 또는 nslookup과 같은 명령을 사용하여 DNS 서버의 접근 가능 여부를 확인하는 작업이 포함됩니다. 서버가 응답하며 도메인 이름을 IP 주소로 올바르게 확인하는지 확인하십시오. 잘못된 구성은 도메인 확인 실패로 이어져 네트워크 통신과 인터넷 접속에 영향을 줄 수 있습니다.

테스트​

호스트에 구성된 DNS 서버 IP를 다음 명령으로 확인합니다:

cat /etc/resolv.conf

각 DNS 서버는 nslookup 또는 dig로 개별적으로 테스트할 수 있습니다. 예를 들어 서버가 8.8.8.8인 경우:

nslookup api.eu1.sdaconsole.io 8.8.8.8
dig @8.8.8.8 api.eu1.sdaconsole.io +short

이러한 명령이 없는 경우 Debian에서 dnsutils 또는 bind9-dnsutils 패키지로 설치할 수 있으며, 또는 ping이나 getent와 같은 기본 명령을 사용하여 현재 DNS 구성을 테스트할 수 있습니다:

ping api.eu1.sdaconsole.io
getent hosts api.eu1.sdaconsole.io

구성​

DNS 서버는 Linux 설치 환경에 따라 서로 다른 서비스로 관리될 수 있습니다. Raspberry Pi의 경우 일반적으로 NetworkManager 서비스가 이를 관리합니다. DNS 확인을 관리하는 서비스는 다음과 같이 해당 파일을 생성했음을 알리는 주석을 /etc/resolv.conf에 남기는 경우가 많습니다:

cat /etc/resolv.conf
> # Generated by NetworkManager
> nameserver 192.168.15.1
> nameserver fe80::dec6:37ff:fe36:5ee8%wlan0

cat /etc/resolv.conf
> # Generated by dhcpcd from eth0.dhcp
> # /etc/resolv.conf.head can replace this line
> nameserver 192.168.15.1

전역 DNS 서버를 설정하려면 다음 파일을 생성합니다:

sudo nano /etc/NetworkManager/conf.d/dns.conf

그리고 다음을 추가합니다:

[global-dns-domain-*]
servers=8.8.8.8,4.4.4.4

NetworkManager 서비스를 재시작하고 /etc/resolv.conf에서 새 값을 확인합니다.

sudo systemctl restart NetworkManager
# Verify /etc/resolv.conf was updated
cat /etc/resolv.conf

NTP 서버​

네트워크 타임 프로토콜(NTP) 서버는 Linux 시스템에서 시스템 시계를 원자시계나 중앙 서버와 같은 시간 소스와 동기화하기 위해 사용됩니다. 정확한 시간 유지는 로깅, 보안 프로토콜 및 네트워크 전반의 작업 조정에 매우 중요합니다. NTP 서버를 잘못 설정하면 SSL 인증서 무효화로 인해 HTTPS 호출이 실패합니다.

테스트​

NTP 동기화 상태와 현재 날짜 및 시간이 올바른지 확인합니다.

# Check NTP sync status
timedatectl status

# Check configured NTP servers
timedatectl timesync-status
timedatectl show-timesync --all

# Check logs from the timesync service
journalctl -u systemd-timesyncd -n 20
# Check if service is active
systemctl is-active systemd-timesyncd

특정 서버와의 연결 테스트:

# Using ntpdate, if installed
ntpdate -q 0.debian.pool.ntp.org

# Using Netcat
timeout 2 nc -u -z -v 0.debian.pool.ntp.org 123

구성​

NTP 서버는 0.debian.pool.ntp.org 또는 ntp.myorg.com과 같은 도메인 이름으로 구성하거나 IP 주소로 직접 구성할 수 있습니다.

# Configure systemd-timesyncd
sudo nano /etc/systemd/timesyncd.conf

[Time] 블록에 사용자 지정 NTP 서버를 추가하고 해당 줄이 주석 처리되지 않았는지 확인합니다. FallbackNTP에서 접근할 수 없는 서버는 모두 제거합니다.

[Time]
NTP=ntp.myorg.com ntp.myorg.local
FallbackNTP=

timesync 서비스를 재시작하고 반드시 활성화합니다.

# Restart and enable
sudo systemctl restart systemd-timesyncd
sudo systemctl enable systemd-timesyncd

# Force synchronization
sudo timedatectl set-ntp true

# Verify sync
timedatectl timesync-status

프록시 서버​

프록시 서버는 클라이언트와 대상 서버 사이의 중개자로 작동하여 요청과 응답을 전달합니다. 기업 환경에서 프록시 서버는 보안 제어, 콘텐츠 필터링, 대역폭 관리 및 외부로 나가는 트래픽의 로깅을 위해 일반적으로 사용됩니다. 이러한 네트워크의 Linux 시스템은 패키지 저장소 및 웹 서비스를 포함한 외부 리소스에 접근하기 위해 HTTP/HTTPS 요청을 회사 프록시를 통해 라우팅하도록 구성되어야 합니다.

테스트​

환경 변수와 시스템 전역 프록시 설정을 확인하여 프록시가 현재 구성되어 있는지 확인합니다:

# Check shell environment proxy variables
env | grep -i proxy

# Check system-wide proxy configuration
cat /etc/environment | grep -i proxy

# Check if proxy is set for current user
echo $http_proxy
echo $https_proxy
echo $no_proxy

프록시 서버가 필요한지 확인하려면 외부 서버에 직접 연결을 시도합니다:

# Try direct connection to a public server
timeout 5 curl -I https://repository.eu1.sdaconsole.io/glue/v2/linux/arm64/release.json 2>&1

# If it fails with connection errors, proxy might be required
# Common error: "Failed to connect" or "Connection timed out"

연결 오류로 실패한다면 프록시가 필요할 수 있습니다. 일반적인 오류는 예를 들어 Failed to connect 또는 Connection timed out 입니다.

특정 프록시 서버로 요청을 테스트하려면:

# Test with curl
curl -I --proxy http://proxy.company.local:8080 https://repository.eu1.sdaconsole.io/glue/v2/linux/arm64/release.json
# Proxy with user authentication
curl -I --proxy http://user@pwd@proxy.company.local:8080 https://repository.eu1.sdaconsole.io/glue/v2/linux/arm64/release.json
# Test without proxy (direct connection)
curl -I --noproxy "*" https://repository.eu1.sdaconsole.io/glue/v2/linux/arm64/release.json

구성​

정보

프록시 주소는 다음 형식 중 하나를 가집니다:

<protocol>://<proxy-address>:<port-number>
<protocol>://<username>:<password>@<proxy-address>:<port-number>

모든 사용자 및 애플리케이션에 대해 프록시를 구성합니다:

# Edit system-wide environment
sudo nano /etc/environment

다음 줄을 추가하거나 수정합니다:

http_proxy="http://proxy.company.local:8080"
https_proxy="http://proxy.company.local:8080"
no_proxy="localhost,127.0.0.1,*.company.local,10.0.0.0/8,192.168.0.0/16"

# Uppercase variants (some applications check these)
HTTP_PROXY="http://proxy.company.local:8080"
HTTPS_PROXY="http://proxy.company.local:8080"
NO_PROXY="localhost,127.0.0.1,*.company.local,10.0.0.0/8,192.168.0.0/16"

변경 사항을 적용합니다:

# Reload environment (or log out and back in)
source /etc/environment
# Verify variables are set
env | grep -i proxy

트래픽이 실제로 프록시를 통해 전달되는지 확인하려면:

# Verbose curl request showing proxy connection
curl -v -I https://repository.eu1.sdaconsole.io/glue/v2/linux/arm64/release.json 2>&1 | grep -i proxy

# Should show something like:
# * Uses proxy env variable http_proxy == 'http://proxy.company.local:3128'
# * Trying proxy.company.local:3128...
경고

일부 프록시는 SSL 검사를 수행합니다. 회사 CA 인증서를 설치해야 할 수 있습니다:

# Copy corporate CA certificate
sudo cp company-ca.crt /usr/local/share/ca-certificates/
# Update CA trust store
sudo update-ca-certificates
# Verify
curl -I https://repository.eu1.sdaconsole.io/glue/v2/linux/arm64/release.json

Debian 저장소​

Debian 저장소는 Debian 기반 시스템을 위한 소프트웨어 패키지와 업데이트를 호스팅하는 서버입니다. 격리된 기업 환경에서는 보안상의 이유로 공용 Debian 미러(deb.debian.org 또는 archive.ubuntu.com 등)에 대한 접근이 차단될 수 있습니다. 기업은 사용 가능한 패키지를 제어하고 외부 대역폭 사용을 줄이기 위해 자체 내부 미러를 운영하는 경우가 많습니다.

테스트​

현재 구성된 저장소를 확인합니다:

# View configured repositories
cat /etc/apt/sources.list

# Check additional repository files
ls -la /etc/apt/sources.list.d/
cat /etc/apt/sources.list.d/*.list 2>/dev/null

다음은 구성된 저장소에 대한 연결성을 완전하게 테스트하기 위한 포괄적인 bash 스크립트입니다:

# Test if repository servers are reachable
grep -h "^deb http" /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null | \
awk '{print $2, $3}' | sort -u | while read repo suite; do
echo "Testing: $repo (suite: $suite)"
# Test the Release file that APT actually fetches
# This is what APT checks first when doing 'apt update'
release_url="${repo}/dists/${suite}"
# Test with curl (follows redirects, checks certificates)
if curl -fsSL --connect-timeout 5 --max-time 10 -I "$release_url/InRelease" >/dev/null 2>&1; then
echo " > Repository is reachable"
else
if curl -fsSL --connect-timeout 5 --max-time 10 -I "$release_url/Release" >/dev/null 2>&1; then
echo " > Repository is reachable"
else
# If failed, show the specific error
error=$(curl -fsSL --connect-timeout 5 --max-time 10 -I "$repo" 2>&1 | head -1)
echo " X Unreachable: $error"
fi
fi
echo
done

또 다른 방법은 패키지 목록 업데이트를 시도하여 저장소 문제를 식별하는 것입니다:

# Try to update package lists
sudo apt update

# Check for errors in apt logs
tail -20 /var/log/apt/term.log

저장소가 차단되었음을 나타내는 일반적인 오류 메시지:

  • Failed to fetch http://deb.debian.org/...
  • Could not resolve 'deb.debian.org'
  • Connection timed out
  • Unable to connect to...

특정 저장소 서버를 수동으로 테스트합니다:

# Test HTTP connectivity to a repository
curl -sSL -I --connect-timeout 5 http://deb.debian.org/debian/

# Or using wget
wget --spider --timeout=5 http://deb.debian.org/debian/

# Test DNS resolution
getent hosts deb.debian.org

구성​

주 소스 파일을 편집합니다:

sudo nano /etc/apt/sources.list

내용을 내부 미러로 교체합니다. Debian 12 (bookworm)의 경우:

# Internal Debian Repository Mirror
deb http://mirror.company.local/debian bookworm main contrib non-free non-free-firmware
deb http://mirror.company.local/debian bookworm-updates main contrib non-free non-free-firmware
deb http://mirror.company.local/debian-security bookworm-security main contrib non-free non-free-firmware

# Optionally, backports for newer packages
deb http://mirror.company.local/debian bookworm-backports main contrib non-free non-free-firmware

내부 미러가 HTTPS를 사용하는 경우:

deb https://mirror.company.local/debian bookworm main contrib non-free non-free-firmware

참고: HTTPS 저장소의 경우 apt-transport-https 및 ca-certificates 패키지가 설치되어 있는지 확인하십시오.

저장소 우선순위 구성 (선택 사항)

내부 저장소와 외부 저장소를 모두 사용하면서 내부 저장소에 우선권을 주어야 하는 경우:

sudo nano /etc/apt/preferences.d/internal-mirror

다음을 추가합니다:

Package: *
Pin: origin mirror.company.local
Pin-Priority: 900

Package: *
Pin: origin deb.debian.org
Pin-Priority: 500

이렇게 하면 내부 미러에 더 높은 우선순위가 부여됩니다.

저장소용 프록시 구성 (선택 사항)

네트워크에서 저장소에 접근하기 위해 프록시가 필요한 경우:

# Configure APT proxy
echo 'Acquire::http::Proxy "http://proxy.company.local:3128";' | \
sudo tee /etc/apt/apt.conf.d/proxy.conf

# For HTTPS repositories
echo 'Acquire::https::Proxy "http://proxy.company.local:3128";' | \
sudo tee -a /etc/apt/apt.conf.d/proxy.conf

# Test
sudo apt update

업데이트 및 검증

저장소를 구성한 후:

# Update package lists
sudo apt update

# Check for errors
echo $? # Should return 0 if successful

# Verify packages can be found
apt-cache policy apt

# Test installing a small package
sudo apt install --dry-run nano

일반적인 문제

문제: apt update가 무한정 멈춤

# Check if repository server is actually responding
timeout 10 curl -v http://mirror.company.local/debian/

# Check for proxy interference
unset http_proxy https_proxy
sudo apt update

문제: 미러를 구성한 후에도 패키지를 찾을 수 없음

# Verify the mirror has the correct Debian version
curl http://mirror.company.local/debian/dists/ | grep bookworm

# Check if the mirror is properly synced
curl -sI http://mirror.company.local/debian/dists/bookworm/Release | grep Date

문제: 혼합된 저장소 소스로 인한 충돌

# Check all active sources
grep -rh "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/ | sort -u

# Disable conflicting sources
sudo mv /etc/apt/sources.list.d/problematic.list /etc/apt/sources.list.d/problematic.list.disabled

sudo apt update