ZeroTier 구성원을 통해 사무실 LAN의 프린터에 도달하는 일은 규칙 하나처럼 들리지만, 실제로는 서로 다른 세 곳에서 내리는 세 가지 결정입니다. 오버레이는 LAN이 어디인지 알아야 하고, Linux 호스트는 패킷을 전달할 의사가 있어야 하며, LAN은 응답을 어떻게 되돌려 보낼지 알아야 합니다. 게이트웨이에서 포트를 여는 인바운드 규칙은 이 중 어느 것도 건드리지 않습니다. 올바른 호스트에 쓴 잘못된 도구입니다.

세 가지 일, 세 명의 주인

관리 경로는 ZeroTier 네트워크 구성에 속합니다. 특정 구성원 주소를 통해 어떤 접두사에 도달할 수 있음을 구성원에게 알립니다.

전달은 Linux 커널과 그 방화벽 정책을 가진 쪽에 속합니다. 오버레이로 들어온 패킷이 물리 인터페이스로 다시 나갈지를 결정합니다. 전달하지 않는 호스트는 패킷을 받아들인 뒤 조용히 버립니다. 보낸 쪽은 시간 초과를 보고 서비스 로그에는 아무것도 나타나지 않습니다.

반환 경로는 LAN에 속합니다. 그 호스트들과 라우터는 오버레이 접두사가 게이트웨이의 LAN 주소를 통해 도달 가능하다는 것을 알아야 하고, 그렇지 않다면 이 질문이 아예 생기지 않도록 무언가가 트래픽을 변환해야 합니다.

이들 각각은 나머지가 실패하는 동안에도 올바를 수 있고, 그래서 게이트웨이에 핑만 하는 시험은 그 뒤의 서비스에 대해 아무것도 증명하지 못합니다.

관리 경로를 구성원 쪽으로 지정하십시오

의도한 LAN 접두사에 대한 경로를 게이트웨이의 LAN 주소가 아니라 오버레이 주소를 통해 추가하십시오. 오버레이 주소는 다른 구성원이 도달할 수 있는 주소이고, LAN 주소는 케이블 위에서만 의미가 있습니다.

설계가 동작하려면 구성원이 관리 경로를 받아들여야 하고, 각자의 로컬 네트워크가 이미 광고하는 접두사를 쓰고 있어서는 안 됩니다. 집에서 192.168.60.0/24에 있는 원격 노트북도 오버레이를 통해 192.168.60.0/24를 라우팅할 수 없습니다.

광고하는 접두사는 작업이 허용하는 만큼 좁게 유지하십시오. 선호도에 영향을 주려고 더 큰 집합을 광고하면 소유하지 않은 주소 공간까지 주장하게 될 수 있고, 그 결과 생기는 충돌은 두 네트워크에 모두 연결된 장치에 나타납니다. 어떤 구성원이 아무 데도 이어지지 않는 경로를 선호하게 만들 수도 있습니다. 경로를 정직하게 유지하고 나머지는 정책에 맡기십시오.

접두사와 구성원 주소를 방화벽 규칙과 같은 메모에 적으십시오. 가장 흔한 고장은 잘못된 구성원을 가리키는 경로입니다.

커널에서 전달을 켜십시오

무엇이든 바꾸기 전에 현재 전달 값을 읽고, 그다음 재부팅 때 사라지는 일회성 명령이 아니라 시스템이 이미 사용하는 방식으로 설정을 영구화하십시오.

정책을 UFW가 가진다면 그 경로 규칙은 출발지, 목적지, 인터페이스 쌍에 대한 전달을 표현합니다. 이것은 게이트웨이 자체에서 서비스를 여는 인바운드 규칙과 별개입니다:

sysctl net.ipv4.ip_forward
sudo ufw route allow in on zt3f2a1c9d out on eth0 proto tcp to 192.168.60.20 port 443
sudo ufw status verbose

인터페이스 이름은 그 호스트의 실제 오버레이 장치이며 ip link로 읽을 수 있습니다. 모든 설치에서 고정된 문자열이 아닙니다. 호스트가 기본적으로 전달하고 UFW가 경로에 없다면 경로 규칙은 무시되고 커널 설정이 중요해집니다.

응답이 어떻게 돌아오는지 고르십시오

출발지를 보존하면 LAN 서비스는 실제 오버레이 주소를 보고 그 주소로 응답합니다. 그러려면 LAN 호스트나 그 라우터에 오버레이 접두사를 게이트웨이로 향하게 하는 경로가 있어야 하고, 그것은 Linux 상자 밖의 변경입니다.

그 경로를 추가할 수 없을 때, 범위를 좁힌 출발지 변환은 요청이 LAN의 게이트웨이에서 온 것처럼 보이게 합니다. 그러면 응답은 로컬로 돌아오고 LAN 라우팅을 바꿀 필요가 없지만, 서비스 로그에서 원래 출발지를 잃습니다.

변환 범위를 오버레이 출발지와 특정 LAN 목적지로 한정하십시오. LAN 인터페이스에서 나가는 모든 것을 변환하는 것은 나중에 규칙을 읽는 사람을 놀라게 하는 넓은 버전이며, 차단됐어야 할 트래픽도 감춥니다.

어느 선택도 LAN에서 임의의 오버레이 구성원으로 요청되지 않은 접근을 허용하지 않습니다. 그것이 필요하다면 자체 검토가 따르는 별도 규칙입니다.

실제 구성원에서 시험하십시오

게이트웨이가 아니라 다른 구성원에서 접속해 허용된 서비스 하나를 요청하십시오. 그다음 닫혀 있어야 할 서비스를 시도하고, 다시 연결한 뒤와 게이트웨이를 재부팅한 뒤에 두 시험을 반복하십시오.

ONLINE을 보고하는 구성원이나 게이트웨이 오버레이 주소로의 성공한 핑은 경로, 전달 규칙, 반환 경로를 검증하지 않습니다:

zerotier-cli listnetworks
ip -4 route get 192.168.60.20
sudo ufw status numbered

두 번째 명령은 패킷이 LAN 호스트로 갈 때 어느 인터페이스를 쓸지 보여 주고, 세 번째는 경로 규칙이 의도한 형태로 있는지 보여 줍니다. 둘 다 맞아 보이는데도 서비스가 계속 시간 초과라면 남은 용의자는 반환 경로입니다.

관련 글