NetBird의 두 LAN: 어떤 피어가 라우팅하고 누가 통신할 수 있는가

서쪽 LAN의 워크스테이션이 브라우저를 열고 동쪽 LAN에 있는 애플리케이션의 주소를 입력한 뒤 시간 초과가 될 때까지 기다립니다. NetBird의 모든 화면은 피어가 연결되었다고 말하지만, 사실이면서 핵심이 아니며, 하나의 오버레이 네트워크에 있는 것과 두 로컬 서브넷을 하나의 네트워크에 넣는 것은 다릅니다. 아래 여정은 그 워크스테이션에서 시작해 설계가 일부러 거부하는 요청으로 끝납니다. 각 지점은 추측이 아니라 장치에서 읽어 낼 수 있는 것이며, 빠진 조각은 오버레이가 아니라 경로나 정책일 것으로 보십시오.

먼저 워크스테이션에서 실패를 읽으십시오

관리 콘솔을 열기 전에 워크스테이션이 실제로 무엇을 보내는지 확인하십시오. 패킷이 사이트 게이트웨이로 가는지, 로컬 인터페이스로 가는지, 어디로도 가지 않는지는 그 머신의 라우팅 테이블이 정하며, 이 결정은 어떤 오버레이 도구 없이도 보입니다. 먼 프리픽스에 대한 경로가 없는 머신은 피어 목록이 아무리 건강해 보여도 실패합니다. 오버레이 범위와 사이트 자체의 프리픽스는 서로 다른 주소 공간이며, 등록은 그중 하나만 구성했습니다.

브라우저가 둘 다 같은 시간 초과로 보고하므로, 다음으로 이름 해석과 도달 가능성을 나누십시오. NetBird 클라이언트가 도는 머신에서 주소로 요청을 반복하고, 그다음 클라이언트가 없는 일반 워크스테이션에서 반복하십시오. 등록된 머신은 성공하고 일반 머신이 실패하면 격차는 로컬 라우팅에 있고, 둘 다 실패하면 경로를 바꾸기 전에 계속 읽으십시오.

사이트마다 라우팅 피어 하나를 고르십시오

라우팅 피어는 오버레이에서 자기 LAN을 대표하는 호스트이므로, 누군가의 책상 워크스테이션이 아니라 서브넷에 대한 안정적인 도달성을 가진 Linux 머신을 고르십시오. 일반 절차로 등록하고 역할 이름을 붙인 그룹에 넣으십시오. 네트워크 리소스와 정책이 모두 그 그룹을 참조합니다. 사이트마다 대표 하나면 읽기 쉬운 상태를 유지하지만, 같은 프리픽스를 광고하는 자원봉사자 무리는 이후의 모든 질문을 디버깅 세션으로 바꾸며, 로컬 세그먼트에서 피어의 주소는 그 주소가 모든 일반 장치에 알려 줄 다음 홉이 되므로 오버레이 신원만큼 중요합니다.

콘솔을 만지기 전에, 이름과 프리픽스가 바로 이런 설계가 어긋나는 지점이므로 계획을 적으십시오. 프리픽스, 게이트웨이, 피어 주소, 그룹을 사이트마다 적고, 서쪽은 10.52.0.0/24이고 10.52.0.5가 맡으며, 동쪽은 10.63.0.0/24이고 10.63.0.5가 맡고, 두 그룹은 west-routers와 east-routers이며, 어떤 프리픽스도 서로, 오버레이 범위, 또는 다른 라우팅 대상과 겹쳐서는 안 됩니다.

리소스를 만들고 매스커레이딩은 켜 둡니다

배포된 대시보드에서 사이트마다 네트워크 리소스 하나를 만들고 그 사이트의 라우팅 피어 그룹을 연결하십시오. 리소스는 프리픽스이고 그룹은 그에 응답하는 호스트이며, 무엇이든 광고되기 전에 둘 다 있어야 합니다. 배포된 자체 호스팅 버전에는 이름이 비슷한 경로 객체가 있는 옛 인터페이스와 달리 네트워크 워크플로가 있는지 확인하십시오.

매스커레이딩은 켜 둡니다. NetBird의 사이트 간 가이드가 이 구성에서 요구하며, 원래 주소를 모두 보이게 하려고 끄는 것은 오버레이의 출처 검사와 정책이 보는 것을 바꾸므로 홉이 하나 적은 같은 설계가 아닙니다. 결과는 분명히 말할 만합니다. 수신 서비스는 출처로 라우팅 피어를 기록하며 개별 워크스테이션을 기록하지 않으므로, 그 서비스의 허용 목록이나 감사가 워크스테이션 주소를 기대한다면 기대를 바꾸거나 변환 전에 사이트 경계에서 신원을 강제해야 합니다.

권한은 시작하는 쪽에 주고 프리픽스에 주지 않습니다

경로는 주소를 도달 가능하게 하고 정책은 누가 그것을 쓸 수 있는지 정합니다. 둘은 서로 다른 소유자의 별개 객체입니다. 정책은 워크로드에서 거꾸로 써서 어느 그룹이 시작하고, 어느 리소스를 대상으로 하며, 어느 TCP 서비스가 필요한지를 정하고, 두 프리픽스를 등록된 모든 피어에 광고하는 네트워크는 도달 가능성만 만들고 아무것도 정하지 않았습니다.

다음으로 좁은 새 규칙은 그 위에 있는 넓은 옛 규칙을 취소하지 않으므로, 이미 무엇이 허용되는지 읽고, 동쪽도 서쪽으로 연결을 시작해야 할 때는 그 방향을 별도 정책으로 쓰십시오. 서쪽이 연 세션의 반환 트래픽은 동쪽으로 새 세션을 허용하는 것과 다른 질문입니다. 서쪽의 일부 워크스테이션만 동쪽 애플리케이션에 도달해야 한다면 변환 전에 사이트 경계에서 선별하고 애플리케이션 자체의 인증은 그대로 두십시오. 라우팅 피어는 LAN 트래픽을 사이트 전체로 나르며 사용자별 오버레이 신원으로 나르지 않으므로, 사용자별 집계는 다른 곳에서 가져와야 합니다.

각 게이트웨이에 다음 홉을 가르친 뒤 거부를 시험하십시오

일반 장치는 오버레이를 결코 보지 못하므로 자기 게이트웨이에 먼 프리픽스를 라우팅 피어의 LAN 주소로 보내는 정적 경로가 필요합니다. 사람들이 이 단계를 건너뛰는 것은 NetBird 안에서 보이는 것은 이미 동작하고 일반 워크스테이션만 계속 시간 초과되기 때문입니다. 게이트웨이는 기본 경로를 그대로 유지하며, 이 프리픽스는 추가이지 대체가 아닙니다.

두 경로 설명은 각 사이트의 게이트웨이 구성에 들어가며 호스트의 덮어쓰기가 아니고, 둘 다 평범한 정적 경로이며 기본 경로는 건드리지 않습니다.

west gateway: 10.63.0.0/24 via 10.52.0.5
east gateway: 10.52.0.0/24 via 10.63.0.5

프로젝트가 실제로 필요로 하는 애플리케이션으로 일반 워크스테이션에서 시험하고, 송신 측에서 선택된 다음 홉, 일치한 정책, 서비스가 기록한 출처 주소를 기록하십시오. 거부도 시험해야 하는데, 아무것도 거부한 적 없는 설계에는 알 수 없는 가장자리가 있고 거부만이 라우팅이 아니라 정책이 일하고 있다는 증거이기 때문입니다. 동쪽도 시작해야 할 때 두 번째 방향이 따라온다고 가정하지 말고 그쪽에서 새 연결을 시작하십시오. 호스트 하나가 사이트의 의존성이 되었으므로 라우팅 피어의 재시작, 업그레이드, 교체도 계획하십시오.

사설 이름에는 자체 리졸버 설계가 필요한데, 도달 가능성은 DNS 레코드를 만들지 않으며 이름이 깨진 채 동작하는 IP 경로는 깨진 경로와 똑같이 읽히기 때문입니다. 라우팅 피어가 클라우드 네트워크 안에서 돈다면 공급자의 전달 및 방화벽 규칙도 검토하십시오. 등록은 그것들을 덮어쓰지 않으므로, 다음에 이것을 디버깅할 사람이 토폴로지 설명이 아니라 일치한 정책과 기록된 출처 주소를 원할 것이기에 시험의 관찰 결과는 계획 옆에 두십시오.