웹 서버의 VPN 클라이언트가 응답을 망가뜨리나요?

사이트는 같은 네트워크의 노트북에서는 로드되지만 다른 모든 곳에서는 시간 초과가 되고, 호스트는 자체 아웃바운드 트래픽을 위해 VPN 클라이언트도 실행합니다. 이 조합은 인바운드 연결이 도착하지만 응답은 잘못된 경로로 나가고 바깥의 클라이언트는 응답을 전혀 보지 못하는 특정한 고장을 만듭니다. 두 부분 모두 같은 패킷 캡처에 나타나므로 읽을 가치가 있는 부분은 사건의 순서입니다.

소스 기반 라우팅 규칙은 종종 증상을 고칩니다. 또한 보통 그것을 유발한 사이트보다 더 많은 트래픽을 예외로 두는데, 규칙을 저장하기 전에 이해해야 할 부분이 바로 이것입니다.

증상: 로컬에서는 응답하고 외부에서는 응답하지 않음

네트워크 내부에서는 응답이 터널을 건널 필요가 없으므로 페이지가 로드되고 서비스가 건강해 보입니다. 외부에서는 요청이 호스트에 도달하고 응답은 VPN으로 라우팅되는데, 원격 쪽에는 그것을 받아들일 이유가 없습니다. 브라우저는 거부가 아니라 시간 초과를 보게 되며, 이는 닫힌 포트가 아니라 단방향 경로의 특징입니다.

라우팅을 바꾸기 전에 리스너가 살아 있고 로컬 요청은 성공하며 외부 요청은 전혀 응답을 만들지 않는 형태를 확인하십시오. 이 세 관찰은 함께 웹 서버 구성이 아니라 반환 경로를 가리킵니다. 이렇게 깨끗한 비대칭성은 오류 메시지를 하나도 읽기 전에 리스너를 배제할 수 있으므로 어떤 로그 줄보다 유용합니다.

작업하는 동안 독립적인 관리 경로를 열어 두십시오. 자신의 SSH 세션을 끊는 규칙은 십 분짜리 수정을 물리적 방문으로 바꿉니다.

소스 선택자가 실제로 일치시키는 것

Linux 정책 라우팅에서 from 192.168.50.2 같은 규칙은 소스가 그 주소인 패킷과 일치합니다. 그것은 패킷이 홈 라우터를 통해 들어온 대화를 이어가고 있다는 사실을 인코딩하지 않으며, 어떤 프로세스가 만들었는지도 모릅니다. 그 예시의 주소는 예시일 뿐이므로 호스트가 실제로 사용하는 주소로 바꾸십시오. 이 줄은 주소에 대한 진술로만 취급하십시오.

선택한 테이블이 평범한 기본 경로를 제공하면 그 소스를 가진 모든 패킷이 같은 예외를 탈 수 있습니다. 같은 주소에 바인딩된 다른 서비스도 그것을 상속하고, 의도적으로 그 주소에 바인딩하는 애플리케이션도 상속합니다. 정책 규칙 참조는 소스, 목적지, 프로토콜, 포트, 표시, 우선순위를 별도의 선택자로 나열하며, 이는 소스만으로는 사용 가능한 가장 거친 선택자임을 상기시킵니다.

우선순위가 결과를 결정합니다. 조회는 순서대로 실행되고 결과를 내는 첫 번째 테이블이 검색을 끝낼 수 있으므로, 너무 이른 규칙은 나중 테이블이 제공했을 더 구체적인 경로를 숨길 수 있습니다. 추가한 한 줄이 아니라 전체 순서 목록을 읽으십시오. 절대 일치하지 않는 규칙은 비용이 없지만, 너무 일찍 일치하는 규칙은 뒤에 있는 모든 것을 조용히 바꿉니다.

반환 경로와 의도하지 않은 트래픽을 확인하십시오

규칙과 테이블을 읽은 다음 커널에 특정 소스와 목적지 쌍이 어떤 경로를 탈지 물으십시오. 호스트 자체에서 테스트하는 것은 외부에서 테스트하는 것과 같지 않으므로 둘 다 하십시오.

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

그런 다음 새로운 외부 연결을 받아들이고, 별도로 여전히 VPN을 통해 나가야 하는 요청을 받아들이십시오. 두 번째가 이제 직접 나간다면 예외는 해결하던 문제보다 넓은 것이며, 중요한 테스트는 바꿀 생각이 없었던 쪽입니다.

브라우저의 공인 주소 확인은 그 브라우저가 만든 요청만 보고합니다. 웹 서버의 응답, 다른 로컬 애플리케이션의 소스 선택, 또는 다음 VPN 재연결 후 관리 트래픽에 무슨 일이 일어나는지에 대해서는 아무것도 말하지 않습니다.

예외가 얼마나 좁을 수 있는지 결정하십시오

두 가지 설계가 방어 가능하며 의도적으로 선택해야 합니다. 호스트가 이 서비스를 게시하기 위해 존재하고 아웃바운드 트래픽이 중요하지 않다면, WAN 전용 정책을 가진 전용 로컬 주소는 전체 범위를 받아들이는 조건에서 합리적인 구성입니다. 특정 인바운드 연결만 자격을 갖추어야 한다면 주소 선택은 너무 거칠며 그 앞에 연결을 인식하는 설계가 있어야 합니다.

의존하는 계약, 즉 공인 매핑, 요청이 전달되는 호스트 주소, 응답이 취해야 할 경로를 기록하십시오. VPN 공급자를 통해 게시된 인바운드 서비스는 홈 라우터를 통해 게시된 것과 다른 계약이며, 한 예시에서 복사한 예외는 다른 쪽에 종종 틀립니다.

명령을 시작 파일에 붙여 넣는 대신 라우팅을 소유한 구성 요소에 정책을 유지하십시오. 규칙 순서, 네트워크 변경 후 정리, 재부팅 후 재적용이 모두 살아남아야 하며, 테스트하지 않은 시작 파일은 보통 당신이 보지 않는 순간에 실패합니다. 방어할 수 있는 수용 결과, 즉 게시된 사이트 하나가 복구되고 무관한 흐름 하나가 변하지 않은 상태로 끝내십시오.