지점과 랩을 잇는 라우티드 VPN인가 브리지드 LAN인가

지점이 집 랩에 도달하는 방법은 두 가지이며 그 차이는 설정이 아닙니다. 서로 다른 프리픽스 사이를 라우팅하면 각 사이트가 자체 브로드캐스트 도메인을 유지하고, 두 LAN을 하나로 브리지하면 브로드캐스트와 검색 트래픽이 모두가 같은 방에 있는 것처럼 동작합니다. 라우팅은 실제 네트워크와의 접촉을 견디는 설계입니다. 브리지는 첫 주를 쉽게 만들고 첫 장애를 흥미롭게 만드는 설계입니다. 아래 비교는 각각이 무엇을 주고 무엇을 치르는지, 그리고 라우티드 버전을 어떻게 검증 가능하게 만들지에 관한 것입니다.

연결의 두 가지 방식, 하나의 분명한 절충

라우티드 링크는 집 랩을 자체 주소 체계를 가진 원격 네트워크로 취급합니다. 지점은 랩의 프리픽스를 요청하고, 터널이 그 패킷을 나르며, 랩의 게이트웨이가 자기 서브넷에서 응답합니다. 지점의 ARP 테이블은 아무것도 바뀌지 않고, 랩의 DHCP 범위도 지점에 닿지 않습니다.

브리지드 링크는 하나의 레이어 2 도메인을 두 사이트로 넓힙니다. 검색 프로토콜이 동작하고 장치가 자동으로 나타나며, 모든 브로드캐스트와 ARP 요청과 멀티캐스트 패킷이 이제 터널을 건널 후보가 되며, 즉 로컬 세그먼트를 위해 만들어진 프로토콜이 나르는 대량의 트래픽을 MTU가 다르고 왕복 시간이 변하는 WAN에 싣는 것입니다.

라우팅이 주는 것

첫 번째 이점은 피해 범위로, 루프, 원치 않는 DHCP 서버, 브로드캐스트 폭주는 그것을 만든 사이트 안에 머뭅니다, 라우터는 브로드캐스트를 전달하지 않기 때문입니다. 두 번째는 주소 체계의 명확성입니다. 지점 프리픽스와 랩 프리픽스가 다르므로 패킷의 목적지가 어느 사이트가 응답해야 하는지 알려주고, 방화벽 규칙은 «어디서나 어디로나» 대신 «지점에서 랩 서브넷으로»라고 쓸 수 있습니다.

세 번째는 터널이 실제로 나르는 것과 일치한다는 점입니다. IPsec 정책은 프리픽스 쌍이고, 양쪽의 전달 경로는 게이트웨이에서 전달이 켜진 평범한 IP 라우팅입니다:

sysctl -w net.ipv4.ip_forward=1
ip route add 10.20.0.0/24 via 192.168.50.1
ip route get 10.20.0.40

포기하는 것은 브로드캐스트를 통한 검색입니다. 이는 실제 손실이며 모든 것을 브리지해 우회하는 대신 의도적으로 대체해야 합니다.

브리지의 비용

브리지는 레이어 2 프레임을 터널로 나르는 것이며, 이는 단순한 정책 기반 터널 대신 IPsec 위의 GRE나 VXLAN 같은 캡슐화를 뜻합니다. 그것이 존재하면 두 사이트는 하나의 장애 도메인을 공유합니다. 스패닝 트리는 터널을 링크로 보고, 브로드캐스트 트래픽은 터널 대역폭을 먹으며, 저지연 세그먼트를 전제하는 장치는 어느 쪽 끝에서도 원인을 짚기 어려운 방식으로 오작동합니다.

또한 당신을 정직하게 유지하는 주소 검사도 사라지고, 단일 플랫 프리픽스에서 중복 주소는 라우팅 오류가 아니라 서로의 트래픽을 조용히 훔치는 두 호스트입니다. 지점과 랩 사이의 프리픽스 중복은 홈 랩 구성에서 흔하므로 브리지는 그 충돌을 해결하지 않고 분산시킵니다.

보안 논거가 보통 결정을 내립니다. 브리지는 링크 로컬 프로토콜이 동작하는 세그먼트를 넓히므로 지점의 장치가 외부에서 접근할 수 없어야 했던 랩 장치와 대화할 수 있습니다. 랩에 하이퍼바이저, 스토리지 콘솔, 관리 인터페이스가 같은 플랫 네트워크에 있다면 이제 지점과 함께 하나의 세그먼트입니다.

브로드캐스트 없는 이름

사람들이 브리지하는 이유는 대개 검색이며, 프린터, 미디어 장치, 목록에 절대 나타나지 않는 랩 호스트가 대상입니다. 라우티드 답은 이름 서비스입니다. 랩 호스트를 지점의 리졸버가 닿을 수 있는 영역에 게시하고, 사용자는 네트워크를 스캔하는 대신 이름으로 접속하게 하세요. 이는 처음에는 일이 더 많고 앞으로의 모든 변경에서는 훨씬 적습니다.

멀티캐스트 검색은 더 어려운 경우이며 정밀함이 필요합니다. mDNS 같은 프로토콜은 링크 로컬 멀티캐스트를 쓰고 라우터는 기본적으로 이를 전달하지 않으므로, 검색 목록에 없는 랩 호스트도 문서화된 주소로 여전히 접근 가능할 수 있습니다. 특정 서비스가 정말 멀티캐스트를 요구한다면 LAN 전체를 브리지하는 대신 그 하나의 프로토콜을 리플렉터나 표적 전달 규칙으로 설계하세요.

리플렉터도 공짜 승리가 아닙니다. 피하려던 수다스러운 트래픽을 한 번에 하나의 서비스로 끌어들이고, 장치가 예전보다 더 많이 광고하기 시작할 때 알아챌 소유자가 필요하며, 서비스마다 선택해 이유를 적으세요. 어떤 서비스가 그것을 필요로 했고 무엇을 광고하는지 기록하세요. 펌웨어 업데이트가 아무에게도 알리지 않고 그 목록을 바꿀 수 있기 때문입니다.

라우티드 설계를 검증 가능하게 만들기

하나의 목표로 랩의 웹 인터페이스를 자체 서버 서브넷에서 골라 양방향으로 증명하세요. 지점의 호스트에서 주소와 수신 서비스를 로컬에서 확인하고, 그다음 터널로 접속해 반복하세요. 터널이 올라와 있다는 것은 게이트웨이가 합의했다는 뜻일 뿐, 호스트 방화벽이나 반환 경로에 대해서는 아무것도 증명하지 않습니다.

랩의 일반 게이트웨이는 지점 프리픽스로 돌아가는 경로가 필요하며, 설계가 의도적으로 소스를 변환하지 않는 한, 그리고 서버 자체의 방화벽은 허용된 원격 범위를 받아들여야 합니다. 둘 다 성공한 터널이 구성해 주지 않습니다. strongSwan의 전달 관련 노트는 양쪽에서 동작해야 하는 패킷 경로를 설명합니다.

다음으로 거부되는 목적지도 시험하세요. 응용 프로그램 하나가 필요한 지점 사용자에게 하이퍼바이저 콘솔은 필요 없습니다. 정책이 진짜인지 아는 유일한 방법은 거부되어야 할 것을 직접 시도하는 것이며, 프리픽스, 리졸버 의존성, 시험 결과를 기록해 두면 어느 사이트의 향후 변경도 기억에서 다시 만드는 대신 몇 분 만에 검토할 수 있습니다.