공유 TAP VPN이 여전히 포털에서 HTTPS를 필요로 하는 이유

두 장치가 유효한 VPN 자격 증명을 보유하고 하나의 브리지된 이더넷 세그먼트를 공유합니다. 이 중 하나만 사무실 포털을 대신해 응답해야 하지만, 다른 하나도 그 세그먼트에서 포털 주소를 여전히 주장할 수 있습니다. 터널은 제 역할을 했습니다. 두 피어를 인증하고 서버로 가는 각 경로를 암호화했습니다. 하지 않은 일은 둘 중 누가 서비스 이름을 소유하는지 보증하는 것이며, 포털에 여전히 유효한 인증서가 필요한 이유가 바로 이 간극입니다.

VPN이 실제로 인증하는 것

VPN 핸드셰이크는 한 가지 질문에 답합니다. 어떤 피어가 어떤 키 자료로 이 터널을 완료했는가. 그 답은 피어별, 연결별이며 그 피어가 이후에 노출하는 서비스에 대해서는 아무것도 말하지 않습니다. TAP 세그먼트에서 피어는 단일 주소조차 아닙니다. 브리지가 학습하려는 어떤 MAC과 어떤 IP든 제시할 수 있기 때문입니다. 인증은 애플리케이션이 아니라 터널 끝점에서 멈춥니다.

세 질문을 하나로 합치지 말고 분리하십시오. 각각 고유한 메커니즘과 고유한 실패 방식을 가집니다.

배포 환경에서는 완벽하게 인증된 터널과 그 뒤의 전혀 인증되지 않은 서비스가 함께 존재할 수 있습니다. 또한 두 번째 계층 주소를 다른 피어가 주장하는 호스트에 검증된 인증서가 있을 수도 있습니다. 그래서 둘 중 하나가 다른 하나를 대체하는 것이 아니라 두 통제가 모두 설계에 포함되어야 합니다. 표는 그 논증 전체를 세 줄로 보여 줍니다.

공유 세그먼트의 ARP는 주소록이 아닙니다

ARP는 로컬 링크에서 IPv4 주소를 MAC에 매핑하고 그 링크의 누구로부터든 응답을 받아들입니다. 관대한 브리지 세그먼트에서는 피어가 다른 장치에 속한 주소를 주장할 수 있고, 브리지는 가장 최근에 응답한 쪽으로 프레임을 전달합니다. 서버로 가는 각 클라이언트 경로를 암호화해도 프레임은 브리지에 도달하기 전에 복호화되므로 달라지지 않습니다. ARP의 신뢰 경계는 터널이 아니라 세그먼트입니다.

호스트가 실제로 무엇을 배웠는지 보십시오. ip neigh show는 현재 매핑과 그 상태를 나열하며, 정상 운영 중 두 MAC 주소 사이를 오가는 항목은 무시할 것이 아니라 조사할 가치가 있는 징후입니다. 건강한 소규모 세그먼트에서는 그러한 항목이 오랫동안 안정적으로 유지됩니다.

피어 격리와 브리지 정책은 바로 이 경우를 위해 존재합니다. 서비스가 IP만이고 장치가 서로의 프레임을 볼 이유가 전혀 없다면 라우팅 설계가 대개 더 나은 답입니다.

인증서 검증은 서비스가 있는 곳에 두십시오

애플리케이션 TLS는 터널이 답할 수 없는 질문에 답합니다. 내가 도달하려던 서비스가 이것인가. 브라우저는 호스트 이름을 인증서와 대조하며, 그 검사만이 체인에서 피어가 아니라 포털을 지목하는 유일한 부분입니다.

경고가 겉치레라고 판단하기 전에 서버가 무엇을 제시하는지 확인하십시오. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal는 체인과 주체 대체 이름을 출력합니다. 입력한 이름이 그 목록에 없으면 경고는 옳고 고쳐야 할 것은 인증서입니다. 사용자에게 경고를 무시하도록 가르치는 것은 작동하는 통제를 장식으로 바꿉니다.

OpenVPN 브리징 안내서 는 이더넷 모델과 그 주변의 정책 옵션을 설명하며, 세그먼트가 무엇을 허용해야 하는지에 대한 올바른 참조입니다. 브리지 규칙을 완화하기 전에 읽어 보십시오. 그 안내서가 설명하는 모델이 위의 모든 점검이 전제하는 바로 그것이기 때문입니다.

그 피어들이 세그먼트를 공유해야 하는지 결정하십시오

요구 사항이 IP 도달성뿐이라면 가장 저렴한 해결책은 대개 두 번째 계층 공유를 중단하는 것입니다. 라우팅 VPN은 각 클라이언트에 자체 주소를 부여하고 공유 브로드캐스트 도메인을 제거하며 피어 간 트래픽을 기본값이 아닌 정책 결정으로 바꿉니다. 그러면 포털에는 보호할 주소가 하나뿐이고 그것을 주장할 이웃도 없습니다.

세그먼트를 유지해야 한다면 클라이언트가 서로 도달하도록 허용하는 서버 측 설정을 확인하십시오. grep -n client-to-client /etc/openvpn/server.conf. 이 설정이 비활성화되면 클라이언트 트래픽이 서버를 거치며 그곳에서 필터링할 수 있습니다. 활성화되면 피어가 브리지를 통해 직접 프레임을 교환하며 필터링 지점은 브리지와 호스트 방화벽입니다.

각 호스트가 실제로 어떤 보호에 의존하는지 적어 두십시오. 터널 인증, 세그먼트 격리 또는 애플리케이션 TLS입니다. 세 가지 모두에 의존하는 호스트는 괜찮습니다. 첫 번째에만 의존하고 나머지 둘도 함께 온다고 가정하는 호스트가 결국 잘못된 콘텐츠를 제공합니다.