홈랩 스플릿 터널: 필요한 것만 라우팅하세요, 전부가 아니라

홈랩에 전체 터널이 필요하다는 조언은 보통 그것을 갖고 있던 튜토리얼에서 나온 것이지 요구 사항에서 나온 것이 아닙니다. 스플릿 터널링은 제대로 된 VPN의 타협 버전이 아니라 라우팅 테이블을 설명할 수 있는 버전입니다. 서비스 다섯 개와 관리 인터페이스 하나가 있는 랩에 집을 떠나는 모든 패킷이 터널을 지날 필요는 없습니다. 필요한 것은 목록과 그 목록의 각 항목에 대한 경로입니다.

신화: 스플릿 터널링은 타협이다

신화가 남는 이유는 전체 터널이 한 번 설정하기는 쉽고 나중에 디버깅하기는 어렵기 때문입니다. 그 맞바꿈은 공용 Wi-Fi의 노트북에는 합리적이고 지하실의 랙에는 틀렸습니다.

랩의 주소 체계가 접속하는 네트워크와 아무 공통점이 없다는 두 번째 가정도 숨깁니다.

경로보다 먼저 자원을 목록화하세요

랩의 각 서브넷, 거기 사는 서비스, 그것을 해석하는 이름, 접근이 허용된 사람을 적고, 당신의 포워딩 노트가 게이트웨이에 대해 계획의 기준이 되는 반환 경로를 설명합니다. 컨테이너 범위와 원격 클라이언트가 이미 쓰고 있을 수 있는 LAN 범위도 더하세요. 겹침이야말로 이 목록이 막는 실패입니다. 모든 사설 주소를 덮는 경로는 조만간 가정용 네트워크와 충돌하며, 목록은 테스트 계획이기도 하므로 설정 뒤가 아니라 앞에 만드는 것이 좋습니다.

각 자원에 터널 경유, 직접, 또는 거부의 경로를 지정하세요. 경로가 지정되지 않은 자원이 나중에 혼란스러운 지원 질문을 만듭니다.

다섯 행과 결정의 한 열이 아무도 읽을 수 없는 라우팅 테이블을 이깁니다.

게이트웨이에는 반환 경로가 필요합니다

게이트웨이의 포워딩은 절반일 뿐입니다. 랩에는 클라이언트 풀로 돌아가는 경로나 반환을 가능하게 하는 지원되는 변환 구성이 필요합니다. 응답이 클라이언트를 찾지 못하면 터널은 연결된 것처럼 보이고 모든 요청이 시간 초과됩니다. 이것은 VPN의 고장이 아니라 라우팅의 증상이므로, 반환 경로는 문제 해결 단계가 아니라 설계의 일부로 확인하세요.

랩 자체의 주소 체계와 겹치는 클라이언트 풀은 이 문제의 나머지 절반이며 똑같은 방식으로 실패합니다.

두 범위가 충돌하면 증상이 아니라 계획을 고치세요.

관리와 인터넷 역할은 분리되어 있습니다

터널을 랩 트래픽만 쓰는지, 인터넷 출구도 되는지 결정하세요. 튜토리얼이 썼다는 이유만으로 기본 경로를 더하지 마세요—그 결정은 모든 DNS 질의와 모든 업데이트 확인이 어디로 가는지를 바꿉니다. VPN 엔드포인트 자체로 가는 바깥 경로를 남겨 두지 않으면 터널이 자기 바깥 연결을 실으려 할 것입니다. 관리 접근은 좁게 유지하고 승인된 복구 방법으로 닿을 수 있게 하세요.

모든 공개 질의에 같은 리졸버가 필요하다고 가정하지 않고 랩 이름에 사설 DNS를 고를 수 있습니다. 그것은 리졸버의 결정이지 경로의 결정이 아닙니다.

둘을 분리해 두는 것이 나중에 실패 모드를 구별할 수 있게 합니다.

LAN이 아니라 바깥에서 시험하세요

같은 LAN에서 시험하는 대신 외부의 승인된 연결을 쓰세요—같은 LAN의 시험은 빠진 반환 경로를 완전히 감출 수 있습니다. 랩 주소, 그 사설 호스트 이름, 의도한 직접 목적지, 필요한 실패 동작을 확인하세요. 실패 사례는 성공 사례만큼 중요합니다. 닿지 말아야 할 자원은 정말로 닿지 않아야 하므로, 설계가 끝났다고 말하기 전에 네 가지 결과를 모두 기록하세요.

그다음 라우팅과 DNS 구성을 목록 옆에 저장하고 소유자를 적으세요. 랩에 서브넷이 하나 더 생기면 둘 다 갱신하고 다시 시험하세요.

기존 가정용 네트워크와 겹치는, 설명되지 않는 경로는 그 단계를 건너뛴 기본 결과입니다.

완성된 설계는 작고 문서화되어 있으며 지루하고, 랩이 자기 네트워크에 바라는 것이 바로 그것입니다. 흥미로운 버전은 집을 떠나 있는 동안 깨지는 버전입니다.