VPN을 통한 MySQL localhost: 여전히 로컬 프로세스를 뜻합니다

사무실 서버의 애플리케이션은 localhost로 MySQL에 연결하고, 여러분은 그 호스트 이름을 데스크톱 클라이언트에 복사하며, 연결은 실패하거나 다른 데이터베이스를 엽니다. VPN은 이 단어의 의미를 바꾸지 않았습니다: localhost는 여전히 클라이언트를 실행하는 머신을 가리킵니다. VPN이 옮긴 것은 패킷이지 인터페이스가 아닙니다. 경로를 건드리기 전에 노트북이 어느 종단점에 도달해야 하는지 정하세요.

1단계: 노트북이 어느 종단점에 도달해야 하는지 정하세요

두 설계 모두 타당하며 서로 다른 질문에 답하므로, 직접 접근은 데이터베이스가 터널이 닿는 전용 주소에서 수신 대기하고 노트북이 그 주소에 연결하는 방식입니다. 전달 접근은 데이터베이스가 loopback에 남고 SSH 세션이 포트를 여러분의 머신까지 운반하는 방식입니다. 하나를 의도적으로 고르세요. 둘을 섞으면 잘못된 이유로 동작하는 연결이 됩니다.

직접 접근이라면 데이터베이스 호스트 자체의 전용 이름이나 주소와 포트를 그것을 운영하는 사람에게 받으세요. VPN 게이트웨이 주소는 같은 머신이 아닌 한 데이터베이스 주소가 아닙니다. 그런 다음 인터페이스로 가는 경로가 그 위에 리스너를 만들지 않으므로 리스너가 실제로 그 인터페이스에 바인딩되었는지 확인하세요.

2단계: 리스너가 로컬에 남을 때만 포트를 전달하세요

데이터베이스가 loopback에만 남아야 한다면 SSH로 전달하고 로컬 끝도 loopback에 바인딩하되, 왼쪽의 바인드 주소는 여러분의 노트북에 속하고 오른쪽의 대상은 SSH 서버 쪽에서 해석됩니다. OpenSSH 참조에 설명된 대로입니다. 이 두 역할을 뒤바꾸는 것이 전달이 동작하는 것처럼 보이지만 아무것에도 연결되지 않는 흔한 이유입니다.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:13306:127.0.0.1:3306 [email protected]
ss -ltn 'sport = :13306'

SSH가 데이터베이스 호스트가 아니라 점프 호스트에 도착하면 오른쪽 loopback은 점프 호스트를 가리키고, 대상은 그 호스트가 닿을 수 있는 주소로 바꿔야 합니다. ExitOnForwardFailure는 전달 설정 실패를 잡아내지만 대상에 대한 이후 연결이 성공한다는 것을 증명하지는 않습니다. 호스트 키 검사를 켜 두고, 모든 인터페이스에 바인딩해 전달 포트를 LAN 전체에 노출하지 마세요.

데이터베이스가 loopback에만 남아야 하는데 SSH를 쓸 수 없다면 멈추세요. 그때 직접 접근은 잘못된 설계이며 억지로 밀어붙일 설정이 아닙니다.

3단계: 클라이언트를 TCP로 강제하세요

Unix에서 localhost를 받은 MySQL 클라이언트는 기본적으로 Unix 소켓을 고르므로, 포트만 바꾸면 전달과 아무 관련이 없는 소켓을 찾게 될 수 있습니다. 명시적 TCP 프로토콜과 loopback 주소를 사용해 클라이언트가 전달 포트로 연결을 열게 하세요.

mysql --protocol=TCP --host=127.0.0.1 --port=13306 --user=DB_USER --password

값이 없는 비밀번호 옵션은 비밀을 명령줄에 두는 대신 묻는 것인데, 이것이 지킬 가치가 있는 습관입니다. 다른 도구에도 같은 구분을 위한 자체 스위치가 있고, 일부 드라이버는 localhost를 특별히 취급합니다. 플래그가 전달되었다고 가정하지 말고 클라이언트가 무엇을 하는지 확인하세요. 데이터베이스 계정에는 서버가 보는 출처와 일치하는 권한도 필요하며, 그것은 노트북이 아니라 전달 호스트입니다.

도구를 TCP로 강제할 수 없다면 멈추세요. 그때는 다른 클라이언트를 쓰거나 전용 리스너로 직접 접근하세요.

4단계: 실제로 어느 종단점에 도달했는지 증명하세요

서버에 그 연결이 무엇이라고 생각하는지 물어보세요. 호스트 이름, 포트, 소켓 변수는 TCP로 왔는지와 어느 리스너가 응답했는지를 알려 주고, 연결 목록은 서버가 기록한 출처 주소를 보여 줍니다. 그 증거가 또 한 번의 경로 변경보다 유용합니다.

mysql --protocol=TCP -h 127.0.0.1 -P 13306 -u DB_USER -p -e "SELECT @@hostname, @@port, @@socket"

어느 종단점을 시도했는지 기록하세요: 로컬 Unix 소켓, 전달 포트, 또는 전용 리스너입니다. 이 세 실패는 고치는 방법이 다르고, 클라이언트가 아직 잘못된 localhost와 대화하는 동안 VPN 경로를 바꾸는 것은 헛수고입니다. 메모에서 SSH 인증과 데이터베이스 인증도 분리해 두세요, 데스크톱 클라이언트에서는 한쪽의 실패가 다른 쪽의 실패처럼 보이기 때문입니다. 그런 다음 끝나면 전달을 제거하세요.

체크리스트는 종단점, 클라이언트 프로토콜, 서버가 본 출처 주소, 그리고 그것을 허용한 권한을 말할 수 있을 때 끝납니다. 네 가지 사실이며, 다음 연결 문제는 오후가 아니라 몇 분이면 풀립니다.