작은 인터넷 설계도 그리기

왜 설계도가 먼저 필요한가

지금까지 우리는 인터넷을 이루는 부품을 하나씩 보았다. 비트가 지나가는 길, 컴퓨터 안의 네트워크 문, 스위치, IP 주소, 라우터, 라우팅 테이블을 배웠다. 이제 이 부품들을 한 장의 지도 위에 올려야 한다.

설계도 없이 장비를 연결하면 처음에는 그럴듯해 보인다. 케이블도 꽂혀 있고, 불도 들어온다. 하지만 통신이 안 될 때 어디가 문제인지 찾기 어렵다. 주소가 겹쳤는지, 게이트웨이가 틀렸는지, 라우터가 돌아오는 길을 모르는지 구분할 수 없기 때문이다.

작은 인터넷의 설계도는 도로 지도와 비슷하다. 어느 동네가 있고, 동네와 동네 사이에 어떤 길이 있으며, 각 동네의 출입구가 어디인지 표시한다. 여기서 동네는 네트워크, 출입구는 라우터의 인터페이스, 도로 표지판은 라우팅 테이블에 해당한다.

다만 비유는 여기까지다. 실제 네트워크에서는 차가 도로를 달리는 것이 아니라, 패킷이라는 데이터 묶음이 IP 주소와 라우팅 테이블을 따라 이동한다.

AI 생성 이미지

우리가 만들 작은 인터넷의 모양

이번 장에서는 세 개의 목적 있는 네트워크를 만든다.

• 클라이언트 네트워크: 사용자의 컴퓨터가 있는 곳

• 서버 네트워크: 웹 서버나 DNS 서버가 있는 곳

• 관리 네트워크: 관리자 컴퓨터와 점검 장비가 있는 곳

여기에 라우터 세 대를 놓아 여러 홉을 지나가게 만든다. 홉은 패킷이 라우터 같은 중간 장비를 한 번 지나는 단계를 뜻한다. 택배가 지역 물류센터를 하나 거칠 때마다 이동 단계가 늘어나는 것과 비슷하다.

작은 인터넷의 전체 구조는 다음처럼 잡을 수 있다.

클라이언트 PC들
192.168.10.0/24
      |
     R1
      |
10.0.12.0/30
      |
     R2 ---- 관리 PC들
      |       192.168.30.0/24
10.0.23.0/30
      |
     R3
      |
서버들
192.168.20.0/24

이 구조에서 클라이언트가 서버에 접속하려면 R1, R2, R3를 차례로 지나야 한다. 즉, 한 방 안의 스위치 네트워크보다 인터넷에 더 가까운 모양이 된다. 장치 몇 대만 있는 작은 실습 환경이지만, "여러 네트워크가 라우터를 통해 이어진다"는 핵심 구조는 실제 인터넷과 같다.

IP 대역을 나누어 배치하기

IP 대역은 같은 동네의 주소 묶음이라고 생각하면 쉽다. 예를 들어 192.168.10.0/24는 192.168.10.으로 시작하는 장치들을 한 동네로 묶겠다는 뜻이다. 정확한 이름은 서브넷이다.

이번 설계에서는 각 역할마다 다른 서브넷을 준다.

라우터 사이의 연결망에는 /30을 썼다. /30은 사용할 수 있는 주소가 아주 적은 작은 네트워크다. 넓은 동네가 아니라 두 라우터가 마주 보는 짧은 다리라고 생각하면 된다. 예를 들어 R1과 R2 사이에는 양쪽 라우터 인터페이스가 쓸 주소 두 개만 있으면 충분하다.

장치별 주소는 이렇게 줄 수 있다.

여기서 중요한 원칙은 간단하다. 같은 네트워크 안에서는 같은 규칙의 주소를 써야 한다. 이 예제처럼 /24를 쓴다면 클라이언트 네트워크의 장치들은 192.168.10.으로 시작하는 주소를 쓰고, 서버 네트워크의 장치들은 192.168.20.으로 시작하는 주소를 쓴다. 서로 다른 네트워크는 주소 대역이 달라야 한다. 두 네트워크에 같은 대역을 중복해서 쓰면, 라우터 입장에서는 어느 쪽으로 보내야 할지 길 찾기가 꼬인다.

또 하나 기억할 것이 있다. PC나 서버처럼 한 네트워크에 붙어 있는 장치는 자기 동네 밖으로 나갈 때 사용할 게이트웨이를 알아야 한다. 클라이언트 PC의 게이트웨이는 192.168.10.1, 웹 서버와 DNS 서버의 게이트웨이는 192.168.20.1, 관리자 PC의 게이트웨이는 192.168.30.1이 된다.

클라이언트, 서버, 관리를 나누는 이유

처음에는 모든 장치를 한 네트워크에 넣고 싶을 수 있다. 그렇게 하면 설정은 단순하다. 하지만 인터넷의 원리를 배우기에는 좋지 않다. 모든 장치가 같은 동네에 있으면 라우터가 할 일이 거의 없고, 여러 홉을 지나는 과정을 관찰하기 어렵다.

클라이언트 네트워크는 요청을 보내는 장치들이 있는 곳이다. 사용자가 브라우저를 열고 웹 서버에 접속하는 출발점이다.

서버 네트워크는 응답을 제공하는 장치들이 있는 곳이다. 웹 페이지를 주는 웹 서버, 이름을 주소로 바꾸는 DNS 서버 같은 장비를 여기에 둔다. 다음에 DNS를 만들 때도 이 서버 네트워크가 중심이 된다.

관리 네트워크는 장비를 점검하고 설정하는 곳이다. 관리용 길을 따로 두면 사용자의 일반 통신과 장비 관리 통신을 구분할 수 있다. 사무실에 손님용 출입문과 직원용 출입문을 나누는 것과 비슷하다.

이 비유도 한계가 있다. 실제 네트워크에서 분리는 벽이나 문만으로 이루어지지 않는다. IP 대역, 라우터의 경로, 보안 정책이 함께 맞아야 한다. 이번 장에서는 먼저 주소와 경로를 나누는 데 집중한다.

라우터가 알아야 하는 길

각 컴퓨터는 자기 동네 밖으로 나갈 때 게이트웨이에 패킷을 맡긴다. 클라이언트 PC의 게이트웨이는 192.168.10.1이다. 이 주소는 R1의 클라이언트 쪽 인터페이스다.

하지만 라우터도 모든 길을 저절로 알지는 못한다. 라우터는 자신에게 직접 연결된 네트워크는 안다. R1은 192.168.10.0/24와 10.0.12.0/30을 안다. 그러나 서버 네트워크인 192.168.20.0/24는 직접 연결되어 있지 않다. 그래서 R1에게 "서버 네트워크로 가려면 R2 쪽으로 보내라"는 길을 알려 주어야 한다.

라우팅 테이블을 말로 쓰면 다음과 같다. 여기에는 직접 연결된 네트워크가 아니라, 라우터가 추가로 알아야 하는 먼 네트워크만 적었다.

다음으로 보낼 곳은 최종 목적지가 아니다. 다음 라우터의 가까운 주소다. 택배 송장에 최종 주소가 적혀 있어도, 지금 물류센터는 다음 물류센터로만 보내면 된다. 라우터도 마찬가지다. R1은 웹 서버 192.168.20.10이 정확히 어느 케이블 끝에 꽂혀 있는지 몰라도 된다. R2에게 넘기면 된다.

패킷 하나가 지나가는 길

클라이언트 PC 192.168.10.10이 웹 서버 192.168.20.10에 접속한다고 해 보자.

먼저 클라이언트는 목적지 IP를 본다. 목적지 192.168.20.10은 자기 네트워크 192.168.10.0/24 안에 없다. 그래서 패킷을 게이트웨이인 R1에게 보낸다.

R1은 패킷의 목적지 IP를 본다. 목적지는 여전히 192.168.20.10이다. R1의 라우팅 테이블에는 192.168.20.0/24로 가려면 R2의 10.0.12.2로 보내라고 적혀 있다. 그래서 R1은 패킷을 R2로 넘긴다.

R2도 목적지 IP를 확인한다. 서버 네트워크는 R3 쪽에 있으므로 10.0.23.2로 보낸다. R3는 서버 네트워크에 직접 연결되어 있다. 마지막으로 R3가 웹 서버 192.168.20.10에게 패킷을 전달한다.

중요한 점이 있다. 최종 목적지 IP는 계속 192.168.20.10으로 유지된다. 하지만 각 구간에서 사용하는 MAC 주소는 다음 장치에 맞게 바뀐다. 클라이언트에서 R1까지 갈 때는 R1의 클라이언트 쪽 MAC 주소가 필요하고, R1에서 R2까지 갈 때는 R2의 R1 쪽 MAC 주소가 필요하다. R2에서 R3까지 갈 때는 R3의 R2 쪽 MAC 주소가 필요하고, 마지막으로 R3에서 웹 서버까지 갈 때는 웹 서버의 MAC 주소가 필요하다.

다시 말해 IP 주소는 먼 목적지 주소이고, MAC 주소는 지금 구간에서 받을 다음 장치의 이름표다. 패킷은 같은 최종 목적지를 향해 가지만, 구간마다 "다음에 누구에게 건네줄지"는 계속 바뀐다.

설계도에서 일부러 빼 둔 것

이번 설계에는 아직 진짜 인터넷 회선이 없다. 공인 IP도 쓰지 않는다. NAT도 다루지 않는다. 사람이 읽는 이름인 example.local 같은 DNS 이름도 아직 붙이지 않았다.

이것은 빠진 것이 아니라 순서다. 먼저 숫자 주소와 라우터만으로 통신이 되는지 확인해야 한다. 이름은 그다음에 붙인다. 도로가 이어졌는지 확인하기 전에 간판부터 세우면, 문제가 생겼을 때 간판 문제인지 도로 문제인지 헷갈린다.

작은 인터넷을 만들 때는 "주소로 먼저 통한다. 그다음 이름으로 통한다"는 순서를 기억하면 좋다.

연결 확인 순서

문제가 생기면 가까운 곳부터 먼 곳으로 확인한다. 이 순서를 지키면 복잡한 네트워크도 차분히 좁혀 갈 수 있다.

첫째, 물리 연결을 본다. 케이블이 꽂혀 있는지, 무선 연결이 살아 있는지, 네트워크 인터페이스가 켜져 있는지 확인한다. 불이 들어온다고 항상 정상은 아니지만, 불도 들어오지 않는다면 위 단계로 올라갈 이유가 없다.

둘째, 각 장치의 IP 주소와 서브넷 마스크를 본다. 클라이언트 PC가 192.168.10.10/24인지, 게이트웨이가 같은 네트워크 안의 192.168.10.1인지 확인한다. 서버도 192.168.20.10/24와 게이트웨이 192.168.20.1을 가져야 한다.

셋째, 같은 네트워크 안의 게이트웨이에 닿는지 본다. 클라이언트가 R1에 닿지 못하면 R2나 R3를 볼 필요가 없다. 서버가 R3에 닿지 못해도 마찬가지다.

넷째, 라우터끼리 이어진 연결망을 확인한다. R1은 R2의 10.0.12.2에 닿아야 하고, R2는 R3의 10.0.23.2에 닿아야 한다. 반대로 R2가 R1의 10.0.12.1에 닿는지, R3가 R2의 10.0.23.1에 닿는지도 확인하면 좋다. 라우터 사이의 짧은 다리가 끊어지면 뒤쪽 네트워크는 모두 멀어진다.

다섯째, 라우팅 테이블을 본다. R1이 서버 네트워크로 가는 길을 아는지, R3가 클라이언트 네트워크로 돌아가는 길을 아는지 확인한다. 왕복 통신에서는 가는 길과 돌아오는 길이 모두 필요하다. 요청은 서버까지 갔는데 응답이 돌아오지 못하면 사용자는 "인터넷이 안 된다"고 느낀다.

여섯째, 그다음에 서버 프로그램이나 보안 설정을 본다. 길이 끊어진 상태에서 웹 서버 설정을 고치면 문제를 더 복잡하게 만들 수 있다. 먼저 길, 그다음 서비스다.

작은 인터넷의 기준점

이번 장의 설계도는 앞으로의 기준점이다. 다음에 DNS를 만들 때도, 웹 서버를 올릴 때도, 장애를 고칠 때도 이 지도를 기준으로 생각한다.

핵심은 세 가지다.

• 역할이 다른 장치는 다른 네트워크로 나눈다.

• 네트워크와 네트워크 사이는 라우터가 잇는다.

• 라우터는 목적지 네트워크와 다음 홉을 알아야 한다.

이제 우리는 단순히 장비를 연결한 것이 아니다. 클라이언트가 출발하고, 라우터가 길을 고르고, 서버가 응답하며, 관리자가 별도 네트워크에서 전체를 살펴볼 수 있는 작은 인터넷의 뼈대를 만든 것이다.