N2N 오버레이는 프록시가 아니다: 두 연결을 따로 그려라

Firefox는 127.0.0.1:8000을 가리키고, N2N 엣지는 살아 있고, 피어는 자신의 오버레이 주소에서 ping에 응답하는데, 브라우저는 여전히 프록시가 연결을 거부했다고 보고합니다. 그 연쇄에는 모순이 없습니다. 오버레이는 호스트에 사설 네트워크에서 도달할 수 있는 주소를 주지만, 프록시 프로토콜을 말하는 프로세스를 만들지는 않습니다. 브라우저는 피어로 가는 경로를 요구하지 않습니다. 로컬 리스너를 요구합니다.

여기서 두 연결이 혼동되고 있으며, 따로 그리면 혼란의 대부분이 일 분 안에 풀립니다.

연결은 둘, 하나가 아니다

첫 번째 연결은 브라우저에서 loopback 포트에서 수신하는 대상으로 갑니다. 그것은 로컬 소켓이며, 아무것도 그것을 소유하지 않으면 패킷 하나도 N2N에 도달하기 전에 연결이 거부됩니다. 두 번째는 프록시 프로세스에서 그것이 가져오는 오리진으로 갑니다. 그 경로는 프록시 호스트의 라우팅 테이블이 선택하며, 일반 업링크일 수도, 다른 터널일 수도, 오버레이와 무관한 정책 경로일 수도 있습니다.

피어에 ping이 통한다는 것은 오버레이가 엣지 주소 사이에서 패킷을 전달할 수 있다는 증거입니다. 포트 8000의 리스너에 대해서는 아무것도 증명하지 않으며, 그 호스트가 오리진에 도달할 수 있는지도 증명하지 않습니다. 별개의 고장에는 별개의 수정이 필요합니다.

리스너는 어디에 있어야 하는가

127.0.0.1에 바인드된 프록시는 의도적으로 로컬이며, 실행 중인 머신에서만 연결을 받습니다. 개인용 프록시에는 올바른 기본값이지만 오버레이를 통해 공유하기에는 잘못된 형태입니다. 오버레이 피어에 서비스를 제공하려면 오버레이 인터페이스의 바인드 주소나 loopback 연결을 종료하고 전달하는 컴포넌트가 필요합니다. 어느 쪽이든 공유 네트워크의 열린 프록시는 초대장이므로, 어떤 오버레이 소스가 서비스를 쓸 수 있는지 명시적 정책으로 결정해야 합니다.

실제 바인드는 구성 파일이 아니라 소켓 목록으로 확인하세요. 오버레이가 올라오기 전에 시작된 데몬은 더 이상 존재하지 않는 주소에 여전히 바인드되어 있을 수 있습니다.

localhost는 피어가 아니다

브라우저의 프록시 필드에서 localhost는 브라우저 자신의 머신을 가리킵니다. 엣지도, 슈퍼노드도, 터널의 먼 쪽 호스트도 아닙니다. 프록시가 다른 피어에서 실행된다면 그 피어의 도달 가능한 오버레이 주소와 포트를 필드에 넣고, 리스너가 당신의 엣지 주소에서 오는 연결을 받는지 확인하세요.

슈퍼노드는 엣지끼리 서로를 찾도록 도울 뿐 프록시 서비스가 아닙니다. 슈퍼노드 주소를 프록시 엔드포인트로 취급하면 같은 거부에 혼란의 한 단계가 더해질 뿐입니다.

경로는 핸드셰이크를 수행할 수 없다

주소가 맞더라도 라우팅은 프록시가 아닙니다. HTTP 프록시 연결은 CONNECT 요청이나 절대 형식의 요청 라인으로 시작하고, SOCKS 프록시는 버전과 메서드 협상으로 시작합니다. 라우터나 오버레이는 바이트를 전달할 뿐 그 메시지를 해석하지 않고 대신 다음 연결을 열지 않습니다. 그래서 ping과 SSH에 통하는 경로가 브라우저 프록시에는 실패할 수 있지만, 브라우저에 필요한 것은 협조하는 프로세스이지 단순한 도달 가능성이 아닙니다.

목표가 단지 피어의 서비스에 도달하는 것이라면 프록시 설정을 제거하고 서비스의 오버레이 주소를 직접 사용하세요.

경계를 순서대로 시험하라

오버레이 주소가 응답하는지 확인하고, 다음으로 구성된 포트에 리스너가 있는지 확인해 그 바인드 주소를 기록하세요. 통제된 요청을 하나 보내고 프록시 로그를 읽어, 실패가 리스너 쪽인지 이후 가져오기 쪽인지 파악하세요. 마지막으로 프록시 호스트의 경로와 오리진에 대한 DNS 정책을 확인하세요.

N2N 프로젝트는 엣지와 슈퍼노드를 오버레이 구성 요소로 문서화합니다. 엣지를 애플리케이션 프록시로 바꾸지 않으며, 아무도 시작하지 않은 프로토콜 핸들러를 추가하는 라우팅 구성은 없습니다.