VPN을 통한 MariaDB: 서버는 어떤 user@host를 볼까
계정은 사용자와 호스트를 함께 기준으로 선택됩니다. 서버가 본 출발지를 찾아 CURRENT_USER()를 읽고, 그 행을 고치십시오. 권한이 아닙니다.
같은 사용자 이름을 두 개의 다른 경로로 입력하면 MariaDB가 당신을 두 개의 다른 계정으로 인증할 수 있습니다. 계정은 사용자와 호스트를 함께 기준으로 만들어지므로 'reporter'@'localhost'과 'reporter'@'10.90.0.23'은 서로 다른 비밀번호와 서로 다른 권한을 가진 별개의 행입니다. VPN을 통할 때 흥미로운 질문은 사용자가 어떤 이름을 입력했느냐가 아니라 서버가 어떤 출발지 주소를 보았느냐입니다.
서버가 실제로 보는 출발지를 확인하십시오
노트북이 아니라 데이터베이스 호스트에서 거꾸로 작업하십시오. 클라이언트가 가지고 있다고 믿는 주소는 여러 가능성 중 하나일 뿐입니다:
| Path | Source MariaDB sees |
|---|---|
| Routed tunnel, no translation | The client's inner VPN address |
| Gateway source translation | The gateway's translated address |
| SSH local forward | The SSH server's address |
| Public exit, no tunnel | Whatever the ISP handed out |
서버 측 증거로 판정하십시오. 연결 로그, 활성 세션 목록 또는 일반 로그의 임시 항목이 서버가 받아들인 주소를 보여 줍니다. 브라우저에서 본 노트북의 공인 IP는 다른 사실이며 종종 오해를 부릅니다.
MariaDB가 선택한 계정을 맞추십시오
계정 선택은 권한의 합집합이 아니라 문서화된 순서를 따릅니다. 정확한 호스트 일치가 와일드카드보다 우선하며, 익명 사용자 행은 이름만으로 결정된다고 가정하는 사람들을 놀라게 하는 방식으로 일치에 참여합니다. 서버는 한 행을 고르며, 같은 이름의 모든 행 권한을 합치지 않습니다. 참조 문서를 한 번 읽는 것이 반나절 추측을 시험하는 것보다 낫습니다.
즉, 세션이 'reporter'@'10.90.0.23'로 인증되었다면 'reporter'@'%'에 권한을 추가해도 아무것도 바뀌지 않을 수 있습니다. 수정은 선택된 행에 적용되어야 하므로 계정 식별이 권한 편집보다 먼저 옵니다.
세션이 실제로 사용하는 계정을 읽으십시오
SELECT USER(), CURRENT_USER();
SHOW GRANTS;CURRENT_USER()은 세션을 인증한 계정을 알려 주고, USER()은 클라이언트가 요청한 것을 보고하며 다를 수 있습니다. 이것들은 정의자 컨텍스트가 있는 저장 루틴 안이 아니라 일반 최상위 쿼리로 실행하십시오, 그렇지 않으면 답이 당신의 세션이 아니라 루틴 소유자를 설명합니다.
실패한 로그인은 이것들 중 아무것도 실행할 수 없으며, 관리자가 계정 정의와 서버의 연결 증거를 대신 검사해야 하는 경우가 바로 이때입니다. 그것을 대비하십시오: 거부된 로그인을 디버깅하는 사람에게는 보통 질의할 SQL 세션이 없습니다.
도달 가능성과 인증을 분리하십시오
오류 문구는 어느 계층에 있는지 알려 줍니다. 연결 거부나 시간 초과는 클라이언트가 리스너에 도달하지 못했다는 뜻이므로 계정과 비밀번호는 아직 문제가 아닙니다. 접근 거부 응답은 서버가 응답했다는 뜻이며, 이는 도달 가능성을 증명하고 계정, 호스트 일치 또는 자격 증명을 가리킵니다.
네트워크 전제 조건은 별도의 목록입니다: 루프백이 아니라 의도한 주소에 바인딩된 리스너, 설정된 포트로 허용된 트래픽, 응답을 위한 반환 경로입니다. 각각 독립적으로 실패할 수 있고, 작동하는 터널이 그중 어느 것도 보장하지 않습니다. 루프백의 리스너는 로컬 연결을 받아들이고 모든 원격 연결을 거부하므로 방화벽 차단처럼 보이는 연결 거부가 생깁니다.
네트워크 팀에 티켓을 열기 전에 바인드 주소를 확인하십시오. 데이터베이스 호스트의 ss -lntp은 어떤 주소와 포트가 실제로 수신 중인지 보여 주며, 그 한 줄이 추측의 범주 전체를 배제합니다.
좁게 고친 뒤 양방향을 다시 시험하십시오
의도한 호스트 한정 계정을 조직의 승인된 절차로 만들고, 자격 증명은 지원되는 저장소에서 가져오며 티켓에 붙여 넣은 공용 것을 쓰지 마십시오. 작업에 필요한 스키마 작업만 부여하십시오. 실패한 원격 로그인을 root 계정, 전부 허용 정책 또는 포괄적 와일드카드 호스트로 바꾸면 시험은 통과하지만 당신이 시험하던 통제가 사라집니다. 급하게 추가한 권한이 나중에 아무도 제거하지 않는 권한입니다.
의도한 경로로 새 세션을 사용해 다시 시험하고, 그다음 부정적 사례를 확인하십시오. 차단되어야 할 경로는 여전히 차단되어야 하고, 부여되지 않은 작업은 여전히 거부되어야 합니다. 그 두 확인이 고친 계정과 넓힌 계정을 구분합니다.
마지막으로 관찰한 출발지 주소와 계정 이름을 함께 기록하십시오. 터널은 도달 가능성을 제공하지만 MariaDB는 여전히 자체 계정을 선택하고 승인하며, 다음 사람이 당신의 결과를 재현하려면 두 사실이 모두 필요합니다.