아웃바운드는
연결을 시작한 방향입니다.

01

연결 방향은 처음 한 번만 정해집니다.

누가 먼저 말을 걸었는지는 연결을 세울 때의 문제이고, 일단 세워진 뒤에는 양쪽이 대등하게 주고받습니다. 화면에서 서버가 먼저 보낸 메시지와 장비가 먼저 보낸 메시지를 각각 세어 표시하는 것이 이 점을 보여주기 위한 것입니다. 연결을 건 쪽만 말할 수 있다면 이 구조 자체가 성립하지 않습니다.

02

나가는 연결은 대개 막혀 있지 않습니다.

회사나 가정의 방화벽은 보통 밖에서 안으로 들어오는 연결을 막고 안에서 밖으로 나가는 연결은 허용합니다. 그래서 안쪽에서 먼저 걸면 아무 설정 없이도 통로가 생깁니다. 밖에서 안으로 들어오려면 문을 따로 열어야 하는데, 그 문은 전 세계에 열리는 것이라 위험이 함께 늘어납니다.

03

포트를 열지 않는다는 것이 핵심입니다.

성공하는 시나리오 내내 안쪽 포트 열림 표시는 꺼진 채로 있습니다. 접속 가능한 지점을 새로 만들지 않았다는 뜻이고, 밖에서 그 장비를 직접 찾아갈 방법은 여전히 없습니다. 관리 통로를 만들면서도 공격받을 수 있는 면을 늘리지 않는다는 것이 이 방식이 널리 쓰이는 이유입니다.

04

연결한 뒤에 누구인지 밝힙니다.

연결이 세워진 직후에 장비가 자기 식별자를 보내는 단계가 따로 있습니다. 서버 입장에서는 여러 장비가 각자 연결을 걸어 오므로, 어느 연결이 어느 장비인지 알아야 명령을 제대로 보낼 수 있습니다. 연결 자체가 신원을 알려주지 않는다는 점이 안쪽에서 거는 방식의 대가입니다.

05

실패도 상태로 표현했습니다.

막히는 시나리오에서 화면은 오류 문구만 띄우지 않고 요청이 어디까지 갔다가 막혔는지를 위치로 보여줍니다. 그리고 그 시점에 안쪽 장비는 아무것도 모르는 상태로 남습니다. 밖에서 접속이 안 될 때 안쪽 로그에 흔적이 없는 이유가 이것이고, 로그가 비어 있다는 사실 자체가 단서가 됩니다.

06

보호 계층은 켜진 것으로 둡니다.

연결을 세우는 단계에서 암호화 표시가 함께 켜집니다. 관리용 통로를 평문으로 여는 경우는 없어야 하므로 기본값을 그렇게 잡았습니다. 다만 이 화면은 그 절차 자체를 보여주지는 않고 상태 표시로만 다루며, 그 과정은 다른 편에서 단계별로 확인할 수 있습니다.

07

예시 주소는 문서용을 씁니다.

화면에 나오는 서버 주소와 장비 이름은 예제용으로 비워 둔 도메인과 임의의 식별자입니다. 실제로 존재하는 주소를 적으면 그쪽으로 접속을 시도하는 일이 생길 수 있어서, 문서에서 쓰라고 지정해 둔 이름을 골랐습니다.

08

끊기면 안쪽에서 다시 걸어야 합니다.

이 구조에서 연결을 세울 수 있는 것은 언제나 안쪽 장비뿐입니다. 그래서 연결이 끊기면 서버는 기다리는 것 말고 할 수 있는 일이 없고, 장비 쪽이 다시 걸어 줘야 통로가 복구됩니다. 장비가 멈췄거나 재연결 로직이 없으면 밖에서는 손쓸 방법이 전혀 없다는 뜻이라, 재연결을 얼마나 견고하게 만들었는지가 이 방식의 신뢰성을 결정합니다.

09

서버가 연결을 들고 있어야 합니다.

장비가 걸어 온 연결은 특정 서버 한 대와 맺어집니다. 그래서 서버를 여러 대 두면 어느 서버가 어느 장비를 들고 있는지 찾는 문제가 새로 생기고, 명령을 보내려는 쪽이 그 정보를 알아야 합니다. 이 화면은 서버가 한 대인 상황을 전제로 하며, 여러 대일 때의 연결 위치 문제는 서버 확장을 다루는 편과 같은 종류의 문제입니다.