VPN 라우터의 LAN과 WAN: 구매 전에 기록할 것
VPN 표시만으로는 VLAN, WAN 장애 조치, 터널 역할을 알 수 없습니다. 도입하려는 모델과 펌웨어의 정확한 기능을 적어 두십시오.
VPN 지원 표시는 라우팅과 분할, 장애 시 전환까지 맡는 장비의 한 기능으로 취급해야 하며, 표시만으로는 장치가 얼마나 많은 별도 네트워크를 수용할 수 있는지 알 수 없습니다. 정확한 모델과 펌웨어에 대한 기능 기록을 먼저 쓰고, 그 기록을 현장에 필요한 흐름과 비교하십시오. 마케팅 페이지는 포트 수를 나열하지만 VLAN 소속, 장애 조치 정책, 터널 범위까지 적는 경우는 드뭅니다. 기록에는 약 이십 분이 걸리며 하드웨어가 도착하기 전에 구매 논쟁 대부분을 정리합니다.
무엇보다 먼저 정확한 장비를 고정하십시오
모델 이름은 펌웨어 세대를 넘나들고, 같은 인클로저도 릴리스에 따라 다른 스위치 드라이버로 출하될 수 있습니다. 보드 식별 정보는 상자가 아니라 장치 자체에서 읽어야 이후의 모든 주장이 재현 가능한 대상에 묶입니다. OpenWrt에서는 명령 하나로 모델, 보드 이름, 펌웨어 릴리스가 나오며, 같은 화면이 대부분의 비즈니스 펌웨어에도 있습니다.
ssh [email protected] 'ubus call system board'
cat /etc/openwrt_release그 문자열을 줄이지 말고 기록에 적으십시오. 다음으로 일반 라우팅 작업과 터널 작업을 분리하십시오. 패킷 전달을 잘하는 장치도 터널 종단을 거부할 수 있고, 터널을 종단하는 장치도 두 로컬 네트워크를 분리할 방법이 없을 수 있습니다. 둘을 하나의 요구로 취급하면 장치가 이미 랙에 설치되고 설정되어 절반쯤 신뢰받을 때까지 불일치가 숨습니다.
포트 수가 아니라 LAN 구조를 기록하십시오
포트 네 개는 보통 스위치 하나를 뜻하고, VLAN을 설정하지 않으면 스위치는 브로드캐스트 도메인 하나를 뜻합니다. 평평한 가정 네트워크에는 맞지만 같은 장비에 게스트 세그먼트, 관리 세그먼트, 격리된 카메라 세그먼트를 원하는 현장에는 틀립니다. 어떤 포트가 어떤 VLAN에 속하는지, 어떤 VLAN이 CPU에 도달하는지, 어떤 인터페이스가 주소를 갖는지 기록하십시오.
펌웨어가 VLAN을 제공하는 곳에서는 인터페이스 목록이 몇 가지 정책을 쓸 수 있는지 결정합니다. 스위치에 정의되었지만 인터페이스로 할당된 적 없는 VLAN은 주소도 방화벽 영역도 없으므로 단독으로는 아무것도 강제할 수 없습니다.
| Field to record | Example entry | Review stops if |
|---|---|---|
| Ports and VLAN membership | ports 1-4 untagged on VLAN 10, port 5 trunk with VLAN 10 and 20 | the datasheet offers only a socket count |
| Routed interfaces | br-lan 192.168.88.1/24, vlan20 192.168.99.1/24 | two subnets cannot hold separate policies |
| WAN method and failover | DHCP on wan, PPPoE on wan2, policy route to wan2 on loss | only one uplink is configurable |
| Tunnel role and scope | WireGuard peer on the router, only 192.168.88.0/24 routed inside | the router can only pass another tunnel through |
메뉴를 믿지 말고 스위치 상태를 읽으십시오. 구형 OpenWrt 대상에서는 스위치 도구가 설정된 장치를 출력하고, DSA 대상에서는 브리지 도구가 포트별로 같은 사실을 보고하므로 펌웨어 릴리스가 기록에 들어갑니다.
WAN과 장애 조치 동작을 적으십시오
접속 방식, 주소 소유, 장애 조치 순서는 WAN 변경을 견디는 터널이 이 세 가지에 모두 의존하므로 업링크마다 한 줄에 들어갑니다. PPPoE 세션은 새 주소로 다시 연결되며 터널도 함께 끊지만, 임대를 유지하는 DHCP 업링크는 그렇지 않을 수 있습니다.
장애 조치에는 정책 결정도 필요합니다. 모든 트래픽을 예비 링크로 보내는 것은 쉽지만, 일반 웹 트래픽이 예비를 쓰는 동안 터널을 주 링크에 두려면 정책 기반 라우팅이 필요하고 모든 펌웨어가 이를 제공하지는 않습니다. 터널이 업링크 하나에 묶여 있는지, 그 링크가 사라질 때 장치가 기존 세션을 어떻게 처리하는지 적으십시오. 장애 조치 체크박스가 아니라 라우팅 테이블을 증거로 남기십시오.
허용되는 흐름 하나와 거부되는 흐름 하나를 시험하십시오
기록은 그에 따라 장치를 검수할 수 있을 때만 보관할 가치가 있습니다. 통과해야 하는 흐름 하나와 통과하면 안 되는 흐름 하나를 골라, 해당 세그먼트의 클라이언트에서 둘 다 실행하십시오. 모든 서브넷을 나르는 터널은 요구가 서브넷 하나였을 때 실패입니다.
허용적인 기본값이 늘 놀라움을 주므로 그다음 거부를 확인하십시오. 게스트 세그먼트는 관리 주소에 도달해서는 안 되고, 검사는 로그인 페이지가 아니라 시간 초과나 거부를 보여야 합니다.
curl -sS --max-time 8 https://api.ipify.org
ping -c 2 192.168.99.1
ip -4 route get 192.168.99.1허용한 흐름이 통과하고 거부한 흐름도 통과하면 메뉴가 시사한 것과 달리 분할이 빠져 있습니다. 둘 다 실패하면 터널 범위나 반환 경로가 잘못되었고, WAN 기록이 보통 어느 쪽인지 설명합니다. 두 결과를 기능 기록과 함께 보관해 다음 검토자가 무엇을, 어느 펌웨어에서, 어느 날짜에 수용했는지 보게 하십시오.