VPN으로 연결된 서버라면 DNS에 어떤 주소를 넣어야 할까?
호스팅 서버에는 세 개의 주소가 있고 서로 바꿔 쓸 수 없다. 각 서비스에 필요한 값을 고른 뒤, 기계 바깥에서 확인한다.
VPN이 설치된 호스팅 서버는 결국 세 개의 주소를 갖게 되며, 설정하려는 자리마다 그중 하나만 맞는다. 공급자 패널의 숫자를 DNS로, 리스너로, 또는 허용 목록으로 복사하는 것이 바로 동작하던 터널을 아무도 닿지 못하는 서비스로 바꾸는 길이다. 이 글은 각 주소가 밝힌 목적에 맞게 선택되도록 작업 순서를 정한다. 실제로 무엇을 공개했는지 확인하는 명령도 함께 적는다.
무엇이든 공개하기 전에 세 주소를 정리하라
기능으로 이름을 붙인다. underlay 주소는 기계가 인터넷을 거쳐 VPN 종단에 닿는 데 쓰는 주소이며, 대개 공급자의 NAT 뒤에 있는 사설 주소다. 터널 주소는 VPN 안쪽에 살고, 제품에 따라 서버나 클라이언트가 나눠 준다. 공인 출구는원격 사이트가 변환을 거친 뒤 기록하는 주소이며, 우리가 질의할 수 있는 어떤 인터페이스에도 있어야 할 필요는 없다.
공인 주소 하나만 보여 주는 패널은 나머지 두 역할에 대해 거의 말해 주지 않는다. underlay 도달성은 요건이지 구매가 아니다: 집 공유기 뒤의 노트북도 공인 IPv4 주소 없이 호스팅 VPN 종단에 닿을 수 있다. 할 수 없는 일은 아무도 전달하지 않는 주소로 풀리는 이름을 써서 들어오는 경로를 지어내는 것이다.
레이블이 아니라 서비스로 주소를 고른다
숫자를 고르기 전에 서버가 무엇을 해야 하는지 적는다. 나가는 API 호출은 상대가 허용 목록을 둘 때 안정적인 출구가 필요하다. 사설 접근에는 클라이언트가 경로를 둘 수 있는 터널 주소와 거기에 묶인 리스너가 필요하다. 공개 호스팅에는 공급자가 실제로 제공하는 들어오는 매핑이 필요하며, 출구 주소만으로는 그것을 주지 않는다.
한 기계가 세 목적을 모두 맡으면서도 세 가지 다른 주소를 쓸 수 있다. 깨지는 것은 하나의 값이 모두를 덮는다는 가정이다:
| Requirement | Value that belongs there | What you see when the roles are swapped |
|---|---|---|
| Outbound allowlisting | Public exit | Requests reach the service but are rejected |
| Private client access | Tunnel address | Client connects, nothing answers |
| Inbound web service | Provider mapping | Name resolves, connection times out |
사람들이 다투는 줄은 들어오는 줄이다. 출구 주소를 가리키는 레코드는 리스너도, 방화벽 구멍도, 포트 매핑도 만들지 않으며 기다린다고 달라지지 않는다. 공급자가 전용 주소를 들어오는 규칙과 함께 판다면 그 묶음이 산 능력이며, 주소만으로는 권리가 아니다.
어느 주소가 어느 것인지 보여 주는 명령
패널이 아니라 기계를 읽는다. 인터페이스 이름은 시스템마다 다르므로 레이블을 믿는 대신 주소를 장치에 맞춘다.
첫 줄은 모든 IPv4 주소와 그 장치를 나열하고, 둘째 줄은 알려진 외부 목적지에 커널이 어느 장치를 쓸지 묻는다:
ip -brief -4 addr show
ip -4 route get 198.51.100.10
curl -4 -s https://ifconfig.me
ss -lntp | grep -E ':(443|1194)'공인 트래픽의 경로 조회가 터널 장치로 답하면 전체 터널이 작동 중이다. 리스너 확인도 그만큼 중요하다, 127.0.0.1에만 묶인 프로세스는 어떤 이름을 공개하든 터널 주소에서 응답하지 않기 때문이다.
공개한 뒤 바깥에서 확인한다
서비스에 필요한 값만 공개하고 그 이상은 두지 않는다: 호스팅에는 A 또는 AAAA 레코드, 나가는 호출에는 허용 목록 항목, 사설 접근에는 클라이언트 프로필이다. 그다음 중요한 위치에서 시험하는데, 그 위치는 방금 고친 기계가 결코 아니다.
두 가지 확인으로 대부분을 덮고, 둘 다 스크립트에 남길 만큼 싸다:
dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/health레코드가 있음을 증명하는 DNS 응답은 요청이 도착한다는 증거가 아니며, 성공한 요청 하나는 경로 하나가 네트워크 하나에서 통한다는 것만 증명한다. 허용 목록이 걸리면 모바일 연결에서 확인을 반복한다: 관찰한 출구가 주소 계열과 지난 경로에 달려 있을 수 있기 때문이다. 어느 계열을 확인했는지 적어 두되, 동작하는 IPv4 경로는 IPv6에 대해 아무것도 말해 주지 않는다.
서비스가 들어오는 쪽이라면 출구 주소로는 부족하다
들어오는 접근에는 네 가지가 맞아야 한다: 클라이언트가 닿을 이름이나 주소, 패킷을 기계까지 나르는 경로, 그것을 받아들이는 리스너, 그리고 버리지 않는 정책이다. VPN은 둘째 요소를 바꾸고 때로는 첫째도 바꾸지만, 셋째와 넷째에는 아무것도 하지 않는다. 터널이 전달 경로라면 클라이언트는 출구가 아니라 터널 주소에 접속한다.
서비스마다 어느 주소에 의존하는지 적어 두고, 공급자가 경로 모델을 바꿀 때마다 그 기록을 다시 본다. 사설로 응답하고 공개로 실패하는 서버는 대개 고장 난 것이 아니다: 잘못된 신원으로 응답하는 것이며, 고치는 일은 방화벽 변경이 아니라 매핑 결정이다.