라우티드 VPN인가 브리지 VPN인가: 클라이언트가 무엇에 도달해야 하는지로 고르기
라우티드 액세스는 선택한 서비스를 전달하고, 브리지 액세스는 세그먼트에 참여합니다. 클라이언트가 무엇에 도달해야 하는지로 결정한 뒤 구축한 경계를 검증하세요.
같은 날 두 건의 티켓이 들어옵니다. 한 사용자는 내부 웹 앱이 필요하고, 한 엔지니어는 벤치 계측기가 같은 Ethernet 세그먼트에 있는 것처럼 동작해야 합니다. 둘 다 VPN에 넣으라고 답하는 순간 문제가 시작됩니다. 라우티드 터널과 브리지 터널은 서로 다른 관계를 확장하며, 각 요청에 맞는 것은 둘 중 하나뿐입니다. 토폴로지를 고르는 것은 액세스 결정이지 암호 설정이 아닙니다.
티켓 창구에서 똑같아 보이는 두 요청
직원의 요구는 서비스입니다. 당신이 통제하지 않는 기기에서 IP로 도달할 수 있어야 합니다. 엔지니어의 요구는 링크 계층에 있습니다: 계측기는 Ethernet 프레임과 브로드캐스트 탐색을 보기를 기대합니다, 그리고 자기가 있다고 믿는 세그먼트의 DHCP도 기대할 수 있습니다.
서로 다른 질문이며, 둘 다 브리지로 답하면 이유 없이 직원의 액세스가 사무실 LAN 전체로 넓어집니다.
고르기 전에 요구를 한 문장으로 쓰세요. 어떤 목적지, 어떤 프로토콜, 어떤 상대가 로컬로 보여야 하는지. 답이 호스트와 포트라면 라우팅으로 충분합니다. 답이 브로드캐스트만 말하는 기기와의 프레임 수준 관계라면 브리지가 유일한 선택일 수 있습니다. 그 중간은 모두 운영 LAN이 아니라 테스트 세그먼트에 어울립니다.
라우트는 LAN 구성원 자격보다 좁다
라우티드 클라이언트는 터널 서브넷의 주소와 선택한 프리픽스에 대한 라우트를 받습니다. 정책이 그렇게 말한다면 애플리케이션 서버에만 도달하고 다른 곳에는 닿지 않습니다. 게이트웨이가 적용 지점이 됩니다. 관련된 모든 경로가 게이트웨이를 지난다는 조건에서만 그렇습니다.
라우트와 권한을 혼동하지 마세요. 클라이언트에 서브넷에 도달하는 방법을 알려줘도 다른 목적지를 시도하는 것은 막지 못합니다.
트래픽을 실제로 강제할 수 있는 곳에 액세스 제어를 적용하고, 애플리케이션 자체의 권한은 그대로 두세요. 넓은 포워딩 규칙이나 잊힌 두 번째 인터페이스는 다이어그램이 시사하는 것보다 더 많은 것을 허용할 수 있습니다. 의도한 규칙이 아니라 실제로 유효한 규칙을 읽으세요. 그런 다음 실패해야 하는 목적지를 시험하세요. 아무도 위반을 시도하지 않은 정책은 가설일 뿐입니다.
브리지는 입장 질문을 바꾼다
브리징은 물리 인터페이스와 TAP 장치를 소프트웨어 스위치로 결합하므로 원격 장치가 같은 브로드캐스트 도메인에 참여합니다. 이것은 실제 역량이자 실제 위험입니다. 원격 장치는 더 이상 라우티드 손님이 아니라 참가자입니다.
어떤 장치가 참여할 수 있는지, 어떤 프레임 유형이 통과해야 하는지, 원치 않는 상호작용이 어디에서 차단되는지 정하세요. 주소 지정과 DHCP 권한은 공유 네트워크의 일부가 되며, 한 세그먼트에 두 개의 DHCP 서버가 있으면 예상대로 혼란이 생깁니다.
계측기에는 사무실 LAN보다 전용 테스트 세그먼트가 보통 더 적합합니다. 관리 액세스는 실험 밖에 두고, 작업이 끝났을 때 임시 참가자를 어떻게 제거할지 정하세요.
필터링은 두 토폴로지 모두에 있다
브리지가 본질적으로 필터링 불가능한 것도 아니고, 라우트가 본질적으로 안전한 것도 아닙니다. Linux 브리지 필터링에는 자체 훅과 자체 규칙 문법이 있으며, 라우티드 IP 포워딩용으로 작성한 규칙이 브리지된 프레임에 자동으로 적용되지는 않습니다.
경계를 약속하기 전에 플랫폼이 실제로 무엇을 지원하는지 확인하세요:
bridge link show
nft list ruleset
TUN과 TAP은 암호가 아니라 인터페이스의 트래픽을 설명합니다. 인터페이스를 바꾼다고 그중 무엇도 고쳐지지 않습니다. 피어 인증, 도난당한 키, 오래된 암호 정책은 모두 변경 후에도 남습니다. 양쪽 끝에는 여전히 일치하고 여전히 지원되는 설정이 필요합니다.
세 번의 시도로 경계를 증명하세요
승인은 세 가지 관찰이지 다이어그램 검토가 아닙니다. 필요한 작업이 되어야 하고, 무관한 목적지는 실패해야 하며, 게이트웨이 자체의 관리 서비스는 손이 닿지 않아야 합니다.
같은 클라이언트에서 허용 경로와 거부 경로를 모두 실행하고 둘 다 기록하세요:
curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5
브리지의 경우 링크 수준 점검을 추가합니다. 허용된 탐색 트래픽이 통과하는지, 주소 지정이 의도한 권한에서 오는지, 임시 참가자가 제거 후 사라졌는지. 일반 라우티드 IP가 이미 요구를 충족한다면 사무실 Ethernet 세그먼트에 참여하려면 별도의 정당화가 필요하고, 그것은 변경 전에 기록되어야 합니다.