VPN 센서가 지사의 VLAN 태그를 결코 보지 못하는 이유
라우팅된 터널은 패킷을 복원하지, 패킷을 실어 나른 프레임을 복원하지 않는다. 인터페이스 유형, 센서 위치, 출처 컨텍스트, 응답 경로에 대한 네 가지 점검.
VPN 쪽 센서는 두 지사 VLAN을 평범한 IP 트래픽으로 보며, 각 지사를 자체 회선에서 식별하던 태그는 사라졌다. 라우팅된 터널이 하는 일이 바로 그것이다. 패킷을 복원하며, 패킷을 전달한 Ethernet 프레임은 복원하지 않는다. 사라진 태그가 문제인지는 센서에 던지는 질문에 전적으로 달려 있다. 아래 네 가지 점검을 순서대로 하면 어느 관측 지점이 그 질문에 답할 수 있는지 알게 된다.
먼저, 터널이 무엇을 복원하는지 확정한다
TUN 인터페이스는 IP 패킷을 운반한다, 따라서 지사 프레임의 VLAN 헤더는 트래픽을 터널로 밀어 넣은 라우터에서 멈춘다. TAP 인터페이스는 Ethernet 프레임을 운반하므로, 브리지와 VLAN 허용 규칙이 통과시키면 태그가 살아남을 수 있다. 캡처에 무엇이 들어 있어야 하는지 따지기 전에 인터페이스 유형을 읽어라.
어느 선택도 결함이 아니다. 두 설계는 서로 다른 질문에 답하고 태그를 서로 다른 곳에 남긴다.
제품 이름에서 추론하지 말고 인터페이스를 직접 확인한다. 링크 세부 정보는 장치 종류를 알려 주고 적용 중인 플래그를 보여 주며, TUN 장치에서 찍은 캡처는 요청했다는 이유만으로 Ethernet 헤더를 얻지 못한다. TUN 캡처에 태그가 보인다면 거의 확실히 다른 인터페이스나 자체 페이로드 안에 프레임을 담아 나르는 터널을 읽고 있는 것이다. 계속하기 전에 어느 경우인지 기록한다.
다음, 객체가 아직 존재하는 위치에 센서를 둔다
세 위치가 대부분의 라우팅 설계를 포괄한다. 지사의 Ethernet 구간, 터널 양 끝 사이의 외부 네트워크, 터널 처리 이후의 경로다. 각각 다른 객체를 보며, 태그는 첫 번째에만 존재한다. 센서 위치를 고르는 것은 정책이 어떤 객체를 필요로 하는지에 대한 결정이며 편의의 문제가 아니다.
| Observation point | What is actually there | Question it can answer |
|---|---|---|
| Branch Ethernet segment | Tagged frames on the local wire | Which VLAN carried this frame here |
| Outer tunnel network | The protected carrier between endpoints | Which endpoints are exchanging traffic |
| After tunnel processing | Recovered IP packets | Which branch prefix the packet claims |
정책 질문을 표가 답할 수 있는 용어로 제기하면 보통 스스로 해결된다. 규칙이 패킷이 어느 지사에서 왔는지 알아야 한다면 하류의 프리픽스 매핑으로 충분할 수 있지만, 그 매핑이 정확하고 모호하지 않은 동안에만 그렇다. 규칙이 프레임이 어느 포트로 도착했는지 알아야 한다면 첫 번째 위치가 필요하다. 하류에서는 아무것도 그것을 재구성할 수 없다. 질문이 아니라 습관으로 배치된 센서 때문에 팀은 설계가 애초에 나른 적 없는 필드를 요구하게 된다.
Ethernet을 실어 나르는 터널은 다른 설계이며 양 끝이 무엇을 보존하거나 다시 쓰는지에 대한 자체 점검이 필요하다. TAP만 고르는 것으로는 여전히 브리지, VLAN 허용 규칙, 검사 정책이 정의되지 않는다.
셋째, 출처 컨텍스트를 신뢰하지 말고 확보한다
지사마다 주소 범위 하나를 두는 것은 VLAN 정체성의 흔한 대체물이며, 매핑이 일대일로 유지되는 동안에만 성립한다. 겹치는 프리픽스, 변환, 공유 게이트웨이는 각각 그 가정을 설계 문제가 아니라 데이터 품질 문제처럼 보이는 방식으로 깨뜨린다. 매핑을 경계와 함께 적고, 두 행에 일치하는 패킷이 어떻게 되는지 명시한다. 두 지사에 나타나는 프리픽스는 받아들이는 동전 던지기가 아니라 발견해야 하는 오류여야 한다.
클라이언트가 제공하는 컨텍스트는 소속의 증거가 아니다. 그것은 주장이며, 다른 열에 속한다.
구분이 중요한 곳에서는 직접 통제하는 연관 데이터를 사용한다. 어느 터널 인스턴스가 연결을 수락했는지, 패킷이 어느 인터페이스로 도착했는지, 그 피어에 대해 로컬 라우팅 테이블이 무엇이라고 하는지다. 클라이언트가 제공하는 레이블은 유용한 단서이며 쓸모없는 인가 입력이다. 센서가 자기 쪽에서 연관을 확립할 수 없다면, 정책에는 자신 있는 추측이 아니라 더 넓은 규칙이 필요하다.
넷째, 응답 경로와 복호화가 놓치는 것을 확인한다
한 방향만 보는 센서도 요청이 제때 계속 도착하기 때문에 건강해 보일 수 있다. 응답 경로를 명시적으로 점검하고, 일반적 도달 가능성이 아니라 같은 흐름에 대해 점검한다. 반이중 가시성은 그로부터 끌어내는 모든 상태 기반 결론에서 조용한 공백이 된다.
내부 IP 트래픽을 복원하는 것도 그 내부의 애플리케이션을 보는 것과 같지 않다. 터널 위로 운반되는 TLS는 여전히 TLS다.
ip -d link show tun0
tcpdump -i tun0 -n -e -c 5그 두 명령은 인터페이스 질문에 답하고 캡처가 실제로 무엇을 담는지 보여 주며, 아키텍처를 두고 논쟁하는 것보다 빠르다. 설계가 사용하는 인터페이스 이름으로 바꾸고 관심 있는 흐름이 활성인 동안 캡처를 실행한다. TUN 장치에 태그가 나타나지 않는다면, 센서가 데이터를 버린 것이 아니라 설계가 브리징 대신 라우팅했다는 것이 발견이다. 그다음 태그를 볼 수 있는 위치로 센서를 옮기거나, 현재 위치가 지탱할 수 있는 용어로 규칙을 다시 쓴다.