DevOps를 위한 네트워킹 (시니어 레벨, 프로덕션 중심)

Source: Dev.to

위 링크에 포함된 본문을 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다. 현재는 번역할 텍스트가 없으므로 번역을 진행할 수 없습니다. 번역이 필요한 전체 텍스트를 복사해서 알려 주세요.

핵심 지식 (자동으로 알아야 함)

네트워크 기본 (생각할 필요 없음)

• IP 주소 – 프라이빗 vs. 퍼블릭
• CIDR – /32, /24, /16
• 포트 – 잘 알려진 포트 vs. 임시 포트
• TCP vs. UDP
• DNS 해석 흐름
• 라우팅 테이블
• 기본 게이트웨이

Linux 네트워킹 명령어 (암기 필수)

인터페이스 및 라우팅

ip a        # show interfaces
ip r        # show routing table

연결 및 포트

ss -tulnp
netstat -tulnp

도달성

ping 
traceroute 

애플리케이션 레이어

curl 
wget 

포트 소유권

lsof -i :8080

방화벽

ufw status
iptables -L -n

🔥 프로젝트 1 – “서비스는 실행 중이지만 접근 불가”

(클래식 인터뷰 질문)

시나리오 (실제 기업 사례)

• Linux VM에 백엔드 서비스 배포
• 프로세스가 실행 중
• 포트가 로컬에서 열려 있음
• 외부 사용자는 접근 불가

목표

추측이 아닌 체계적인 장애 격리를 수행한다.

아키텍처

Client → DNS → Network → Firewall → OS → Application

단계별 실습

Step 1 – 서비스 시작

python3 -m http.server 8080

리슨 상태 확인:

ss -tulnp | grep 8080

예상: 0.0.0.0:8080 또는 127.0.0.1:8080에서 서비스가 리슨 중.

Step 2 – 로컬 접근 테스트

curl http://localhost:8080

• ✅ 정상 작동 → 애플리케이션은 정상
• ❌ 실패 → 애플리케이션 문제, 네트워킹이 아님

Step 3 – 인터페이스 바인딩 확인

ip a

핵심 인사이트: 앱이 127.0.0.1에 바인딩돼 있으면 외부에서 접근 불가.

Step 4 – 라우팅 확인

ip r

다음 항목 확인:

• 기본 라우트
• 올바른 게이트웨이

❌ 기본 라우트가 없으면 → 트래픽이 VM을 떠날 수 없음.

Step 5 – 방화벽 점검 (매우 흔함)

sudo ufw status
# 또는
sudo iptables -L -n

수정 (UFW 예시):

sudo ufw allow 8080

Step 6 – 포트 소유권 확인

lsof -i :8080

확인 내용:

• 올바른 프로세스가 리슨 중인지
• 포트 충돌 여부

Step 7 – 외부 테스트

다른 머신에서:

curl http://<VM_IP>:8080

인터뷰 매핑 (정확히 사용할 문구)

“저는 Application → Port binding → OS firewall → Routing → DNS 순으로 레이어를 하나씩 점검합니다.”

🔥 PROJECT 2 – DNS Failure in Production

시나리오

• IP 로 서비스에 접근 가능
• 도메인 이름 으로는 접근 불가

단계

Step 1 – DNS 확인

nslookup myservice.company.com
# or
dig myservice.company.com

Step 2 – /etc/resolv.conf 확인

cat /etc/resolv.conf

다음 항목을 확인하세요:

• 올바른 nameserver 항목
• 사내 DNS와 공용 DNS 구분

Step 3 – IP와 DNS 비교

curl http://10.0.2.15:8080
curl http://myservice.company.com:8080

인터뷰 답변

“IP는 동작하지만 DNS가 실패한다면, 문제는 DNS 해석에 있으며 네트워킹이나 애플리케이션이 아닙니다.”

🔥 PROJECT 3 – 라우팅 문제 (트래픽이 어디에도 도달하지 않음)

시나리오

• 서비스 실행 중
• 방화벽 열림
• DNS 정상
• 여전히 접근 불가

단계

Step 1 – 라우트 확인

ip r

일반적인 문제:

• 기본 라우트 누락
• VPN 또는 클라우드 잘못 구성 후 잘못된 게이트웨이

Step 2 – 패킷 경로 추적

traceroute google.com

추적이 일찍 멈추면 → 라우팅 문제.

면접 팁

“Traceroute는 패킷이 어디서 사라지는지 알려줍니다. 추측보다 훨씬 빠릅니다.”

🔥 PROJECT 4 – Port Conflict & Ghost Services

Scenario

• 배포 성공
• 앱이 즉시 충돌

Steps

Step 1 – Check Port Usage

ss -tulnp | grep 8080
# or
lsof -i :8080

Step 2 – Kill or Reconfigure

kill -9 <PID>

Interview Insight

“One of the first things I check is whether the port is already in use.”
“제가 가장 먼저 확인하는 것 중 하나는 포트가 이미 사용 중인지 여부입니다.”

🔥 PROJECT 5 – Firewall Lockdown Simulation

(Add your own steps here – e.g., enable a strict security group, verify connectivity, then roll back.)

보안 초점

시나리오

• 보안 팀이 방화벽을 강화했습니다
• 앱이 작동을 멈췄습니다

단계 1: 방화벽 활성화

sudo ufw enable

단계 2: 모든 트래픽 차단

sudo ufw default deny incoming

단계 3: 필요한 포트만 허용

sudo ufw allow 22
sudo ufw allow 443

학습 결과

• 최소 권한 네트워킹
• 제로 트러스트 사고방식

면접 답변

“저는 절대 포트를 넓게 열지 않습니다. 애플리케이션이 엄격히 필요로 하는 것만 허용합니다.”

🎯 FINAL INTERVIEW MASTER ANSWER

Question:
“Service is up but not reachable. What do you check?”

Perfect Senior Answer:

“저는 계층별로 문제를 해결합니다.

1. Service status – 서비스가 실행 중이며 올바른 인터페이스/포트에서 리스닝하고 있는지 확인합니다 (systemctl status …, ss -ltnp).
2. Firewall rules – ufw/iptables 정책을 확인하여 필요한 포트가 허용되어 있는지 확인합니다.
3. Routing – 라우팅 테이블 (ip route)을 검사하여 트래픽이 호스트에 도달할 수 있는지 확인합니다.
4. DNS resolution – 호스트명이 올바른 IP로 해석되는지 확인합니다 (dig, nslookup).
5. Connectivity tools – ping, traceroute, tcptraceroute 등을 사용해 패킷이 어디서 떨어지는지 찾습니다.
6. Application logs – 바인딩이나 권한 문제를 나타낼 수 있는 오류를 확인합니다.
   이러한 계층을 차례로 점검함으로써 차단이 호스트, 네트워크, 혹은 애플리케이션 수준 중 어디에 있는지 빠르게 파악할 수 있습니다.”