Foghorn: 간단명료한 비 DNS 솔루션

Source: Dev.to

What ?

Foghorn은 주기적으로 UDP 패킷을 목적지/서브넷에 전송하고, 동일한 UDP 패킷을 보내는 다른 유틸리티들을 수신하는 송신기/수신기 쌍이다.
IT 지식이 없는 사람이 IT와 관련된 일을 할 수 있게 만든 장난감 프로젝트다.

Why ?

내 임의의 박스들이 서로 자신이 누구이며 어디에 있는지 알려줘야 했기 때문이다.
나는 소프트웨어 테스트 팀의 기술 운영을 담당했었는데, 흔히 N개의 맞춤형 장치(빌드 타워, 라즈베리 파이, SoC POC 등)를 관리해야 하는 상황이 많았다.

IT 부서는 이 장치들을 추적하고 싶어 하지 않으며(그리고 추적할 필요도 없어야 하고), 가끔 DNS 용도로 장치 이름을 인정해줄 수도 있지만 보통은 그렇지 않다.

When ?

네트워크 인프라를 제어할 수 없고 여전히 여러 대의 장치를 모아야 할 때, Foghorn은 “가난한 사람을 위한 비‑DNS 도구”다.
완전한 섀도우‑IT 솔루션이다.

How ?

가장 간단히 말해, Foghorn은 송신기와 수신기로 구성된다. 송신기는 주기적으로 UDP 패킷을 보낼 IP 혹은 서브넷을 지정받으며, 패킷 안에는 자신의 이름과 선택적인 별명을 담은 JSON 페이로드가 들어간다. 수신기는 같은 포트에서 UDP 패킷을 듣고, 패킷이 온 IP와 JSON에 담긴 이름을 매핑한다.

즉, 송신기가 NAT 뒤에 있을 경우 수신기에는 “외부” IP만 보인다는 점을 유의한다.

Where ?

https://github.com/taikedz/foghorn

현재 Linux에서만 동작하고 지원한다. 설치 프로그램은 systemd 서비스를 지원하므로, 부팅 시 자동으로 Foghorn을 시작하도록 할 수 있다.

Python 3만 설치되어 있다면 Windows에서도 실행할 수 있지만 서비스 코드는 제공되지 않는다. 창을 열어 두고 실행할 수는 있지만, Windows는 사용자의 동의 없이 재부팅될 수 있어 여전히 문제가 된다.

Other thoughts

DNS propagation on corporate LANs

이것이 “형편없는 재발명된 바퀴”라고 생각할 수도 있겠지만, 나는 이름이 IT DNS에 전파되지 않는 상황에서 실제로 효과적으로 사용해 본 경험이 있다. 이는 합리적인 접근이다—네트워크에 임의의 박스가 실제 기업 서버와 충돌해 MITM(중간자 공격) 혼란을 일으키는 것을 원치 않기 때문이다!

예를 들어 https://payroll.lan이라는 급여 서비스가 있다고 하자. 임의의 머신이 스스로 호스트명을 선언하도록 허용하면, 누군가 실수로(…) 자신의 머신을 payroll이라고 명명해 IP 충돌을 일으킬 위험이 있다. 그 결과 실제 급여 서버에 접속하려는 사용자는 서버에 도달하지 못한다.

물론 올바른 해결책은 임의의 머신을 위한 테스트 네트워크를 구축하고, 별도의 DHCP + DNS 영역을 제공하는 것이다. IT 부서에 있다면 당연히 그렇게 해야 한다. IT 부서가 아니고 이 글을 읽게 되었다면, 그것은 더 이상 논의할 문제가 아니다. 현실은 타협의 연속이며, 개발자는 종종 IT가 인프라를 제공하기 전에 빠른 해결책이 필요하고, 경영진은 즉각적인 조치를 요구한다… 그래서 우리는 여기까지 왔다. IT가 아닌 사람이 IT와 같은 솔루션을 필요로 하는 상황이다.

NAT and firewall traversal

Windows 클라이언트 머신에서 Foghorn 네트워크로 ping을 보내고 응답을 받으려 했지만, 쉽지 않았다. 박스들에 ping을 보낼 수는 있어도 응답이 돌아오는 과정에서 보통 사라진다. 이것이 방화벽 문제인지 궁금하다—소켓이 패킷을 보낼 때 임의의 포트에서 전송되므로 서버 측은 그 포트에 응답할 수 있다.

이는 타당한 논리다—두 프로세스가 각각 server.lan:80에 요청을 보낼 때, 각 프로세스는 자신의 요청에 해당하는 데이터를 받아야 한다. 만약 두 프로세스가 같은 원본 포트(예: 80)를 재사용한다면 데이터 충돌이 발생한다.

TCP에서는 방화벽이 연결을 식별하고 흐름을 제어한다: 연결이 확립되면 해당 연결은 자유롭게 패킷을 주고받을 수 있다.

하지만 UDP는 연결이 없기 때문에 들어오는 패킷은 어떤 요청에 대한 응답인지에 대한 메타데이터가 전혀 없다. 네트워크는 최근에 해당 서버로 나갔던 포트를 기억하고, 그 포트로 돌아오는 응답을 허용해야 한다—하지만 이는 NAT와 방화벽의 책임이다. Linux에서는 기대대로 동작했지만, Windows에서는 패킷 응답이 전혀 돌아오지 않는 문제가 지속적으로 발생했다.