VPN을 켜면 클라우드 방화벽이 보는 주소

VPN에 연결하기 전에는 동작하고 연결한 뒤에는 실패하는 데이터베이스는 자격 증명 문제인 경우가 드뭅니다. 클라우드 방화벽은 소스 주소를 대조하고, 전체 터널은 그 대조 대상 주소를 바꿔 버립니다. 노트북이 보낸다고 생각하는 주소와 서버가 받는 주소의 차이가 버그의 전부이며, 한 단계로 측정할 수 있습니다.

소스 주소는 무엇이 되는가

전체 터널에서는 모든 패킷이 VPN 게이트웨이를 통해 나가므로, 서버는 집 인터넷 연결이 아니라 게이트웨이의 이그레스 주소를 봅니다. 경로에 포워드 프록시가 있으면 그 주소가 도착합니다. 둘 다 정당한 소스이며, 원래 규칙에 있는 주소는 어느 쪽도 아닙니다.

Azure SQL의 서버 수준 및 데이터베이스 수준 방화벽 규칙은 논리 서버에 도달하는 클라이언트 주소를 대조하며, 전체 터널 후에는 그것이 이그레스 주소입니다. 단일 주소를 허용하는 AWS 보안 그룹도 같은 방식으로 동작합니다. 패킷은 인증 전에 버려지므로, 돌아오는 오류는 권한 문제가 아니라 네트워크 장애처럼 보입니다. 사람들이 비밀번호 재설정을 시작하는 이유가 바로 그것입니다.

허용 목록은 어디서 결정되는가

실패하는 경로에 맞는 규칙을 읽고, 기억하는 규칙이 아니라 실제 규칙을 보세요. 범위, 포트, 프로토콜, 그리고 어떤 신원 확인보다 먼저 평가되는지 확인합니다.

그다음 어떤 계층이 그 결정을 정당하게 소유하는지 정합니다. 주소 규칙은 트래픽이 어디서 오는지 답합니다. 프라이빗 엔드포인트는 서비스가 프라이빗 경로로 도달 가능한지 답합니다. 분할 터널 예외는 어떤 대상이 터널을 우회하는지 답합니다. 서로 교환할 수 없고, 터널이 바뀌면 각각 다른 방식으로 실패합니다.

세 가지 수리, 세 계층

아래 각 선택지는 다른 이유로 흐름을 고치며, 잘못 고르면 다음 게이트웨이 변경까지만 동작하는 연결이 됩니다.

이그레스 주소를 추가하는 것은 새 게이트웨이나 다른 리전이 조용히 무효화하기 때문에 가장 작은 변경이자 가장 취약한 방법입니다. 주소를 터널 정의 옆에 기록해 둘을 함께 움직이게 하세요. 임시 넓은 범위는 진단이지 수리가 아니며, 그대로 두는 것이 내부 서비스가 노출되는 경로입니다.

관리형 플랫폼이 터널에 참여할 수 없는 이유

Heroku, AppHarbor, CloudBees 같은 애플리케이션 플랫폼은 tun 또는 tap 장치가 없고 만들 권한도 없는 환경에서 코드를 실행합니다. 인바운드 모델은 임의의 수신 소켓이 아니라 HTTP입니다. VPN 바이너리를 포함한 빌드팩도 인터페이스를 둘 자리가 없습니다. 실행 가능한 방식은 데이터베이스가 허용할 수 있는 고정 이그레스 주소, 플랫폼이 제공하는 프라이빗 연결 제품, 또는 HTTPS로 도달하는 DMZ의 프록시입니다.

그 프록시는 자체 인증과 로깅을 갖는 접근 경로입니다. 플랫폼을 VPN의 구성원으로 만들지 않으며, 그렇게 설명하면 아무도 감사할 수 없는 규칙이 생깁니다.

실패한 클라이언트에서 검증하세요

다시 연결하고 클라이언트의 정확한 경로를 반복하세요. 서비스가 기록하는 소스 주소, 클라이언트가 데이터베이스 이름에 대해 선택하는 경로, 실제 쿼리의 결과를 이 순서로 확인합니다. 게이트웨이에서의 테스트는 게이트웨이가 동작함을 증명할 뿐이며, 그것은 의심된 적이 없습니다. 연결이 이제 인증되는데 쿼리가 여전히 실패한다면 남은 문제는 데이터베이스 권한입니다.

터널이 바뀔 때마다 이 규칙을 검토하세요. 교체된 게이트웨이나 새 이그레스 범위는 애플리케이션 구성을 전혀 바꾸지 않고도 경로를 끊습니다.