응답은 터널이 아니라 LAN으로 나간다: 이유와 방법

게이트웨이를 통해 게시한 서비스는 인터넷 대부분에서 동작하지만 한 사무실에서는 실패합니다. 누군가 터널을 확인하고 요청이 도착하는 것을 보고 응답도 같은 경로로 돌아가야 한다고 결론짓습니다. Linux는 그렇게 동작하지 않으며, 터널을 아무리 들여다봐도 응답은 달라지지 않습니다. 응답은 목적지에 따라 라우팅되고, 실패하는 그 한 호출자는 호스트가 이미 직접 도달하는 서브넷에 있습니다.

나가는 패킷을 실제로 결정하는 것

커널은 패킷의 목적지에 대한 경로를 조회하며, 정책 규칙을 우선순위 순으로 살핀 뒤 일치하는 규칙이 선택하는 테이블을 봅니다. 패킷이 도착한 인터페이스는, 그것을 중요하게 만들 규칙이나 마크가 쓰여 있지 않은 한 아무 역할도 하지 않습니다. 이것은 이 호스트의 라우팅 사실이지 터널의 결함이 아닙니다.

따라서 터널에서 받은 요청이 물리 인터페이스로 나가는 응답을 만들 수 있고, 어떤 장비도 오류를 보고하지 않은 채 흐름이 단방향이 됩니다. 터널에 대해 결론을 내리기 전에 양방향을 확인하십시오. 잘못된 방향으로 나간 응답은 터널 카운터에서 사라지므로, 무언가 전송되었는지에 대해 양쪽이 서로 다른 말을 합니다. 규칙을 건드리기 전에 어느 카운터가 움직였는지 확인하십시오.

로컬 서브넷이 이기는 이유

로컬 네트워크에 주소가 있는 호스트는 메인 테이블에 해당 프리픽스에 대한 연결 경로를 가지며, 연결 경로는 직접 일치입니다. 호출자가 같은 서브넷에서 오면 조회는 터널을 고려하기도 전에 로컬 링크를 찾습니다.

이 비대칭성이 진단을 혼란스럽게 만듭니다. 더 넓은 인터넷의 호출자는 어떤 로컬 경로와도 일치하지 않아 동작하지만, 사무실 프리픽스를 공유하는 유일한 호출자는 실패합니다, 그리고 누군가 테스트에 쓰는 것이 바로 그 호출자입니다.

피어 범위는 설치된 경로와 같지 않습니다

터널 쪽에서 피어의 허용 범위는 터널로 무엇을 보낼 수 있고 어떤 소스를 받아들이는지를 설명합니다. 로컬 라우팅 테이블이 패킷을 어디로 보낼지에 대해서는 아무 말도 하지 않습니다.

터널 도구가 호스트에 기본 경로를 설치하면 관련 없는 트래픽을 부수적 피해로 터널에 끌어들일 수 있습니다. 그 대신 정책 규칙이 결정을 맡아야 하는 곳에서는 도구의 경로 설치 옵션이 바로 그것을 막기 위해 존재하며, 주소와 키, 엔드포인트 설정은 그대로 유지됩니다. 편의를 위해 추가한 기본 경로는 호스트가 자기 로컬 네트워크를 잃는 흔한 방식입니다.

소스 주소로 테이블을 선택하십시오

소스 기반 규칙은 서비스 주소에서 나가는 응답을 기본값이 터널인 전용 테이블로 보내고, 나머지는 모두 메인 테이블을 계속 사용합니다. 로컬에서 쓰이지 않는 테이블 번호와 우선순위 번호를 고르고, 무엇이든 삽입하기 전에 기존 규칙을 읽으십시오. 저장된 파일이 아니라 살아 있는 규칙을 읽으십시오, 재부팅 후에는 둘이 다를 수 있습니다.

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

마지막 줄은 경로가 없을 때 로컬 링크로 폴백하는 대신 눈에 보이게 실패하게 만듭니다. 소스는 실제로 호스트에 할당되어 있어야 하고, 일반적인 로컬 및 메인 조회는 이전 위치에 남아 있어야 합니다. 규칙은 소스로 테이블을 고르며, 테이블 간에 프리픽스 길이를 비교하지 않습니다.

경로를 확인하고, 그다음 서비스를 확인하십시오

캡처에서 추론하는 대신, 서비스 주소를 소스 선택자로 사용해 커널에 무엇을 할지 물어보십시오. 여기서 올바른 답을 얻으면 패킷 추적을 통째로 아낄 수 있습니다.

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

출력에는 터널 이름이 나와야 합니다. 그다음 건드리지 않은 소스를 시험해 여전히 로컬 링크를 사용하는지 확인하여 변경이 한 주소에 국한되었음을 입증하십시오. 더 넓은 선택자는 원래 불만에 대해 아무것도 증명하지 못합니다.

이것이 고치지 않는 것

게이트웨이의 포워딩, 방화벽 규칙, ICMPv6 동작은 소스 경로가 그 무엇도 대체하지 않으므로 그대로 두십시오. Packet Too Big 메시지가 없으면 어느 테이블이 조회에서 이겼든 큰 응답은 여전히 깨집니다. 라우팅 규칙을 추가하기 전에 고치지 않으면 증상이 변경 후에도 남습니다.

이 중 무엇이든 적용하기 전에 게시 모델을 확인하십시오. 자체 백엔드 연결을 여는 리버스 프록시는 자신의 소스를 제시하고 호출자를 보존하지 않으므로, 그 설계에서는 이 결함이 발생할 수 없습니다. 거기에 규칙을 적용하면 아무것도 해결하지 못하고 실제 원인을 가리는 라우팅 예외가 추가됩니다.

마지막으로 규칙 번호와 테이블을 호스트의 구성 관리에 기록하십시오. 손으로 추가한 정책 규칙은 다음 재구축에서 사라지고, 사무실 호출자는 같은 불만을 안고 돌아옵니다.