설정은 같고 노드 조합만 다르다

외부로 나가는 우회 서버가 포트 셋으로 열려 있었다. 각 포트의 설정을 비교하니 완전히 같았다.

Open Table of contents

설정이 같은 세 포트

설정이 같은데 포트를 셋으로 나눈 것은 이유가 있을 수밖에 없다. 설정 파일만 보면 그 이유가 안 보인다.

같은 것이 셋 있는 구성은 대개 설정이 아니라 그 앞이나 뒤가 다르다. 그래서 포트 뒤에 무엇이 붙어 있는지를 봤다.

포트별로 연결된 서버 목록을 보니 조합이 각각 달랐다. 하나는 두 노드만 붙어 있고 다른 하나는 셋이고 나머지는 넷이었다.

각 노드는 고정 외부 주소를 하나씩 가지므로 나가는 요청이 그 주소로 보인다. 설정은 같고 나가는 주소의 집합만 다른 구성이었다.

이유는 상대 쪽에 있었다. 거래처는 허용 주소 목록을 등록받는데 등록 개수에 제한이 있는 곳이 있었다.

넷을 다 등록할 수 있는 곳에는 넓은 조합을 쓰고 둘까지만 되는 곳에는 좁은 조합을 쓴다. 외부의 제약이 우리 쪽 구성을 정한 셈이다.

거래처마다 다른 노드 집합을 쓰게 하는 방법은 요청마다 라우팅하는 것과 포트로 나누는 것 둘이었다. 뒤쪽을 택하면 우회 서버는 아무것도 몰라도 되고 어느 포트로 보내느냐가 곧 어느 노드로 나가느냐가 된다.

대신 호출하는 쪽이 거래처와 포트의 대응을 알아야 하고 그 대응표를 어딘가에서 관리해야 한다. 새 연동을 붙일 때는 등록 가능 개수 확인이 가장 먼저인데 그것을 안 하고 넓은 포트를 쓰면 등록 안 된 노드로 나갈 때만 거부된다.

그 거부는 어느 노드로 나가느냐가 매번 달라서 간헐적으로 나타난다. 간헐적인 인증 실패는 이 구성을 의심할 신호가 된다.

주소를 바꿀 때도 제약이 있는데 무중단으로 하려면 새 주소와 옛 주소를 둘 다 등록해 두고 전환한 뒤에 옛 것을 빼야 한다. 등록 슬롯이 꽉 찬 거래처는 그것이 불가능하므로 여유가 있는 곳과 없는 곳을 미리 갈라야 전환 계획이 선다.