2026 리눅스마스터 2급 ⑪ 인터넷 활용｜네트워크·포트·서비스 설정

리눅스 인터넷 활용은 인터페이스가 주소를 갖고 → 목적지가 같은 네트워크인지 판단하고 → 다른 네트워크라면 라우팅표의 게이트웨이로 보내고 → DNS가 이름을 주소로 바꾸며 → TCP·UDP 포트가 응용 서비스를 구분하는 흐름으로 공부하면 됩니다.

ip는 주소·링크·경로를, ss는 소켓과 LISTEN 상태를, getent는 시스템의 이름·서비스 데이터베이스 조회 결과를 보여 줍니다. 연결 문제는 주소 → 경로 → 이름해석 → 소켓 → 응용 서비스 순서로 좁혀 가면 원인을 섞지 않을 수 있습니다.

12편 전체 목차는 2026 리눅스마스터 2급 전체 학습지도에서 확인할 수 있습니다.

네트워크 설정의 네 가지 질문

항목	답하는 질문	예	확인 명령
IP 주소	이 인터페이스를 어떤 주소로 식별하는가?	192.168.10.25, 2001:db8::25	ip -br address
프리픽스·서브넷	어디까지 직접 연결된 같은 네트워크인가?	/24, /64	ip address show
라우팅·게이트웨이	목적지까지 어느 인터페이스·다음 홉으로 보낼 것인가?	default via 192.168.10.1	ip route show
DNS	도메인 이름을 어떤 주소·레코드로 해석하는가?	example.com → 주소	getent ahosts example.com

DNS와 게이트웨이는 역할이 다릅니다. DNS는 이름을 주소로 해석하고, 게이트웨이는 다른 네트워크로 패킷을 전달할 다음 홉입니다. DNS가 고장 나도 IP 주소로 통신할 수 있을 수 있고, 기본 경로가 없으면 DNS 서버 주소를 알아도 외부에 도달하지 못할 수 있습니다.

1. 주소·링크·라우팅을 먼저 확인

# 인터페이스 상태와 주소를 간단히 확인
ip -br link
ip -br address

# IPv4·IPv6 라우팅표 확인
ip -4 route show
ip -6 route show

# 실제 패킷을 보내지 않고 문서용 목적지까지 선택될 경로 계산
ip route get 192.0.2.1

# 현재 이웃 캐시(IPv4 ARP, IPv6 NDP 결과) 확인
ip neigh show

192.0.2.0/24는 문서 예시용으로 예약된 주소 대역입니다. ip route get은 커널이 선택할 경로를 조회하며 해당 목적지에 서비스가 있다는 뜻은 아닙니다.

lo는 루프백 인터페이스로 자기 시스템 내부 통신에 사용됩니다. 127.0.0.1과 IPv6 ::1은 로컬 호스트를 뜻하므로, 여기에만 바인딩된 서비스는 다른 호스트가 직접 접속할 수 없습니다.

2. TCP와 UDP 차이

구분	TCP	UDP
통신 형태	연결 지향 바이트 스트림	연결 설정 없는 데이터그램
순서·신뢰성	순서 보존, 재전송, 흐름·혼잡 제어 제공	전달·순서·중복 방지를 자체 보장하지 않음
경계	응용 메시지 경계를 보존하지 않는 스트림	각 데이터그램 경계를 보존
대표 사용	SSH, HTTP/1.1·HTTP/2, SMTP	DNS의 많은 질의, 실시간 전송, QUIC 기반 HTTP/3

UDP가 언제나 빠르고 TCP가 언제나 느리다는 설명은 틀립니다. 실제 성능은 왕복 지연, 손실, 응용 프로토콜의 재전송·혼잡제어, 구현 방식에 따라 달라집니다. UDP를 쓰는 응용도 필요하면 자체적으로 신뢰성과 보안을 구현합니다.

3. 주요 서비스와 기본 포트

서비스	기본 포트·전송	핵심 용도	주의
SSH	TCP 22	보호된 원격 로그인·터널·파일 전송 기반	Telnet과 달리 암호화·인증 구조 사용
DNS	UDP/TCP 53	이름과 주소·각종 레코드 조회	DNS는 UDP만 쓴다는 설명은 틀림
HTTP	TCP 80	웹 요청·응답	평문 전송 가능
HTTPS	TCP 443, HTTP/3은 UDP 443	TLS 또는 QUIC로 보호되는 HTTP	포트만으로 실제 프로토콜을 확정할 수 없음
SMTP	TCP 25	메일 서버 간 전송	제출·보호 포트와 역할을 별도로 구분
FTP	TCP 21 제어, TCP 20은 전통적 active 데이터	파일 전송	기본 FTP는 보호되지 않으므로 현대 실무에서 주의

포트 번호는 서비스의 기본 관례입니다. 관리자가 SSH를 다른 포트에 두거나, 어떤 프로그램이 80번 포트에서 HTTP가 아닌 자체 프로토콜을 사용할 수도 있습니다. 따라서 포트 번호만 보고 프로세스·프로토콜·외부 노출을 모두 확정하지 않습니다.

4. 소켓과 LISTEN 상태 읽기

# TCP·UDP의 수신 대기 소켓을 숫자 형식으로 조회
ss -tuln

# 연결된 TCP 소켓과 프로세스 정보 확인
# 다른 사용자의 프로세스 정보는 권한에 따라 제한될 수 있습니다.
ss -tnp

# 서비스 이름 데이터베이스에서 ssh 항목 확인
getent services ssh

로컬 주소 예	뜻	외부 접근 판단
127.0.0.1:8080	IPv4 루프백에만 바인딩	같은 호스트에서만 직접 접근
0.0.0.0:22	모든 IPv4 로컬 주소에 대한 와일드카드 수신	방화벽·라우팅·NAT를 추가 확인
[::]:443	IPv6 와일드카드 수신	IPv4 겸용 여부는 시스템 설정에 따라 다름

LISTEN이 보인다는 것은 로컬 소켓이 연결을 기다린다는 뜻이지 인터넷 전체에서 접근 가능하다는 뜻은 아닙니다. 호스트 방화벽, 클라우드 보안정책, 상위 라우터, NAT, 서비스 접근제어를 함께 봐야 합니다.

5. DNS와 응용 계층 확인

# 시스템이 실제로 사용하는 NSS 경로를 통해 주소 조회
getent ahosts example.com

# systemd-resolved가 있다면 DNS 서버·링크별 상태 확인
resolvectl status

# 로컬 TCP/IP와 ICMP 처리 확인
ping -c 3 127.0.0.1

# curl이 설치된 환경에서 안전한 문서용 사이트의 HTTP 헤더 확인
curl -I https://example.com

getent는 단순히 DNS만 직접 묻는 명령이 아니라 /etc/nsswitch.conf에 정의된 시스템 이름 서비스 경로를 따릅니다. 반면 resolvectl은 systemd-resolved가 사용되는 환경에서 링크별 DNS 상태와 캐시·프로토콜 설정을 확인하는 데 유용합니다.

6. 연결 문제를 좁히는 순서

1. 링크: 인터페이스가 UP이며 케이블·무선·가상 NIC가 연결됐는지 확인합니다.
2. 주소: 올바른 IPv4·IPv6 주소와 프리픽스가 있는지 확인합니다.
3. 경로: 목적지에 맞는 직접 경로 또는 기본 게이트웨이가 있는지 봅니다.
4. 이름해석: 도메인 이름이 의도한 주소로 해석되는지 확인합니다.
5. 소켓: 서버가 올바른 주소·포트에서 수신 중인지 봅니다.
6. 응용·정책: TLS, 인증, 서비스 설정, 방화벽과 접근정책을 확인합니다.

자주 틀리는 5가지

1. “DNS와 게이트웨이는 모두 인터넷 주소를 찾아 준다” → DNS는 이름해석, 게이트웨이는 다른 네트워크로의 다음 홉입니다.
2. “UDP는 포트가 없다” → TCP와 UDP 모두 포트를 사용해 응용 종점을 구분합니다.
3. “53번은 UDP만 쓴다” → DNS는 메시지와 동작에 따라 UDP와 TCP를 모두 사용합니다.
4. “LISTEN이면 외부 접속이 된다” → 바인딩 주소, 방화벽, 라우팅·NAT를 추가 확인해야 합니다.
5. “ping 실패는 서버가 꺼졌다는 뜻이다” → ICMP 차단, 경로 문제, 이름해석 문제 등 여러 원인이 있습니다.

셀프체크 5문항

1. IP 주소·프리픽스·게이트웨이·DNS의 역할을 각각 쓰세요.
2. TCP와 UDP의 데이터 경계와 신뢰성 차이는 무엇인가요?
3. DNS가 UDP와 TCP를 모두 사용할 수 있다는 뜻을 설명하세요.
4. 0.0.0.0:22 LISTEN만으로 인터넷 접속 가능을 단정할 수 없는 이유는?
5. 이름으로 접속이 안 될 때 주소·경로·DNS·소켓을 어떤 순서로 확인하겠습니까?

정답 확인

1. 주소는 인터페이스 식별, 프리픽스는 직접 연결 범위, 게이트웨이는 다른 망의 다음 홉, DNS는 이름해석입니다.
2. TCP는 신뢰성 있는 바이트 스트림이라 메시지 경계를 보존하지 않고, UDP는 전달 보장 없는 데이터그램 경계를 보존합니다.
3. 일반 질의는 UDP가 흔하지만 큰 응답·영역전송 등에는 TCP가 사용될 수 있어 53번을 UDP 전용으로 볼 수 없습니다.
4. 모든 로컬 IPv4 주소에 바인딩됐다는 뜻일 뿐 방화벽·상위 라우터·NAT·서비스 정책은 별도이기 때문입니다.
5. 인터페이스 주소 → 라우팅표 → 이름해석 → 수신 소켓 → 응용·보안정책 순서로 확인합니다.

전체 공부 순서로 돌아가려면 리눅스마스터 2급 전체 학습지도를 확인하세요.

공식 자료

• KAIT 리눅스마스터 2급 출제기준: 인터넷 활용
• IETF RFC 1122: Internet Host Communication Layers
• IETF RFC 9293: TCP
• IETF RFC 768: UDP
• IETF RFC 1035: DNS 구현과 규격
• IETF RFC 9110: HTTP Semantics
• IETF RFC 4251: SSH Protocol Architecture
• ip(8): 링크·주소·라우팅 조회
• ss(8): 소켓 통계와 상태

이 글은 2026년 7월 11일 기준 KAIT 범위와 IETF RFC·iproute2 매뉴얼을 확인해 작성했습니다. 포트는 기본 관례이며 실제 서비스·접근 가능성은 시스템 설정에 따라 달라집니다. 외부 대상 스캔이나 설정 변경 없이 로컬 상태와 문서용 대상을 확인하는 명령만 사용했으며, 문제는 자체 제작했습니다.