호스트 라우트를 건드리지 않고 네임스페이스에서 VPN 라우팅 테스트하기

두 랩은 같은 VPN 토폴로지를 모델링하면서도 전혀 다른 방식으로 실패할 수 있습니다. 하나는 네트워크 네임스페이스 안에 살고, 다른 하나는 호스트 자체의 라우트 위에 삽니다. 네임스페이스 버전은 모든 인터페이스, 라우트, 소켓을 삭제할 수 있는 컨텍스트에 보관하고, 호스트 버전은 더 빨리 시작하지만 상태를 남깁니다. 그 남은 상태가 한 달 뒤 두 번째 랩을 반복하기 어렵게 만드는 이유입니다. 먼저 정리를 비교하세요. 실험을 두 번 실행할 수 있는지는 그것이 결정합니다.

같은 랩을 만드는 두 가지 방법과 각각이 이기는 상황

호스트 라우트 랩에서는 작업 중인 머신에 터널 인터페이스와 라우트를 추가하므로, 실험은 셸, 패키지 관리자, 그리고 다른 모든 연결과 운명을 함께합니다. 네임스페이스 랩에서는 각 역할이 인터페이스, 주소, 라우트, 소켓의 자체 스택을 받고, 네임스페이스를 삭제하면 그것이 모두 사라집니다. 어느 모델도 더 옳지 않습니다. 서로 다른 질문에 답하기 때문입니다. 주제가 라우팅과 포워딩이면 네임스페이스를, 주제가 데스크톱 클라이언트 하나가 어떻게 통합되는지라면 호스트 랩을 고르세요.

둘을 섞는 것이 흔한 실수입니다: 호스트 클라이언트에 대해서만 테스트한 네임스페이스 랩 은 어느 배치에 대해서도 아무것도 증명하지 않습니다. 첫 링크를 만들기 전에 어떤 질문을 하는지 결정하세요.

역할마다 하나의 컨텍스트, 의도적으로 연결

역할마다 네임스페이스 하나를 만들고 각 veth 쌍의 양 끝을 그것을 소유한 컨텍스트로 옮기세요. 처음 네 개의 명령이면 형태를 보기에 충분합니다:

ip netns add client
ip netns add gateway
ip link add veth-c type veth peer name veth-g
ip link set veth-c netns client

호스트의 무엇과도 겹치지 않는 범위를 랩에 주고, 시작하기 전에 어느 네임스페이스가 어느 주소를 소유하는지 적어 두세요. 작동하는 랩에는 두 개의 별도 경로가 필요합니다. VPN 엔드포인트가 상대에 도달하기 위한 외부 경로와, 보호되는 리소스를 위한 반환 경로이며, 그것들을 두 가지 결정으로 모델링하세요. 나가는 절반만 만드는 랩은 핸드셰이크 테스트를 통과하고 애플리케이션 테스트에서 실패합니다.

포워딩 역할이 랩을 흥미롭게 만드는 지점

한 역할은 포워딩해야 하며, 이는 그 네임스페이스 안에서 포워딩을 활성화하고 설계에 필요한 규칙을 추가하는 것을 뜻하고, 포워딩 상태는 네임스페이스마다이므로 호스트 설정은 랩과 무관하며 랩 설정은 밖으로 새지 않습니다. 네트워크 네임스페이스 문서 가 설명하듯이요. WireGuard는 인터페이스와 그 외부 소켓이 서로 다른 네임스페이스에 살 수 있다고 문서화합니다. 이는 유용한 요령이자 자신을 혼란스럽게 만드는 훌륭한 방법입니다. 인터페이스를 옮기면 연결의 모든 부분이 똑같이 옮겨진다고 가정하지 마세요.

테스트 패킷 후 포워딩 카운터를 확인하세요. 한 번도 일치하지 않은 규칙과 패킷을 버린 규칙은 라우트 테이블에서 똑같이 보입니다. 카운터만이 둘을 구분합니다.

기준선을 기록한 다음 라우트 하나를 깨뜨리기

존재하는 것을 기록하는 것으로 시작하고, 각 줄 옆에 컨텍스트를 적으세요. 네임스페이스를 읽고, 다음으로 테스트 목적지가 그중 하나 안에서 택할 라우트를, 다음으로 그것을 나르는 링크의 카운터를 읽으세요:

ip netns list
ip -n client route get 10.0.0.5
ip -n gateway -s link show veth-g

세 번째 명령은 사람들이 건너뛰는 것이고, 증거가 사는 곳이 바로 거기입니다. 버린 수와 오류 카운터는 패킷이 포워딩 역할에 애초에 도달했는지 알려 줍니다. 변경 후 같은 세 가지 보기를 기록하고, 증거는 기억이 아니라 diff가 되게 하세요. 그다음 정확히 하나를 깨뜨려, 라우트를 삭제하거나 포워딩 경로에 거부 규칙을 추가하고 예상한 증상을 확인하세요. 응답 없는 완료된 핸드셰이크, 또는 타임아웃 대신 이름 확인 실패입니다. 성공만 보여 주는 랩은 아주 적게 가르칩니다.

정리가 다음 실행을 반복 가능하게 만든다

정리는 이름 붙인 리소스로 한정하세요. 전면적인 방화벽 재설정이나 호스트 라우트 제거는 재현성이 아니라 두 번째 사고입니다. 토폴로지, 정확한 명령, 기대한 관찰을 저장하면 다음 실행은 이전 상태가 어느 컨텍스트에 있었는지 추측하지 않고 같은 실패를 재현합니다. 그 기록이 없으면 랩은 절차가 아니라 이야기입니다.

랩에는 로컬에서 생성한 자격 증명을 사용하고, 프로덕션 계정은 공유 예제에서 빼 두세요. 그다음 각 네임스페이스를 삭제하고 호스트 보기가 바뀌지 않았음을 확인하세요. 이것이 이 모델을 고르는 이유 전부입니다. 깔끔하게 제거할 수 없는 랩은 단계가 더 붙은 호스트 변경입니다.