Debugging VLANs on my TP-Link Managed Switch

2023-07-04

Michael Lynch

내 TP-Link 매니지드 스위치에서 VLAN 디버깅하기

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

매니지드 스위치의 핵심 기능은 네트워크를 VLAN으로 나눌 수 있다는 점입니다. 이 기능이 무척 기대됐지만, VLAN을 제대로 동작시키기까지 수시간의 시행착오가 필요했습니다.

TP-Link VLAN 문서가 부족하다고 느껴 다른 분들께 도움이 될까 하여 제가 정리한 내용을 공유합니다.

배경

VLAN이 익숙하지 않다면 제가 가장 좋아하는 설명 영상인 Raid Owl의 VLAN 설명 영상을 추천합니다.

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

제조사마다 VLAN 기능을 설명하는 용어가 조금씩 다릅니다.

TP-Link 스위치에서는 다음 세 가지 설정을 알아두면 됩니다.

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

태그드 포트

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

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

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

예시: 포트 하나를 VLAN 10과 20에 태그드 포트로 추가한 모습. 스위치는 VLAN 10과 20으로 태그된 트래픽은 허용하지만, VLAN 30으로 태그된 패킷 같은 다른 트래픽은 차단합니다.

언태그드 포트

포트 하나를 VLAN에 언태그드 포트로 추가해도 스위치는 해당 포트에 연결된 장치가 그 VLAN으로 트래픽을 주고받을 수 있도록 허용한다는 점은 태그드 포트와 같습니다. 차이점은 스위치가 패킷을 포트로 전달하기 전에 네트워크 패킷에서 VLAN 태그를 제거한다는 것입니다.

언태그드 포트는 일반 데스크톱 PC, 스캐너, 프린터처럼 VLAN을 이해하지 못하는 장치에 사용합니다. 포트에 연결된 장치가 VLAN을 전혀 모르기 때문에 스위치가 VLAN 태그를 제거하는 것입니다.

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

PVID

TP-Link 스위치에서는 각 포트마다 PVID, 즉 port VLAN identifier가 있습니다. 연결된 장치에서 해당 포트를 통해 패킷이 스위치로 들어오면, 스위치는 그 포트의 PVID를 VLAN 태그로 패킷에 추가합니다.

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

VLAN을 이해하는 장치에 연결된 포트에는 PVID를 설정할 필요가 없습니다. 해당 장치들이 스스로 VLAN 태그를 추가하기 때문입니다.

반면 VLAN을 이해하지 못하는 장치에 연결된 포트에는 PVID를 반드시 설정해야 합니다. 스위치가 그 장치를 대신해 올바른 VLAN 태그를 붙여야 하기 때문입니다.

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

TP-Link는 VLAN 설정을 이름이 비슷한 여러 메뉴 속에 숨겨 두었습니다. 처음에는 제대로 된 설정을 건드리고 있는 건지조차 확신이 서지 않았습니다.

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

상단 내비게이션 바에서 “L2 Features”를 클릭합니다
왼쪽 사이드바에서 “VLAN”을 클릭합니다
하위 메뉴에서 “802.1Q VLAN”을 클릭합니다

TP-Link 웹 인터페이스의 VLAN 설정 스크린샷 — TP-Link 매니지드 스위치에서 VLAN 설정을 찾는 방법

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

“Port Config” 탭에서는 각 포트의 PVID를 설정할 수 있습니다. 앞서 말했듯이 PVID는 VLAN에 속해야 하는 비 VLAN 장치에 직접 연결된 포트에만 설정하면 됩니다. 특정 포트에 PVID를 설정한다면, 해당 포트는 하나의 VLAN에만 언태그드 포트로 속해야 합니다.

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

일부 스위치는 설정에서 PVID를 아예 노출하지 않습니다. 태그드 포트와 언태그드 포트만 보여주고 스위치가 PVID를 자동으로 설정해 줍니다.

QNAP 스위치의 한층 더 나은 VLAN 관리 인터페이스를 보여주는 Raid Owl 영상 스틸컷 — QNAP 매니지드 스위치의 VLAN 관리 인터페이스 스크린샷. QNAP 인터페이스는 TP-Link보다 훨씬 직관적입니다.

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 무선 액세스 포인트
VLAN 간 또는 인터넷으로 나가는 패킷에 방화벽 규칙을 적용하는 OPNsense 방화벽
일부 VM의 네트워크 인터페이스에 VLAN ID를 태깅하는 Proxmox 서버

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

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

TP-Link TL-SG3428X를 구입한 뒤 기존 언매니지드 스위치를 그대로 교체했습니다. 네트워크 다이어그램 자체는 크게 달라지지 않았습니다.

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

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

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

언매니지드 스위치를 매니지드 스위치로 교체하자 매니지드 스위치가 무선 액세스 포인트에서 오는 VLAN 태그 트래픽을 버리기 시작했습니다.

해결책은 매니지드 스위치에 기존 VLAN 정보를 알려주는 것이었습니다. 그러지 않으면 스위치는 계속해서 VLAN 태그가 붙은 패킷을 모두 버릴 것이기 때문입니다.

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

VLAN ID	VLAN 이름	포트(태그드)
1	System	전체
10	Trusted	1(방화벽), 17(무선 액세스 포인트)
20	Guest	1(방화벽), 17(무선 액세스 포인트)

이 설정 변경 후 Wi-Fi 장치들의 인터넷이 다시 연결됐습니다. 스위치가 VLAN 태그를 인식하고 트래픽을 OPNsense 방화벽으로 전달한 덕분이었습니다.

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

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

RJ45 케이블이 꽂힌 채 손에 들고 있는 작은 장치 사진 — 우리 집 외부 태양광 패널 상태를 추적하는, 네트워크상의 신뢰할 수 없는 IoT 장치

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

그래서 OPNsense 방화벽에서 게스트보다도 더 신뢰하지 않는 장치들을 위한 “Purgatory”라는 새 VLAN을 만들었습니다. Purgatory에 속한 장치는 DNS 서버와 공인 인터넷 IP에는 접근할 수 있지만 다른 어떤 VLAN에도 접근할 수 없습니다. OPNsense 방화벽에서 새 VLAN을 만드는 방법

DNS를 허용하고 내부 네트워크로의 트래픽을 차단하는 Purgatory용 OPNsense 방화벽 규칙 스크린샷 — Purgatory VLAN의 방화벽 규칙

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

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

TP-Link 스위치의 Purgatory VLAN 스크린샷. 포트 24가 언태그드 포트로 VLAN에 속해 있으며, 다른 멤버는 없습니다. — 신뢰할 수 없는 IoT 장치를 Purgatory VLAN에 언태그드 포트로 추가했습니다.

TP-Link 포트 설정에서 포트 24의 PVID가 80으로 표시된 스크린샷 — 신뢰할 수 없는 IoT 장치를 Purgatory VLAN에 언태그드 포트로 추가했습니다.

하지만 동작하지 않았습니다. 클라우드 대시보드에 즉시 IoT 장치가 오프라인으로 표시됐습니다.

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

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

OPNsense 방화벽을 확인해 보니 Purgatory VLAN에서는 트래픽이 전혀 보이지 않았습니다. DHCP 설정을 확인해 Purgatory VLAN용 DHCP 서버가 동작 중인지도 확인했고, 정상적으로 동작하고 있었습니다.

사흘 밤을 머리를 쥐어뜯으며 원인을 찾다가 마침내 깨달았습니다. OPNsense 방화벽을 Purgatory VLAN에 추가하지 않았던 것입니다!

당시 상황은 이러했습니다.

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

해결책은 간단했습니다. OPNsense 방화벽을 Purgatory VLAN에 추가하는 것이었습니다. 방화벽은 VLAN을 이해하는 장치이므로 태그드 포트로 추가했습니다.

TP-Link 스위치의 Purgatory VLAN 스크린샷. 포트 24는 언태그드 포트로, 포트 1은 태그드 포트로 VLAN에 속해 있습니다. — IoT 장치가 OPNsense 방화벽을 통해 인터넷에 도달할 수 있도록 수정한 Purgatory VLAN용 TP-Link VLAN 설정

VLAN ID	VLAN 이름	포트(태그드)	포트(언태그드)
80	Purgatory	1(방화벽)	24(IoT 장치)

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

이렇게 변경하자 IoT 장치가 클라우드 대시보드에 연결됐고, 우리 집 네트워크로부터 적절히 격리되었습니다.

VLAN 문제 디버깅 팁

VLAN 문제를 디버깅할 때 가장 어려웠던 점 중 하나는 설정 변경이 어떤 효과를 내는지 관찰할 방법을 찾는 것이었습니다. 포트 하나를 태그드 포트에서 언태그드 포트로 바꾸면 그 차이가 있는지 어떻게 테스트할 수 있을까요?

Wireshark 켜기

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

평소에는 Wireshark를 꺼리는 편입니다. 훌륭한 도구이긴 하지만 문제와 관련된 정보를 찾다 보면 항상 길을 잃곤 합니다. Wireshark를 열 때마다 필터 쿼리 언어를 다시 익혀야 할 것 같아 별로 내키지 않습니다.

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

Wireshark 스크린샷 — Wireshark 출력 덕분에 스위치가 테스트 장치에서 오는 트래픽을 모두 버리고 있다는 것을 깨달았습니다.

재부팅

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

네트워크 상태를 초기화하는 가장 믿을 만한 방법이 이것이라는 사실이 아쉽지만, 실제로 그랬습니다. 호스트가 어떤 시스템을 실행하느냐에 따라 30~90초가 걸리므로 테스트 주기가 느려져 번거롭습니다. 하지만 스위치의 VLAN 설정을 바꿨을 때 다른 어떤 방법보다도 확실하게 시스템의 네트워크 상태를 초기화해 주었습니다.

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

원격 관리 도구 활용하기

TinyPilot은 제가 만든 제품이라 편향된 의견일 수 있지만, VLAN 문제를 디버깅하는 데 TinyPilot이 도움이 됐습니다.

처음에는 Proxmox VM 서버의 VM에서 VLAN을 디버깅해 보려 했지만, 실제로 시뮬레이션하려는 IoT 장치와는 너무 달랐습니다. Proxmox 서버는 VLAN을 이해하는 장치인 반면, 제가 테스트하려던 것은 비 VLAN 장치였기 때문입니다. Proxmox 서버를 언태그드 포트로 취급하면 Proxmox 서버 자체에 아예 접속할 수 없게 됩니다.

TinyPilot 덕분에 테스트 중인 장치가 네트워크 연결을 잃더라도 항상 접근할 수 있었습니다. 모든 설정을 브라우저 탭으로 진행하므로 메인 데스크톱에서 모든 작업을 처리할 수 있었습니다.

한 브라우저 창에서는 베어메탈 테스트 서버를 제어하고 다른 창에서는 해당 스위치 포트의 VLAN 설정을 조정하는 데모

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” 버튼을 누르지 않으면 다음에 스위치가 재부팅될 때 변경 사항이 모두 사라집니다.