로컬호스트란 무엇인가요?
소개
localhost는 Go로 작성된 가볍고 간단한 인트라넷 침투 도구입니다. 이 도구는 웹 서비스 매핑을 지원합니다. 로컬 호스트에서 시작된 서비스를 원격 서버에 매핑하고, 원격 서버에 접속할 때 로컬과 원격 사이에 이미 설정된 터널을 사용하여 실제 요청을 로컬 서비스로 전송하여 로컬 서비스에 접속합니다. Go로 작성하는 이유는 무엇인가요? 다른 언어에 비해 Go는 컴파일이 쉽고 추가적인 런타임 환경 요구 사항이 없으며, 로컬 교차 컴파일을 통해 모든 종류의 시스템에 대한 실행 파일을 얻을 수 있어 사용자에게 매우 친숙합니다.
사용
도움말 파일은 여기: localhost 도움말 파일, 도움말 파일 또는 CyberCloud 테스트 플랫폼의 클라우드 실제 머신 사용 페이지에서 도구를 다운로드할 수 있습니다.
위에서 언급했듯이 localhost는 가볍고 사용하기 쉬우며, 시작 매개변수 두 개만 있는 독립 실행형 실행 파일로 다음과 같이 시작됩니다:
# windows
localhost.exe -token xxxxxxxx -port xxxx
# mac
localhost -token xxxxxxxx -port xxxx
-토큰 이 매개 변수는 현재 사용 중인 토큰으로, CyberCloud 테스트 플랫폼의 클라우드 실제 머신 사용 페이지에서 적용할 수 있으며 매번 30분 동안 유효합니다.
-port 이 매개변수는 현재 로컬로 시작된 서비스의 포트입니다.
클라이언트의이 부분의 설계에서 가능한 한 모든 사람의 사용 임계 값을 줄이기 위해 의도적으로 가능한 한 적은 매개 변수의 설계, 포트 포트 매개 변수가 필수적이며 토큰 매개 변수 설계가 필요한 이유,이 매개 변수의 초기 의도는 ssh 프로토콜의 키와 유사한 사용자의 신원을 식별하여 동작을 추적 한 다음 토큰을 사용하여 사용을 제어 할 수 있도록하는 것입니다. 나중에 토큰은 일회용 만료일과 같은 사용 동작을 제어하는 데 사용되었습니다. 다른 매개 변수는 기능 및 보안에 영향을 미치지 않는 경우 제외되었으므로 사용하기에 충분히 쉬웠으면 좋겠습니다.
원칙
전체 도구는 서버, 클라이언트, 웹의 세 부분으로 나뉩니다. 서버와 클라이언트는 채널 설정, 채널 포워딩 및 기타 로직을 포함하여 서비스 매핑의 주요 부분입니다. 웹 측은 일부 대화형 인터페이스, 라우팅 집계 프록시 포워딩 처리를 제공합니다.
핵심 논리
로컬 호스트의 핵심 부분은 서버와 클라이언트 모두에 의해 달성되는 인트라넷 침투입니다. 우리 모두 알다시피 로컬 서비스는 로컬 또는 LAN 내에서만 액세스 할 수 있으며 원격 장치는 로컬 서비스에 액세스 할 수 없지만 로컬 장치는 통신을 위해 설정된 원격 터널에 대한 로컬 액세스를 통해 원격 서비스에 액세스하여 원격 장치가 로컬 서비스에 액세스 할 수있는 목적을 달성 할 수 있습니다.
전체 흐름도는 아래와 같습니다:
먼저 서버에서는 기반 서비스의 전체 서비스 중 스케줄링 부분인 웹 사이드 부분이 시작되는데, 이는 웹 인터페이스에 대한 클라이언트 측 호출 중 일부와 사용자의 요청 시 역방향 프록시 등을 제공하는 역할을 합니다. 웹 사이드 서비스는 원격 서버에서 장시간 실행되고 있으며, 다음 부분에서 어떤 작업이 이루어지는지 자세히 설명하겠습니다.
클라이언트 측은 내부 친구들에게 배포되어 다운로드하여 사용할 수 있습니다. 클라이언트 측을 실행할 때 클라이언트는 웹 서비스를 호출하고 해당 서버 측을 시작한 후 관련 파라미터 정보를 전달하여 클라이언트 측에 반환합니다.
서버가 시작되면 두 개의 포트를 수신 대기하기 시작합니다. 하나는 사용자 요청 포트, 다른 하나는 클라이언트 측의 터널 연결 포트를 수신 대기합니다. 클라이언트가 원격 서버에 연결하면 현재 연결을 통해 통신 터널을 열고, 사용자 요청이 들어오면 설정된 통신 터널을 통해 로컬 서버로 요청 메시지를 전달합니다. 사용자 요청이 들어오면 설정된 통신 터널을 통해 로컬 클라이언트로 요청 메시지를 전달합니다.
클라이언트가 시작을 완료하고 웹 서비스 호출에서 성공적으로 돌아온 후 클라이언트는 해당 서버에 연결하기 위해 관련 정보를 얻고 터널이 성공적으로 설정된 후 서버가 전달한 요청 정보를 기다립니다. 요청을 수신하면 클라이언트는 지정된 포트의 로컬 서비스에 연결하여 요청 메시지를 현재 로컬 서비스로 전달하고, 동시에 기존 링크를 통해 요청자에게 응답 메시지를 반환합니다.
이러한 방식으로 서비스 침투를위한 전송 서버를 통해 로컬 서비스에 대한 원격 액세스 목적을 달성 할 수 있으며이 방법은 사용자가 중간 프로세스에주의를 기울일 필요가 없으며 제공되는 서비스의 클라이언트 측만 시작하면되며 기본적으로 사용 비용이없는 간단한 사용은 코드에 영향을 미치지 않습니다.
경로 집계 역방향 프록시
사용 과정에서 일부 친구들은 클라이언트 터미널 시작이 완료되면 액세스 링크를 표시하기 위해 돌아 오는데,이 링크를 방문하면 자신의 로컬 서비스에 직접 액세스 할 수있는 이유가 무엇인지에 대한 질문이있을 수 있습니다. 클라이언트 측이 시작되면 웹 측의 인터페이스 서비스를 호출하고 이때 현재 사용자의 신원을 기록하고 서버 측을 시작하면 시작 서버 포트와 현재 사용자 ERP 간의 매핑 관계를 형성하고 현재 ERP에 따라 역방향 프록시 규칙을 설정합니다. 웹 측에서 시작된 서비스에는 현재 요청을 수신하는 서비스가 있으며, 어느 곳에서든 웹 측 서비스에 액세스하면 액세스 경로를 수신하고 판단하여 기존 연결의 ERP 정보와 일치하면 현재 액세스 요청 메시지를 해당 서버 측 서비스에 전달하고 서버 측은 해당 클라이언트 측에 요청을 전달합니다.
흐름도는 아래와 같습니다:
또한 집계 된 ERP 경로를 통한 첫 번째 액세스 후 현재 액세스의 IP가 기록되고 IP와 ERP 매핑 관계도 후속 액세스에 해당하며 경로는 ERP 정보를 전달할 수 없지만 현재 로컬 서비스에 매핑 될 수 있으며 일부 정적 리소스에 대한 액세스 경로 문제를 해결하는 데 사용할 수 있으며 기록 문제를 해결하는 데 사용할 수도 있습니다. 경로 액세스.
데모
**, 지속 시간 02:14
미래
history 라우팅
프런트 엔드 프로젝트의 경로가 히스토리 모드를 채택하면 위의 ERP 집계 경로는 액세스 할 ERP를 제거한 후 ERP 경로에 대한 첫 번째 액세스를 통해 액세스 할 수 있지만 일반적으로 여전히 약간의 문제를 가져 오며 후속 계획은 범 도메인 이름 확인을 사용하여 경로 처리를 제거하고 도메인 이름을 통해 사용자의 신원을 확인하여 경로를 사용자의 원래 모습으로 다시 확인하여 추가 문제와 이해 비용을 유발하지 않는 상황을 갖게됩니다. 다음 계획은 일반 도메인 이름 확인을 사용하여 라우팅 처리를 제거하여 사용자 식별을 도메인 이름으로 확인하고 라우팅이 사용자의 원래 모습으로 돌아갈 수 있도록하여 추가 문제와 이해 비용을 유발하지 않는 것입니다.
https 지원
현재 로컬 호스트 도구는 상호 작용 과정에서 여전히 http 프로토콜이며 현재 로컬 프로젝트의 https 구성을 제거해야만 사용할 수 있지만 일부 친구들이 우리와 소통하고 일부 프로젝트에서 https 요청이 필수라는 것을 알게되어 향후 https를 지원할 예정이며, https 요청 인 한 로컬 프로젝트의 https로 기본 설정 될 것으로 예상하고 있습니다. 별도의 명시적 구성이나 선언 없이 로컬 프로젝트의 https로 기본 설정됩니다.
결론
로컬 코드 원격 도로는 많은 방향을 경험하는 전체 과정에서 많은 아이디어를 생성하고 궁극적으로 로컬 호스트이 도구를 탄생 시켰으며, 이후에는 더 많은 시나리오와 결합되어이 도구를 계속 개선하고 모든 사람이 작업 과정에서 더 빠르고 비용을 절약 할 수 있기를 바랍니다.
