fatedier/frp빠른 리버스 프록시로, NAT 또는 방화벽 뒤에 있는 로컬 서버를 인터넷에 노출할 수 있도록 도와줍니다.
frp는 훌륭한 스폰서들의 지원으로 지속적인 개발이 가능한 오픈 소스 프로젝트입니다. 함께하고 싶다면 frp 개발 후원을 고려해 주세요.
당신이 직접 제어하는 주권 클라우드
데이터 소유권과 프라이버시를 위해 구축된 오픈 소스, 자체 호스팅 퍼블릭 클라우드 대안
회의 녹화 API를 찾고 있다면 Recall.ai를 확인해 보세요.
Zoom, Google Meet, Microsoft Teams, 대면 회의 등을 녹화하는 API입니다.
frp는 NAT 또는 방화벽 뒤에 있는 로컬 서버를 인터넷에 노출할 수 있게 해주는 빠른 역방향 프록시입니다. 현재 TCP와 UDP, 그리고 HTTP 및 HTTPS 프로토콜을 지원하며, 도메인 이름을 통해 내부 서비스로 요청을 전달할 수 있습니다.
frp는 또한 P2P 연결 모드를 제공합니다.
frp는 현재 개발 중입니다. master 브랜치에서 최신 릴리스 버전을 사용해 보거나, dev 브랜치를 사용하여 현재 개발 중인 버전에 접근할 수 있습니다.
현재 버전 2를 작업 중이며 일부 코드 리팩토링과 개선을 시도하고 있습니다. 다만 버전 1과 호환되지 않을 것임을 유의하시기 바랍니다.
적절한 시점에 버전 0에서 버전 1로 전환할 예정이며, 큰 기능 요청보다는 버그 수정과 개선만 수용할 것입니다.
v2 버전의 복잡성과 난이도는 예상보다 훨씬 높습니다. 산발적인 시간에만 개발을 진행할 수 있고, 끊임없는 중단이 생산성을 크게 저하시킵니다. 이러한 상황에서 메이저 버전 개편을 진행할 충분한 시간이 생길 때까지 현재 버전을 계속 최적화하고 반복할 것입니다.
v2의 개념은 클라우드 네이티브 분야, 특히 K8s와 ServiceMesh에서의 수년간의 경험과 성찰에 기반합니다. 그 핵심은 envoy와 유사한 현대화된 4계층 및 7계층 프록시입니다. 이 프록시 자체는 확장성이 매우 높아 내트래버스(내트워크 관통) 기능을 구현할 수 있을 뿐만 아니라 다양한 다른 영역에도 적용할 수 있습니다. 이 확장성이 높은 코어를 기반으로 frp v1의 모든 기능을 구현하면서도 이전에는 달성할 수 없었거나 우아한 방식으로 구현하기 어려웠던 기능들도 해결하고자 합니다. 또한 효율적인 개발 및 반복 역량을 유지할 것입니다.
또한 frp 자체가 K8s를 기반으로 다양한 확장 기능을 제공할 수 있는 것처럼, 고도로 확장 가능한 시스템이자 플랫폼이 되기를 구상하고 있습니다. K8s에서는 CRD, 컨트롤러 모드, webhook, CSI, CNI와 같은 기능을 활용하여 기업 요구에 맞게 맞춤 개발할 수 있습니다. frp v1에서는 서버 플러그인 개념을 도입하여 기본적인 확장성을 구현했습니다. 그러나 이는 단순한 HTTP 프로토콜에 의존하며 사용자가 독립적인 프로세스를 시작하고 직접 관리해야 합니다. 이 방식은 유연하고 편리하다고 보기 어렵고, 실제 요구 사항은 매우 다양합니다. 소수의 인원이 유지 관리하는 비영리 오픈 소스 프로젝트가 모든 사람의 요구를 충족시킬 것이라고 기대하는 것은 비현실적입니다.
마지막으로, 구성 관리, 권한 검증, 인증서 관리, API 관리와 같은 모듈의 현재 설계가 충분히 현대적이지 않다는 점을 인정합니다. v1 버전에서 일부 최적화를 수행할 수는 있지만, 호환성을 유지하는 것은 상당한 노력이 필요한 어려운 문제로 남아 있습니다.
frp에 대한 지원에 진심으로 감사드립니다.
먼저 Release 페이지에서 운영 체제와 아키텍처에 맞는 최신 프로그램을 다운로드하세요.
다음으로, 공인 IP 주소가 있는 서버 A에 frps 바이너리와 서버 구성 파일을 배치하세요.
마지막으로, 공용 인터넷에서 직접 접근할 수 없는 LAN에 있는 서버 B에 frpc 바이너리와 클라이언트 구성 파일을 배치하세요.
일부 백신 프로그램은 frpc를 악성코드로 잘못 표시하여 삭제합니다. 이는 frp가 역방향 프록시를 생성할 수 있는 네트워킹 도구이기 때문입니다. 백신 프로그램은 방화벽 포트 제한을 우회할 수 있는 능력 때문에 역방향 프록시를 플래그 처리하는 경우가 있습니다. 백신을 사용 중이라면 우발적인 격리/삭제를 방지하기 위해 백신 설정에서 frpc를 허용 목록/제외 목록에 추가해야 할 수 있습니다. 자세한 내용은 issue 3637을 참조하세요.
frps.toml을 수정하여 frp 클라이언트가 연결할 bindPort를 설정합니다: ```tomlbindPort = 7000
2. 서버 A에서 `frps`를 시작합니다:
`./frps -c ./frps.toml`
3. 서버 B에서 `frpc.toml`을 수정하고 `serverAddr` 필드를 frps 서버의 공용 IP 주소로 설정합니다: ```toml
# frpc.toml
serverAddr = "x.x.x.x"
serverPort = 7000
[[proxies]]
name = "ssh"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 6000
참고로 localPort(클라이언트에서 수신)와 remotePort(서버에서 노출)는 frp 시스템을 오가는 트래픽에 사용되며, serverPort는 frps와 frpc 간의 통신에 사용됩니다.
frpc를 시작합니다:./frpc -c ./frpc.toml
test라고 가정), 다음 명령어를 사용합니다:ssh -oPort=6000 [email protected]
이 예제는 tcpmux 유형의 프록시를 사용하여 동일한 포트를 통해 여러 SSH 서비스를 노출합니다. 마찬가지로, 클라이언트가 HTTP Connect 프록시 연결 방식을 지원하기만 하면 이 방식으로 포트 재사용을 달성할 수 있습니다.
2. 내부 머신 A에 다음 구성으로 frpc를 배포합니다: ```toml
serverAddr = "x.x.x.x"
serverPort = 7000