공용 Wi-Fi와 VPN: 터널이 덮지 않는 것

초록 배지, 만족한 포털, 작동하는 브라우저: 그것이 눈에 보이는 이야기의 전부다. 배지가 빠뜨리는 것은 암호화된 연결이 당신을 보호해야 할 바로 그 무선 링크에 의해 운반된다는 점이다. 그 링크는 여전히 모든 패킷을 전달하고, 목적지 주소를 보고 있으며, 무언가 도착할지도 결정한다. 호텔 연결의 노트북 쪽을 살펴보면 터널이 덮는 부분과 당신에게 남기는 부분이 보인다.

접속 링크가 모든 것을 운반한다

IPsec ESP 터널은 보호된 내부 패킷을 네트워크가 경로를 지정할 수 있는 외부 헤더로 감싸며, RFC 4303 3.1.2절이 그 분리를 설명한다. 내부 패킷은 터널이 보호하는 대상이다. 외부 헤더는 핫스팟이 전달하기 위해 읽는 것이다. 다른 설계는 다르게 캡슐화하지만 계획의 질문은 같다: 이 연결을 운반하는 접속 경로는 어느 것인가.

게이트웨이 장애나 패킷을 버리는 링크는 내용을 드러내지 않고 전달을 멈춘다. 더 강한 암호로 바꾸는 것은 빠진 조각이 암호가 아니라 전송이기 때문에 아무 소용이 없다. 성공적인 전달은 작동하는 경로가 어느 기계의 상태에 대해서도 아무 말도 하지 않으므로 반대 방향에서도 똑같이 적게 증명한다.

당신의 노트북에는 여전히 자기 문이 있다

신뢰할 수 없는 세그먼트에 참여하면 당신의 기계가 수신 대기하는 포트에 누가 도달할 수 있는지가 바뀐다. 파일 공유 서비스, 원격 관리 에이전트 또는 모든 인터페이스에 바인딩된 개발 서버는 무언가 막지 않는 한 그 세그먼트의 누구나 도달할 수 있다. 터널에 들어가지 않는 트래픽은 터널로 보호되지 않는다. 터널이 올라오기 전에 응답하는 수신 대기는 바로 그 창 동안 노출된다.

요구 사항은 좁고 정확히 말할 가치가 있다: 노트북은 VPN 종단에 도달해야 하고, 핫스팟의 무관한 장치는 로컬 서비스에 도달해서는 안 된다. 호스트 방화벽 규칙이 그 경계를 표현한다, 그리고 플랫폼 자체의 공유 설정도 그 일부를 표현한다. 프린터나 포털 단계는 의도적으로 추가하는 제한된 예외이며, 핫스팟 전체가 사무실 LAN의 신뢰를 받을 자격이 있다는 증거가 아니다.

일부 조직은 업무 연결이 활성화된 동안 로컬 접근도 제한하는데, 이는 공학이 아니라 정책이다. 주변 기기를 작동시키기 위해 방화벽을 끄기 전에 그 정책을 읽어라.

실제로 무엇이 수신 대기하는지 확인하라

설정 페이지가 아니라 소켓을 보라. 페이지는 의도를 설명하고 소켓 표는 기계를 설명한다. 아래 두 목록은 모든 수신 대기 소켓을 이웃이 도달할 수 있는 소켓과 분리하니, 터널을 연결하기 전에 신뢰할 수 없는 세그먼트에서 실행하라.

ss -lntu
ss -lntup | grep -v 127.0.0.1
resolvectl query vpn.example.net

첫 명령은 모든 소켓을 보여주고, 두 번째는 루프백 밖에 바인딩된 것으로 거른다. 0.0.0.0 또는 ::의 서비스는 무선을 포함한 모든 인터페이스에서 사용할 수 있지만, 127.0.0.1의 같은 서비스는 세그먼트에서 전혀 도달할 수 없다. 리졸버 질의는 터널이 존재하기 전에 이름이 어느 경로를 타는지 확인하며, 캡티브 포털이 간섭하는 곳이 바로 거기다. 일부 클라이언트는 응답을 바꾸는 인터페이스를 올리기 때문에 연결 후 목록을 다시 실행하라.

터널이 올라와 있는 동안에만 나타나는 포트는 덜 노출되지만, 그것을 아는 것은 여전히 가치가 있다. 절대 목록이 아니라, 터널이 추가한 것인 차이를 기록하라.

세션 중간에 새 신원을 받아들이지 마라

예상치 못한 경로 변경, 재연결 또는 포털 리디렉션은 다른 서버 신원을 받아들일 허가가 아니다. 클라이언트가 인증서나 키 불일치를 보고하면, 우회할 연결이 아니라 신원 발견으로 취급하라. 포털을 작동시키기 위해 설명 없는 루트 인증서를 설치하는 것은 전달 문제를 신뢰 문제로 바꾼다. 그러면 신뢰 문제는 그것을 만든 여행보다 오래 살아남는다.

포털 자체의 브라우저 흐름을 사용한 뒤 터널을 다시 연결하고, 클라이언트 로그에서 확인한 신원을 읽어라. 신원 실패는 상대가 기대한 사람이 아님을 뜻하고, 전달 실패는 상대가 결코 응답하지 않았음을 뜻한다. 전자는 멈출 이유이고, 후자는 다른 경로를 시도할 이유다.

먼저 장애 시 동작을 정하라

여기서 서로 다른 두 기능이 혼동된다. 재연결은 서비스를 복구하려 하고, 차단 정책은 터널이 내려간 동안 어떤 트래픽이 허용되는지 제어한다. 어느 것도 작동하는 무선 링크를 제공하지 않고, 어느 것도 종단이 깨끗하다고 증명하지 않는다. 명시적으로 선택하라: 로컬 경로를 절대 써서는 안 되는 애플리케이션에는 닫힌 실패를, 허용된다면 터널 밖의 일반 브라우징을 허용하라.

선택을 적어 두라. 대부분 클라이언트의 기본값은 둘 중 어느 것도 아니고 버전에 따라 다르다. 그런 다음 가용성이 중요하다면 자체 데이터 요금제가 있는 휴대전화 핫스팟 같은 대체 접속 경로를 마련하고, 통과할 수 있는 인수 테스트에서는 의도한 트래픽이 검증된 터널을 사용하고 무관한 로컬 수신 대기가 도달 불가하며 장애가 당신이 고른 동작을 만들어 내는 세 가지 별개의 결과를 확인하라.