최근에 생애 첫 매니지드 네트워크 스위치인 TP-Link JetStream TL-SG3428X를 구매했다.

매니지드 스위치의 핵심 기능은 네트워크를 VLAN으로 나눌 수 있다는 점이다. 이 기능이 정말 기대됐지만, VLAN을 제대로 동작하게 만드는 데 몇 시간의 시행착오가 필요했다.

TP-Link의 VLAN 문서가 부족하다고 느껴서, 혹시 다른 사람에게 도움이 될까 싶어 내가 정리한 내용을 공유한다.

배경

VLAN이 익숙하지 않다면, 내가 가장 좋아하는 설명 자료는 Raid Owl의 영상이다.

태그드 포트, 언태그드 포트 그리고 PVID

제조사마다 VLAN 기능을 설명하는 용어가 다르다.

TP-Link 스위치에서 알아둬야 할 설정은 다음과 같다:

• 태그드 포트
• 언태그드 포트
• PVID

태그드 포트

포트를 VLAN에 태그드 포트로 추가하면, 스위치는 해당 포트에 연결된 장치가 그 VLAN으로 트래픽을 보내고 받을 수 있도록 허용한다.

태그드 포트에서는 스위치가 패킷의 VLAN 태그를 그대로 유지하므로, VLAN을 인식하는 장치는 VLAN의 태그드 포트로 추가해야 한다. VLAN을 인식하는 장치란 방화벽, 다른 매니지드 스위치, VLAN을 지원하는 무선 액세스 포인트 등을 말한다.

예를 들어 포트 5를 VLAN 10과 20에 태그드 포트로 추가하면, 스위치는 해당 포트로 VLAN 태그 10과 20이 붙은 패킷을 전송한다. 태그를 제거하지 않으므로 포트 5에 연결된 장치는 VLAN 태그가 그대로 붙은 패킷을 받게 된다. 10과 20만 허용되므로 다른 VLAN 태그가 붙은 패킷은 받지 않는다.

언태그드 포트

포트를 VLAN에 언태그드 포트로 추가해도 태그드 포트와 마찬가지로 해당 포트에 연결된 장치가 그 VLAN으로 트래픽을 보내고 받을 수 있다. 차이점은 언태그드 포트의 경우 스위치가 패킷을 포트로 전달하기 전에 네트워크 패킷에서 VLAN 태그를 제거한다는 점이다.

언태그드 포트는 일반 데스크톱 PC, 스캐너, 프린터 같은 VLAN을 인식하지 못하는 장치를 위한 것이다. 포트에 연결된 장치가 VLAN에 대해 전혀 모르기 때문에 스위치가 VLAN 태그를 제거하는 것이다.

예를 들어 포트 6을 VLAN 10에 언태그드 포트로 추가하면, 스위치는 VLAN 태그 10이 붙은 패킷을 해당 포트로 보내지만 전달하기 전에 태그를 제거한다. 포트 6에 연결된 장치는 VLAN 태그가 없는 패킷을 받게 된다. VLAN 10만 허용되므로 다른 VLAN 태그가 붙은 패킷은 받지 않는다.

PVID

TP-Link 스위치에서 각 포트는 PVID, 즉 포트 VLAN 식별자를 갖는다. 연결된 장치에서 해당 포트를 통해 패킷이 스위치로 들어오면, 스위치는 그 포트의 PVID를 VLAN 태그로 패킷에 추가한다.

태그드 포트와 언태그드 포트가 스위치에서 포트로 나가는 패킷을 어떻게 처리할지를 정의한다면, PVID는 포트에서 스위치로 들어오는 패킷에 영향을 준다.

VLAN을 인식하는 장치가 연결된 포트에는 PVID를 설정할 필요가 없다. 그런 장치들은 스스로 VLAN 태그를 추가하기 때문이다.

반면 VLAN을 인식하지 못하는 장치가 연결된 포트에는 PVID를 설정해야 한다. 스위치가 그 장치를 대신해 올바른 VLAN 태그를 추가해야 하기 때문이다.

TP-Link 매니지드 스위치에서 VLAN 설정 찾는 방법

TP-Link는 VLAN 설정을 이름이 비슷한 여러 옵션들 사이에 숨겨 놓았다. 처음에는 내가 올바른 설정을 만지고 있는 게 맞는지조차 확신이 서지 않았다.

나와 비슷한 인터페이스를 가진 TP-Link 스위치를 사용하고 있다면, 다음 순서로 VLAN 설정을 찾을 수 있다:

1. 상단 네비게이션 바에서 “L2 Features”를 클릭한다
2. 왼쪽 사이드바에서 “VLAN”을 클릭한다
3. 하위 메뉴에서 “802.1Q VLAN”을 클릭한다

“VLAN Config” 탭에서는 스위치에 VLAN을 추가하고 어떤 포트가 해당 VLAN의 멤버인지 설정할 수 있다.

“Port Config” 탭에서는 각 포트의 PVID를 설정할 수 있다. 다시 말하지만 PVID는 VLAN에 속해야 하는 VLAN 비인식 장치에 직접 연결된 포트에만 설정하면 된다. 특정 포트에 PVID를 설정한다면, 그 포트는 하나의 VLAN에만 언태그드 포트로 속해 있어야 한다.

왜 TP-Link는 PVID를 수동으로 관리하게 할까?

일부 스위치는 설정에서 PVID를 아예 빼놓는다. 태그드 포트와 언태그드 포트만 보여주고, 스위치가 PVID를 자동으로 설정해 준다.

PVID 설정을 노출하지 않는 스위치에서는 포트를 VLAN 20에 언태그드 포트로 추가하면 암시적으로 해당 포트의 PVID가 20으로 설정된다. TP-Link도 이 방식을 따랐으면 좋았을 텐데, 지금 구현은 불필요하게 복잡하다.

TP-Link 스위치에서 언태그드 포트와 PVID를 관리할 때 내가 쓰는 원칙은 다음과 같다:

• VLAN을 인식하지 못하는 장치를 스위치에 연결한다면, 그 장치는 하나의 VLAN에만 속해야 한다.
  • 장치의 포트를 해당 VLAN에 언태그드 포트로 추가한다.
  • 포트의 PVID를 해당 VLAN ID로 설정한다.
  • 다른 모든 VLAN에서 해당 포트를 제거한다.

예를 들어 스위치의 포트 16에 프린터를 연결하고 VLAN 20에 넣고 싶다면, 포트 16을 VLAN 20에 언태그드 포트로 추가하고 포트 16의 PVID를 20으로 설정하면 된다.

TP-Link는 기술적으로는 하나의 포트를 여러 VLAN에 언태그드로 추가하는 것을 허용하지만, 그렇게 할 이유가 있다고 생각하지 않는다. 그렇게 하면 장치는 다른 VLAN에 있는 장치로부터 패킷을 받을 수는 있지만, 보낼 때는 포트의 PVID와 일치하는 단일 VLAN의 장치에게만 패킷을 보낼 수 있기 때문이다.

매니지드 스위치 도입 전의 내 홈 네트워크

매니지드 스위치를 들이기 전에도 이미 VLAN을 사용하고 있었지만, 언매니지드 스위치를 통해 연결하고 있었다.

내 구성에서 관련된 네트워크 장치들은 다음과 같았다:

• 모든 VLAN에 완전한 접근 권한을 가진 데스크톱 PC
• 서로 다른 VLAN을 가진 두 개의 WLAN 네트워크를 호스팅하는 Ruckus WiFi 액세스 포인트
• VLAN을 통과하거나 인터넷으로 나가는 패킷에 방화벽 규칙을 적용하는 OPNsense 방화벽
• 특정 VM의 네트워크 인터페이스에 VLAN ID를 태그하는 Proxmox 서버

이 다이어그램에서는 VLAN을 인식하는 장치들이 직렬로 연결된 경우가 하나도 없다는 점에 주목하자. 덕분에 설정이 많이 단순해졌는데, 매니지드 스위치로 업그레이드하기 전까지는 그 사실을 깨닫지 못했다.

실수 1: 언매니지드 스위치를 매니지드 스위치로 교체했더니 WiFi 인터넷이 끊겼다

TP-Link TL-SG3428X를 구매했을 때, 기존 언매니지드 스위치 자리에 그대로 교체해서 넣었다. 네트워크 다이어그램 자체는 크게 달라지지 않았다:

새 매니지드 스위치를 설치하고 몇 분 지나지 않아 약혼자가 노트북에서 인터넷이 끊겼다고 했다. 내 휴대폰을 확인해 보니 마찬가지였다.

WiFi 장치들은 모두 WiFi 네트워크에 연결은 됐지만 인터넷에 접속할 수 없었다. 어떻게 된 일일까? 방화벽 설정은 하나도 건드리지 않았다. 그냥 언매니지드 스위치를 매니지드 스위치로 교체했을 뿐인데.

몇 시간 후에야 문제의 원인을 깨달았다. 매니지드 스위치가 태그된 패킷을 모두 드롭하고 있었던 것이다. WiFi 장치에서 액세스 포인트까지는 트래픽이 도달했지만, 스위치가 내 VLAN에 대해 아무것도 모르기 때문에 VLAN 태그가 붙은 패킷을 거부하고 있었다.

해결책은 매니지드 스위치에 기존 VLAN들을 알려주는 것이었다. 그렇지 않으면 스위치는 계속해서 VLAN 태그된 패킷을 모두 드롭할 것이다.

수정 후 내 매니지드 스위치 설정은 다음과 같았다:

이 설정 변경 후 WiFi 장치들의 인터넷이 다시 연결됐다. 스위치가 VLAN 태그를 인식하고 트래픽을 OPNsense 방화벽으로 전달했기 때문이다.

실수 2: 라우터를 VLAN에 추가하는 것을 잊어버림

네트워크에 신뢰할 수 없는 장치를 추가하려다가 또 다른 문제에 부딪혔다. 집에 태양광 패널이 있는데, 상태를 모니터링하려면 이 독점 IoT 장치를 사용해야 한다.

이 IoT 장치는 측정값을 벤더의 클라우드 대시보드에 업로드하기 위해 인터넷 접속이 필요하다. 이 작은 상자가 그 밖에 무슨 짓을 할지 전혀 알 수 없으니, 홈 네트워크의 어떤 것에도 접근하지 못하게 하고 싶었다.

OPNsense 방화벽에서 게스트보다도 덜 신뢰하는 장치들을 위해 “Purgatory”라는 새 VLAN을 만들었다. Purgatory에 속한 장치는 DNS 서버와 공인 인터넷 IP에는 접근할 수 있지만, 다른 VLAN에는 접근할 수 없다.

그 다음 TP-Link 스위치에서 태양광 모니터링 IoT 장치가 연결된 포트를 Purgatory VLAN에 추가했다. IoT 장치는 VLAN을 인식하지 못하는 장치이므로 Purgatory에 대해 언태그드 포트로 설정하고, Purgatory VLAN ID(80)를 해당 포트의 PVID로 지정했다.

포트를 VLAN에 언태그드 포트로 할당하면 패킷이 IoT 장치에 도달하기 전에 VLAN 태그가 제거된다. PVID를 할당하면 IoT 장치가 스위치로 보내는 패킷에 VLAN 태그가 추가된다.

하지만 동작하지 않았다. 클라우드 대시보드는 즉시 IoT 장치가 오프라인이라고 표시했다.

IoT 장치에서는 어떤 진단도 실행할 수 없어서 다른 시스템으로 디버깅해야 했다. Dell Optiplex NixOS 시스템을 Purgatory VLAN에 추가해 보니 역시 네트워크 접속이 끊겼다. Purgatory VLAN에 속해 있는 동안에는 네트워크의 어떤 것도 ping할 수 없었다.

뭐가 잘못된 건지 알아내려고 머리를 싸맸다. 테스트 장치를 태그드 포트로도, 언태그드 포트로도 추가해 보고 PVID를 1로도, 80으로도 설정해 봤다. 아무것도 통하지 않았다. 장치를 네트워크에 연결할 수 없었다.

OPNsense 방화벽을 확인해 보니 Purgatory VLAN에서는 트래픽이 전혀 보이지 않았다. DHCP 설정을 확인해 Purgatory VLAN용 DHCP 서버가 실행 중인지 확인했는데, 실행 중이었다.

사흘 밤을 끙끙 앓으며 원인을 파악하려 한 끝에 마침내 깨달았다. OPNsense 방화벽을 Purgatory VLAN에 추가하지 않았던 것이다!

당시 상황은 다음과 같았다:

1. IoT 장치가 TP-Link 매니지드 스위치로 트래픽을 보낸다.
2. 스위치가 Purgatory용 VLAN 태그를 추가한다.
3. Purgatory VLAN에 다른 호스트가 없으므로 Purgatory 패킷이 갈 곳이 없다.

해결책은 간단했다. OPNsense 방화벽을 Purgatory VLAN에 추가하는 것이다. 방화벽은 VLAN을 인식하므로 태그드 포트로 추가했다:

포트 24에 대한 원래 PVID 설정은 올바랐다. 스위치가 IoT 장치가 스위치로 보내는 패킷에 Purgatory용 VLAN 태그 80을 붙여야 하므로 PVID는 80이어야 했다.

이 변경을 적용하자 IoT 장치가 클라우드 대시보드에 연결됐고, 홈 네트워크로부터 적절히 격리됐다.

VLAN 문제 디버깅을 위한 팁

VLAN 문제를 디버깅할 때 가장 큰 어려움 중 하나는 내 설정 변경이 어떤 영향을 미쳤는지 관찰할 방법을 찾는 것이었다. 포트를 태그드 포트에서 언태그드 포트로 바꾸면, 그게 차이를 만들었는지 어떻게 테스트할 수 있을까?

Wireshark 열어보기

장치의 네트워크 상태를 진단하기 위해 여러 커맨드라인 도구를 시도해 봤지만, 결국 가장 유용한 것은 Wireshark였다.

나는 평소에 Wireshark를 잘 쓰지 않는다. 훌륭한 도구이긴 하지만, 내 문제와 관련된 정보를 찾으려다 항상 길을 잃곤 한다. Wireshark를 열면 필터 쿼리 언어를 다시 배워야 할 것 같아 별로 내키지 않는다.

이번 경우에는 Wireshark로 뭔가 영리한 작업을 할 필요가 전혀 없었다. 실행하자마자 장치에서 나가려는 트래픽은 보이는데 돌아오는 트래픽이 전혀 없는 것을 보고 바로 무엇이 잘못됐는지 깨달았다.

재부팅

VLAN 문제를 디버깅할 때 가장 골치 아픈 점 중 하나는 테스트 컴퓨터가 새로운 VLAN 설정에 언제 “반응”하는지 확신할 수 없다는 것이었다.

네트워크 상태를 초기화하는 가장 신뢰할 수 있는 방법이 이것이었으면 좋지 않았겠지만, 실제로는 그랬다. 호스트가 어떤 시스템을 실행하느냐에 따라 30~90초가 걸리므로 테스트 주기가 느려져서 번거롭다. 하지만 스위치의 VLAN 설정을 변경했을 때 다른 어떤 방법보다도 시스템이 네트워크 상태를 확실히 초기화하도록 보장했다.

더 나은 방법이 분명 있을 테지만, 나는 찾지 못했다.

원격 관리 도구 사용하기

TinyPilot은 내가 만든 제품이라 편향됐을 수 있지만, VLAN 문제를 디버깅하는 데 TinyPilot이 도움이 됐다.

처음에는 Proxmox VM 서버의 VM에서 VLAN을 디버깅해 보려 했지만, 시뮬레이션하려는 실제 IoT 장치와 너무 달랐다. Proxmox 서버는 VLAN을 인식하지만, 내가 테스트하려는 장치는 VLAN을 인식하지 못하는 장치였다. Proxmox 서버를 언태그드 포트로 취급하면 Proxmox 서버 자체에 대한 접근이 완전히 차단될 것이다.

TinyPilot을 사용하면 테스트 중인 장치가 네트워크 연결을 잃더라도 항상 접근할 수 있었다. 그리고 모든 설정을 브라우저 탭을 통해 하므로 메인 데스크톱에서 모든 작업을 할 수 있었다.

ping

네트워크 연결 끊김을 확인하는 데 내가 찾은 가장 신뢰할 수 있는 방법은 검증된 ping 유틸리티였다.

두 개의 터미널 창에서 두 개의 ping 명령을 사용했다. 하나는 10.0.80.1에 있는 방화벽으로, 다른 하나는 google.com으로 보냈다. 각 창을 통해 로컬 네트워크와 Google에 대한 연결이 언제 생기고 끊기는지 알 수 있었다.

ping 10.0.80.1    # Test connection to router
ping google.com   # Test connection to Internet

ifconfig

ifconfig 명령이 얼마나 도움이 되지 않는지 보고 놀랐다. 다음 명령들이 네트워크 설정을 강제로 초기화할 줄 알았다:

IFACE="eth0"

sudo ifconfig "${IFACE}" down && \
  sudo ifconfig "${IFACE}" up && \
  sudo ifconfig "${IFACE}"

종종 저 명령들을 실행해도 네트워크 상태가 초기화되지 않았다. 스위치 레벨에서 장치를 네트워크에서 제거한 뒤 ifconfig로 장치의 네트워크 인터페이스를 초기화해도, 장치는 여전히 이전 VLAN의 IP를 가지고 있다고 생각했다. 재부팅할 때까지 새 서브넷의 IP 주소를 가져오지 못했다.

dhclient

다른 사람들이 dhclient를 추천하는 것을 본 적이 있다. 이 명령어 순서는 호스트가 DHCP 리스를 해제하고 새로 요청하도록 강제하는 것이다:

dhclient -r
dhclient

테스트 시스템에서는 제대로 동작하지 않았다. 첫 번째 명령이 그냥 멈춰 버리고 DHCP 리스를 해제하지 않았다.

nslookup

이전에 많이 써보지 않았던 nslookup도 시도해 봤다. DNS 조회 결과를 알려주는 도구다.

nslookup은 결국 VLAN 디버깅에는 유용하지 않았지만, 알아두면 좋은 도구다.

주의할 점

TP-Link 스위치에서 VLAN을 설정하면서 겪은 함정들은 다음과 같다.

• VLAN에 언태그드 포트를 지정했지만 해당 포트의 PVID 설정을 잊었다.
• 포트를 VLAN에 추가했지만 같은 VLAN에 라우터 포트를 추가하는 것을 잊었다.
• VLAN을 인식하는 장치 A가 VLAN을 인식하는 장치 B를 통해 방화벽에 연결된다면, 장치 B는 A의 모든 VLAN을 알고 있어야 한다는 점을 잊었다. 그렇지 않으면 장치 B는 인식하지 못하는 VLAN의 패킷을 방화벽에 도달하기도 전에 단순히 드롭해 버린다.
• TP-Link 네비게이션 바에서 “Save” 버튼을 누르지 않으면, 다음에 스위치가 재부팅될 때 변경 사항이 모두 사라진다.