경로 하나에 근거 넷

한 연동이 어떤 경로로 나가는지 확정해야 했다. 후보가 셋이었다.

Open Table of contents

상황 — 후보가 셋이었다

가능한 경로는 이랬다.

직접 호출
프록시 경유
터널 경유

직접 호출 과 프록시 경유 와 터널 경유 가 각각 다른 설정을 읽고 다른 장비를 거친다.

하나로 확정해야 다음 작업을 정할 수 있었고 하나만 확인하고 답했다가 틀리면 그 뒤의 판단이 전부 어긋난다.

클라이언트 코드를 열었다.

proxy = ssh_tunnel.get_proxy_url("<대상>") or settings.<대상>_proxy

ssh_tunnel 을 우선하고 없으면 _proxy 설정을 쓰는 우선순위 분기였다.

여기까지로 아는 것은 코드가 무엇을 하려고 하는지뿐이고 실제로 어느 쪽이 쓰이는지는 설정에 달렸다.

SSH_TUNNELS=[{ name: <대상>, host: <주소>, local_port: 3128 }]
<대상>_PROXY=''

SSH_TUNNELS 에는 값이 있고 _PROXY 는 비어 있다.

get_proxy_url 이 값을 내고 뒤쪽은 애초에 빈 값이므로 프록시는 안 쓴다. 보통 빈 값은 설정 안 함으로 넘기는데 우선순위 분기에서는 그 자체가 명시적 표현이었다.

저장소에서 읽은 코드가 서버에서 도는 코드라는 보장은 없다.

컨테이너 안의 코드를 확인하니 같은 or 분기가 그대로 있었다. 배포가 밀렸거나 부분 실패했으면 둘이 달랐을 것이고 그러면 앞의 두 근거가 함께 무의미해진다.

마지막으로 그 연동이 도는 동안의 로그를 봤다.

asyncssh: Connected to SSH server at <주소>, port 22

asyncssh 가 실제로 연결돼 있다.

이 기록만이 그렇게 됐다는 근거이고 앞의 셋은 그렇게 될 것이라는 근거라 성격이 다르다.

확인한 넷을 나란히 놓았다.

① 코드      터널 우선 분기
② 환경      터널 설정 있음, 프록시 비어 있음
③ 배포본    같은 코드
④ 로그      터널 실제 활성

코드 와 환경 과 배포본 과 로그 가 다 같은 답을 가리키므로 확정했다.

확정하고 나서 실제 경로를 한 줄로 그려 봤다.

클라이언트 → 로컬 소켓 → 터널 → 중계 서버 → 상대

로컬 소켓 과 터널을 지나 중계 서버로 나가는 것이 이 연동의 실제 모양이었다.

넷이 다 필요했는지 따져 봤다.

① 코드만    배포본이 다를 수 있다
② 환경만    코드가 그걸 안 읽을 수도 있다
③ 배포본만  실제로 그 분기를 타는지 모른다
④ 로그만    다른 용도의 연결일 수도 있다

넷이 각각 서로 다른 반론을 막고 있었다.

근거를 하나씩 쌓을수록 남아 있는 반론이 하나씩 줄었다. 여러 근거를 모으는 것이 같은 말을 반복하는 것이 아니라 서로 다른 구멍을 메우는 일이었다.

경로를 확정했으니 애초에 왜 그렇게 했는지도 봤다.

# 상대가 출발지 IP 허용 목록을 강제하는데
# 전용 프록시 인스턴스가 없어 다른 서버의 고정 IP 를 빌려 쓴다

설정 주석에 적혀 있었고 다른 서버의 고정 IP 를 빌리는 구조였다.

상대가 허용하는 것은 나가는 주소이므로 그 주소를 고정해야 한다. 프록시를 따로 세우는 대신 이미 고정 주소가 있는 서버로 터널을 판 것이다.

이 구조에는 함께 딸려 오는 것이 있다.

중계 서버 다운  →  터널 끊김  →  연동 실패

그 중계 서버가 죽으면 터널이 끊겨 연동이 멈추는 단일 실패 지점이 생긴다.

프록시를 세우는 것보다 싸지만 그 서버에 대한 의존이 생겼다. 그것을 기록에 남겼는데 그 서버를 정리하려는 사람이 이 의존을 알아야 한다.