Pi 한 대에서 두 개의 VPN 홉: 어느 라우트가 어느 피어를 운반하는가

작은 보드에 터널 주소가 두 개 있으면 실수처럼 보이고, 반사적으로 하나를 지우고 싶어집니다. 그 반사는 정리하려던 것을 망가뜨립니다. 두 홉을 운반하는 호스트는 연결마다 주소를 하나씩 유지하며, 각 주소는 서로 다른 라우트로 선택됩니다. 물어볼 가치가 있는 질문은 어느 라우트가 어느 목적지에 어느 운반자를 고르는가이며, 주소가 몇 개인가가 아닙니다.

서로 다른 운반자가 필요한 세 목적지

두 홉 체인은 세 개의 목적지 클래스가 겹쳐진 것이고, 각각은 서로 다른 연결이 운반합니다. 바깥 피어에는 물리 링크로 도달해야 합니다. 안쪽 피어에는 바깥 터널로 도달해야 합니다. 가려진 애플리케이션의 목적지에는 안쪽 터널로 도달해야 하며, 그 터널 자체의 전송은 바깥 터널이 운반합니다.

라우트를 건드리기 전에 표의 행을 독자의 실제 주소로 채우십시오, 표는 구체적일 때만 쓸모가 있기 때문입니다. 작동하는 체인은 네 행을 동시에 만족하고, 반쯤 작동하는 체인은 보통 그중 하나를 잘못된 운반자로 만족합니다. 잘못된 행을 고장으로 읽는 것이 라우팅 문제를 하루 종일의 수정 작업으로 바꿉니다.

주소에는 개수가 아니라 역할이 있다

리눅스는 한 인터페이스에 여러 주소를, 한 호스트에 여러 터널을 허용하므로 개수는 정확성에 대해 아무것도 말해주지 않습니다. 중요한 것은 어느 주소가 어느 연결에 속하는지, 그리고 특정 피어의 라우트가 의도한 연결을 선택하는지입니다. 세 가지 뷰가 세 방향에서 답하므로 매번 같은 순서로 읽을 가치가 있습니다.

주소 목록은 무엇이 존재하고 어느 연결이 그것을 소유하는지 보여줍니다. 라우트 표는 일반 목적지 트래픽에 대한 운반자 질문에 답합니다. 정책 뷰는 출발지나 표시로 선택된 트래픽에 대해 다시 답하며, 두 클라이언트가 한 호스트를 공유할 때의 정상적인 배치입니다.

ip -4 addr show
ip -4 route show table all
ip rule show

목록이 길어 보여서 주소를 지우면 경로의 일부가 사라질 수 있고, 중복으로 보여서 라우트를 지우면 같은 일을 더 조용히 합니다. 둘 다 오류를 내지 않고, 피어는 의도한 경로에서 응답을 멈출 뿐 다른 경로로는 여전히 도달할 수 있습니다. 안쪽 피어의 출구 주소를 보고하는 애플리케이션은 트래픽이 바깥 터널을 지났음을 증명하지 않습니다, 직접 접근도 같은 관측을 내기 때문입니다. 관측과 증명 사이의 이 간극이 운반자를 라우팅 계층에서 확인하는 이유입니다.

활성화 순서는 고정 대기에 이긴다

안쪽 클라이언트가 바깥 클라이언트가 제공하는 주소나 라우트에 의존한다면, 활성화는 지연이 아니라 그 자원을 기다려야 합니다. 고정 대기는 바깥 터널이 느린 날까지 작동하고, 그다음 아무도 재현할 수 없는 방식으로 간헐적으로 실패합니다. 의존성 기반 순서는 추측을 없애고 의존성을 한 번 설명하는 것 외에는 비용이 들지 않습니다. 인터페이스 이름도 순서 메커니즘이 아닙니다.

커널은 tun0 및 tun1 같은 이름을 생성 순서대로 부여하며, 그 순서는 재부팅이나 재연결 사이에 바뀔 수 있습니다. 구성을 도구가 제공하는 식별자나 의도적으로 부여한 이름에 묶으십시오. 직접 고른 이름은 계약이고, 커널이 고른 이름은 우연입니다.

각 클라이언트의 전송을 다른 클라이언트의 애플리케이션 라우트 밖에 두고, OpenVPN 2.6 라우팅 옵션이 실제로 무엇을 약속하는지 정확히 파악하십시오. 문서화된 기본 리디렉션 메커니즘은 클라이언트가 이미 존재하던 게이트웨이를 통해 자신의 원격 피어에 도달할 수 있게 유지하며, 이는 특정 재귀 루프를 하나 끊습니다. 그것은 한 클라이언트를 다른 클라이언트의 운반자로 만들지 않으므로 체인의 나머지는 여전히 당신의 설계입니다. 체인이 라우트 대신 정책을 필요로 하는 곳에서는 명시적 출발지 또는 표시 규칙을 작성하고 일치시켜야 할 트래픽으로 시험하십시오.

바깥 홉이 죽으면 무슨 일이 일어나는가

체인이 완전하다고 볼 수 있기 전에 바깥 홉이 사라질 때 무슨 일이 일어나는지 결정하십시오. 안쪽 클라이언트의 전송은 그것과 함께 죽고, 다음 수는 기술이 아니라 정책의 질문입니다, 즉 실패시키는 것, 다시 시도하는 것, 아니면 물리 링크를 통해 직접 재연결하는 것입니다. 생각해 볼 가치가 있는 것은 세 번째 결과입니다. 사용자가 아직 커버리지가 온전하다고 믿는 순간, 두 홉 설계를 한 홉 설계로 조용히 바꿔놓습니다.

두 홉이 필수라면 바깥이 사라졌을 때 안쪽 클라이언트가 직접 경로를 세울 수 없어야 하며, 그것을 아는 방법은 바깥 홉을 끊고 안쪽이 어떻게 하는지 관찰하는 것입니다. 승인된 대체 경로는 정당한 답이지만 문서화하고 시험하고 전달해야 합니다. 아무도 문서화하지 않은 대체 경로는 사고 검토에서 유출과 구별되지 않습니다.

DNS와 다른 주소 체계도 같은 결정에 속합니다. 로컬에서 생성된 조회는 전달된 클라이언트의 정책이 아니라 호스트 자체의 정책을 따르므로, 전달 트래픽에 작동하는 확인자가 호스트 자신이 쓰는 것과 다를 수 있습니다.

각 계층을 당신이 만든 순서대로 받아들이십시오

체인이 만들어진 순서대로 시험하십시오: 먼저 바깥 터널만, 다음으로 바깥 터널을 통한 안쪽 클라이언트의 전송, 다음으로 안쪽 터널을 통한 애플리케이션입니다. 모든 승인은 이미 열려 있던 페이지가 아니라 새 연결이어야 합니다. 그다음 각 계층을 따로 끊고 복구하면서 다음 계층이 어떻게 하는지 관찰하십시오.

대체 경로의 결과는 여기서 가장 값진 관측이며, 공인 IP 페이지가 결코 보여주지 않는 것입니다. 피어의 경로, 그들이 쓰는 주소, 그리고 그 결과를 구성 옆에 저장하십시오, 행복한 경로는 나중에 의심받는 부분이 아니기 때문입니다.