네트워크를 공부하다 보면 IP, MAC 주소, ARP, TCP, 포트 같은 개념이 계속 등장해요.
책을 읽을 때는 분명 이해한 것 같은데,
"그래서 실제 컴퓨터에서는 이게 어떻게 움직이는 거지?"
라는 생각이 계속 들더라고요.
그래서 이번에는 GPT와 함께 VirtualBox에 Ubuntu Server VM을 직접 구성해서 네트워크 기초 실습을 진행해봤어요.
단순히 ping 한 번 날려보고 끝내는 게 아니라,
- 가상 네트워크 구성
- IP 직접 설정
- Ping 통신
- ARP 테이블 확인
tcpdump를 이용한 패킷 확인- nginx 웹 서버 구축
- TCP 3-Way Handshake 확인
- 서비스 장애 상황 만들어보기
- SSH로 VM에 원격 접속
까지 하나씩 직접 확인해봤어요.
처음 해보는 실습이라 중간중간 생각보다 많이 막혔는데, 오히려 그 과정에서 배운 게 많았습니다.
실습 환경
이번 실습에서는 다음 환경을 사용했어요.
- Mac (Apple Silicon)
- VirtualBox
- Ubuntu Server ARM64
- Ubuntu Server VM 2대
- nginx
- tcpdump
- SSH
VirtualBox의 네트워크는 각 VM에 두 개씩 구성했어요.
VM1
├── 어댑터 1 : NAT
└── 어댑터 2 : 내부 네트워크(labnet)
VM2
├── 어댑터 1 : NAT
└── 어댑터 2 : 내부 네트워크(labnet)NAT는 Ubuntu 패키지를 설치하는 등 인터넷을 사용하기 위한 용도이고,
labnet은 VM1과 VM2가 서로 통신하기 위한 네트워크 실습용 망으로 사용했어요.
최종적으로는 다음과 같은 구조입니다.
인터넷
│
┌────────┴────────┐
│ │
NAT NAT
│ │
VM1 VM2
192.168.10.10 192.168.10.20
│ │
└──── labnet ─────┘
1. Ubuntu Server VM 만들기
Apple Silicon Mac을 사용하고 있기 때문에 VirtualBox도 Apple Silicon Hosts 버전을 설치했어요.
Ubuntu 역시 일반 amd64 이미지가 아니라 ARM64 Ubuntu Server ISO를 사용했습니다.
VM 하나당 설정은 크게 잡지 않았어요.
CPU : 2 Core
Memory : 2GB
Disk : 20GB
OS : Ubuntu Server ARM64네트워크 실습이 목적이라 Ubuntu Desktop 대신 Ubuntu Server를 선택했어요.
GUI가 없어서 처음에는 살짝 낯설었지만, 클라우드나 서버 공부를 생각하면 오히려 서버 환경에 익숙해질 수 있어서 좋았습니다.
2. 네트워크 인터페이스 확인하기
Ubuntu 설치를 마친 뒤 가장 먼저 네트워크 인터페이스를 확인했어요.
ip -br addr확인해보니 대략 이런 구조였습니다.
lo UNKNOWN 127.0.0.1/8
enp0s8 UP 10.0.2.15/24
enp0s9 UP여기서 역할은 다음과 같아요.
enp0s8
→ VirtualBox NAT
→ 인터넷 접속용
enp0s9
→ VirtualBox 내부 네트워크
→ VM끼리 통신하는 실습용enp0s8에 붙은 10.0.2.x 주소는 VirtualBox NAT가 자동으로 할당해준 주소였어요.
따라서 이 인터페이스는 건드리지 않고, IP가 없는 enp0s9에 직접 주소를 설정했습니다.
3. VM에 고정 IP 설정하기
이번 실습에서는 다음 주소를 사용했어요.
VM1 : 192.168.10.10/24
VM2 : 192.168.10.20/24Ubuntu Server에서는 Netplan을 이용해 네트워크 설정을 관리할 수 있어요.
먼저 설정 파일을 확인했습니다.
ls /etc/netplan그리고 Netplan 파일을 수정했어요.
sudo nano /etc/netplan/00-installer-config.yamlVM1의 내부 네트워크 인터페이스에는 다음과 같이 주소를 설정했습니다.
network:
version: 2
ethernets:
enp0s9:
dhcp4: false
addresses:
- 192.168.10.10/24VM2는 주소만 다르게 설정했어요.
network:
version: 2
ethernets:
enp0s9:
dhcp4: false
addresses:
- 192.168.10.20/24설정이 잘못되었는지 먼저 확인하고,
sudo netplan generate문제가 없다면 적용합니다.
sudo netplan apply그리고 다시 확인했어요.
ip -br addrVM1:
enp0s9 UP 192.168.10.10/24VM2:
enp0s9 UP 192.168.10.20/24이렇게 나오면 성공입니다.
4. 드디어 Ping을 날려보자
이제 VM1에서 VM2로 Ping을 보내봤어요.
ping 192.168.10.20정상적으로 응답이 돌아왔습니다.
64 bytes from 192.168.10.20 ...그리고 마지막에는
0% packet loss까지 확인할 수 있었어요.
반대로 VM2에서도 VM1로 Ping을 보내봤습니다.
ping 192.168.10.10역시 정상적으로 통신됐어요.
처음에는 단순히
"오, Ping 된다!"
정도로 생각했는데, 여기서 중요한 건 왜 통신이 되는지였습니다.
VM1과 VM2의 주소는 각각
192.168.10.10/24
192.168.10.20/24이기 때문에 둘 다
192.168.10.0/24라는 같은 네트워크에 속해 있어요.
따라서 중간에 라우터를 거칠 필요 없이 서로 직접 통신할 수 있습니다.
5. ARP 테이블 직접 확인하기
여기서 책에서 공부했던 ARP를 직접 확인해봤어요.
VM1에서 다음 명령어를 실행했습니다.
ip neigh그러자 이런 정보가 나타났어요.
192.168.10.20 dev enp0s9 lladdr xx:xx:xx:xx:xx:xx STALE192.168.10.20이라는 IP 주소와 함께 VM2의 MAC 주소가 저장되어 있는 걸 볼 수 있었어요.
처음에는
"나는 VM2의 IP만 입력했는데 MAC 주소는 어떻게 알았지?"
라는 생각이 들었어요.
바로 이 과정에서 ARP가 사용됩니다.
VM1
"192.168.10.20 누구야?"
│
│ ARP Request
▼
VM2
"나야! 내 MAC 주소는 xx:xx:xx..."
│
│ ARP Reply
▼
VM1즉, 같은 LAN에서 실제 Ethernet 통신을 하기 위해서는 상대방의 MAC 주소가 필요하고, 그 주소를 알아내는 과정이 ARP라는 것을 직접 확인할 수 있었어요.
[이미지: ip neigh 명령어에서 192.168.10.20의 MAC 주소가 표시된 화면]
6. tcpdump로 ARP 패킷 직접 보기
이번에는 ARP가 실제로 움직이는 모습을 패킷으로 확인해봤습니다.
sudo tcpdump -i enp0s9 arp그런데 처음 실행했을 때 아무것도 나오지 않았어요.
왜 그런지는 뒤에 트러블슈팅에서 자세히 이야기해볼게요.
ARP 캐시를 비우고 다시 Ping을 보내자,
Who has 192.168.10.20? Tell 192.168.10.10
192.168.10.20 is-at xx:xx:xx:xx:xx:xx와 비슷한 패킷을 확인할 수 있었어요.
책에서 ARP Request, ARP Reply라고만 보던 내용을 실제 패킷으로 보니까 훨씬 이해가 잘 되더라고요.
7. VM2에 nginx 웹 서버 설치하기
Ping까지 확인했으니 이제 단순한 ICMP 통신을 넘어 실제 TCP 서비스를 이용해보기로 했어요.
VM2에 nginx를 설치했습니다.
sudo apt update
sudo apt install nginx -y서비스 상태를 확인합니다.
sudo systemctl status nginx정상적으로 실행 중이라면 active (running)이라고 표시됩니다.
그리고 실제 80번 포트가 열려 있는지도 확인했어요.
sudo ss -lntp결과에서 다음과 같은 부분을 확인했습니다.
LISTEN ... 0.0.0.0:80쉽게 생각하면,
IP 주소 → 어떤 컴퓨터인가?
Port → 그 컴퓨터 안의 어떤 프로그램인가?라고 이해할 수 있어요.
8. VM1에서 HTTP 요청 보내기
이제 VM1에서 VM2의 nginx로 접속해봤어요.
curl http://192.168.10.20그러자 nginx 기본 페이지의 HTML 코드가 출력됐습니다.
🎉 드디어 웹 통신 성공!
VM1
↓
192.168.10.20으로 IP 통신
↓
TCP 80번 포트 연결
↓
HTTP 요청
↓
nginx
↓
HTTP 응답
9. TCP 3-Way Handshake 직접 확인하기
이번에는 curl을 실행할 때 TCP에서는 실제로 어떤 일이 일어나는지 확인해봤어요.
VM1에서 다음 명령어를 실행했습니다.
sudo tcpdump -i enp0s9 tcp port 80그리고 다른 터미널에서 다시 요청했어요.
curl http://192.168.10.20패킷을 보면 TCP 연결을 시작하면서 다음 과정이 나타납니다.
VM1 VM2
SYN
----------------------->
SYN + ACK
<-----------------------
ACK
----------------------->바로 유명한 TCP 3-Way Handshake입니다.
쉽게 표현하면,
VM1 : "연결하고 싶은데 가능해?" → SYN
VM2 : "가능해!" → SYN + ACK
VM1 : "응, 확인했어." → ACK이렇게 서로 연결할 준비가 됐는지 확인한 뒤에야 HTTP 데이터를 주고받습니다.
10. 일부러 nginx를 죽여봤다
이번에는 정상 동작만 보는 게 아니라 일부러 장애를 만들어봤어요.
VM2에서 nginx를 종료했습니다.
sudo systemctl stop nginx그리고 VM1에서 다시 접근했습니다.
curl http://192.168.10.20당연히 정상적으로 접속되지 않았어요.
여기서 중요한 건 바로 "네트워크가 고장 났네!"라고 판단하지 않는 것이었습니다.
먼저 Ping을 확인합니다.
ping 192.168.10.20Ping은 정상적으로 동작했어요.
다음으로 VM2에서 포트를 확인했습니다.
sudo ss -lntpnginx를 종료했기 때문에 80번 포트가 더 이상 LISTEN 상태가 아니었습니다.
그리고 서비스 상태까지 확인했어요.
sudo systemctl status nginx즉 문제를 다음과 같이 좁힐 수 있었습니다.
Ping 성공
↓
IP 네트워크 정상
80 Port 확인
↓
80번 포트 LISTEN 안 함
nginx 확인
↓
서비스 중지 상태
원인 발견!다시 실행하면
sudo systemctl start nginx웹 요청도 정상적으로 돌아옵니다.
11. Mac에서 SSH로 VM 접속하기
계속 VirtualBox 화면을 왔다 갔다 하면서 명령어를 입력하는 게 조금 불편했어요.
그래서 SSH 설정도 해봤습니다.
VM에 SSH 서버를 설치했어요.
sudo apt update
sudo apt install openssh-server -y상태 확인:
sudo systemctl status ssh그리고 VirtualBox NAT에서 포트 포워딩을 설정했습니다.
Host Port : 2222
Guest Port : 22
Protocol : TCP즉,
Mac : 2222
↓
VirtualBox NAT
↓
VM1 : 22(SSH)구조가 됩니다.
Mac 터미널에서는 이렇게 접속했어요.
ssh -p 2222 heejun@127.0.0.1이제 Mac 터미널을 여러 개 열어서 VM1에 동시에 접속할 수 있었습니다.
트러블슈팅
이번 실습은 한 번에 순조롭게 진행되지는 않았어요.
오히려 여기서 막혔던 것들이 네트워크와 Linux를 이해하는 데 더 도움이 됐습니다.
문제 1. Ubuntu 설치 화면 대신 UEFI 화면이 나타남
처음 VirtualBox VM을 부팅했는데 Ubuntu 설치 화면이 아니라 UEFI Boot Manager가 나타났어요.
원인
Ubuntu ISO가 VM에 제대로 연결되지 않았거나 올바른 ISO에서 부팅하지 못한 상태였습니다.
또한 Apple Silicon Mac이기 때문에 일반 x86용 Ubuntu 이미지가 아니라 ARM64 이미지가 필요했어요.
해결
VirtualBox에서 Ubuntu Server ARM64 ISO를 연결한 뒤 다시 부팅했습니다.
Apple Silicon Mac
↓
VirtualBox Apple Silicon Hosts
↓
Ubuntu Server ARM64 ISO문제 2. Netplan YAML 구조가 예제와 달랐다
실제 Ubuntu 설정 파일에는 다음과 같은 내용도 들어있었어요.
match:
macaddress: ...
set-name: ...처음에는 내 파일이 잘못된 건가 싶었습니다.
원인
Ubuntu 설치 과정에서 Netplan 설정을 자동 생성하면서 인터페이스 MAC 주소와 이름을 고정하기 위한 추가 옵션이 들어간 것이었어요.
해결
기존 내용을 무조건 삭제하기보다 먼저 실제 인터페이스를 확인했어요.
ip -br addr그리고
enp0s8 → NAT
enp0s9 → 내부 네트워크라는 것을 확인한 뒤 enp0s9에만 고정 IP를 설정했습니다.
환경에 따라 eth0, ens33, enp0s3, enp0s8, enp0s9처럼 인터페이스 이름이 달라질 수 있기 때문에 예제를 그대로 복사하지 않는 게 중요했어요.
문제 3. enp0s9에 IP가 붙지 않음
Netplan 파일을 수정하고 ip -br addr을 확인했는데 enp0s9 UP만 나오고 IP가 보이지 않았어요.
해결
설정 문법을 검사하고 다시 적용했습니다.
sudo netplan generate
sudo netplan apply그 후 다시 확인하니
enp0s9 UP 192.168.10.10/24가 나타나면서 해결됐습니다.
문제 4. Netplan 파일 확인 중 Permission denied
cat /etc/netplan/00-installer-config.yaml을 실행했는데 Permission denied가 발생했어요.
원인
해당 파일을 일반 사용자 권한으로 읽을 수 없었기 때문입니다.
해결
sudo cat /etc/netplan/00-installer-config.yaml처럼 sudo를 붙여 해결했습니다.
문제 5. tcpdump를 실행했는데 ARP 패킷이 안 보임
sudo tcpdump -i enp0s9 arp를 실행했는데 아무것도 나오지 않았습니다.
원인
이미 이전 Ping 과정에서 VM2의 MAC 주소를 알아냈고, 그 정보가 ARP 캐시에 저장되어 있었기 때문이었어요.
해결
Neighbor Cache를 비웠습니다.
sudo ip neigh flush dev enp0s9그리고 다시 Ping을 보내자 ARP Request와 Reply가 정상적으로 캡처됐어요.
이번 실습에서 가장 중요하게 배운 것
이번 실습을 하면서 각각 따로 외우고 있던 개념들이 하나의 흐름으로 연결되기 시작했어요.
웹 서버에 접속한다고 가정하면 실제로는 단순히
curl → nginx가 아니라,
목적지 IP 확인
↓
같은 네트워크인지 판단
↓
ARP를 이용해 MAC 주소 확인
↓
Ethernet Frame 전송
↓
TCP 3-Way Handshake
↓
TCP 연결 생성
↓
HTTP Request
↓
nginx 처리
↓
HTTP Response같은 과정이 숨어있다는 것을 직접 확인할 수 있었습니다.
특히 이번 실습에서 직접 만져본 개념은 다음과 같아요.
IP Address
Subnet
Network Interface
MAC Address
ARP
ICMP
Ping
TCP
Port
3-Way Handshake
HTTP
nginx
SSH책에서 각각 하나의 챕터처럼 떨어져 있던 개념들이 실제 통신 하나를 만들기 위해 서로 연결되어 있다는 점이 가장 인상 깊었어요.
마무리
처음에는 그냥
"VM 두 대 만들어서 Ping 한 번 해보자."
정도의 실습일 줄 알았어요.
그런데 직접 해보니 VirtualBox 네트워크부터 Netplan, ARP, TCP, nginx, SSH까지 자연스럽게 연결됐습니다.
특히 단순히 명령어가 성공하는 것보다
"왜 지금 이 패킷이 발생했지?"
"왜 Ping은 되는데 웹 접속은 안 되지?"
"이 IP는 어느 인터페이스에 붙어 있는 거지?"
같은 질문을 계속 던지는 게 네트워크 공부에서 중요한 것 같아요.
그리고 일부러 nginx를 종료해서 장애를 만들어본 것도 재미있었습니다.
서비스 안 됨
↓
Ping 확인
↓
포트 확인
↓
프로세스 확인
↓
원인 찾기이런 식으로 하나씩 원인을 좁혀가는 과정이 제가 관심을 가지고 있는 클라우드 엔지니어와 SRE의 트러블슈팅 방식과도 연결되는 느낌이 들었어요.
다음 실습에서는 지금처럼 같은 192.168.10.0/24 네트워크에서 통신하는 것이 아니라,
192.168.10.0/24
│
Router
│
192.168.20.0/24처럼 서로 다른 두 네트워크 사이에 Linux Router를 만들어 직접 라우팅해보려고 합니다.
이번에는 같은 네트워크 안에서 통신하는 과정을 확인했다면, 다음에는 다른 네트워크로 패킷이 넘어갈 때 Gateway와 Routing Table이 어떤 역할을 하는지 직접 확인해보겠습니다.
