IPC ko KR

IPC

ASF는 유일한 자체 IPC 인터페이스를 가지고 있으며, 이로 인해 프로세스와 더 상호작용할 수 있습니다. IPC는 **프로세스 간 통신(inter-process communication)**의 약자이며, 가장 단순하게 정의하면 Kestrel HTTP 서버 기반의 "ASF 웹 인터페이스"로, 최종 사용자를 위한 프런트엔드(ASF-ui)와 제3자 연동을 위한 백엔드(ASF API) 양쪽 모두로 프로세스와 추가로 연동하는 데 사용될 수 있습니다.

IPC는 우리의 필요와 능력에 따라 수많은 다른 것들로 사용될 수 있습니다. 예를 들어, ASF와 모든 봇의 상태를 가져오고, ASF에 명령어를 보내고, 일반/봇 환경설정을 가져와서 수정하고, 새로운 봇을 추가하고, 기존의 봇을 삭제하고, 백그라운드 게임 등록기 에 키를 보내고, ASF의 로그파일에 접근할 수 있습니다. 이 모든 작업은 API로 제공됩니다. 즉, 당신이 자신의 도구와 스크립트를 짜서 ASF 실행중에 ASF와 통신하고 영향을 미칠수 있다는 뜻입니다. 추가로, 명령어 전송같은 선택된 작업은 ASF-ui에 구현되어 있으며 친숙한 웹 인터페이스로 쉽게 접근할 수 있습니다.

---

사용법

IPC **전역 설정 속성**을 통해 수동으로 비활성화하지 않는 한, IPC는 기본적으로 활성화되어 있습니다. ASF는 IPC의 실행을 로그에서 표시하여 IPC 인터페이스가 제대로 시작되었는지 확인할 수 있습니다.

INFO|ASF|Start() Starting IPC server...
INFO|ASF|Start() IPC server ready!

ASF의 http 서버가 이제 선택한 단말에서 수신중입니다. IPC용 커스텀 설정 파일을 제공하지 않은 경우, 기본 1242 포트에서 IPv4 기반 **127.0.0.1**과 IPv6 기반 [::1] 모두를 포함하는 localhost가 사용됩니다. 위 링크를 통해 IPC 인터페이스에 접근할 수 있지만, ASF 프로세스가 실행 중인 기기에서만 가능합니다.

ASF의 IPC 인터페이스는 사용계획에 따라 세가지의 다른 접근방법을 제공합니다.

가장 낮은 단계로 IPC 인터페이스의 핵심이며 다른 모든 것이 동작하도록 하는 ASF API 가 있습니다. 자신만의 도구나 유틸리티, 프로젝트에서 ASF와 직접적으로 통신하기 위해 이를 사용해야 합니다.

중간 단계로 ASF API의 프론트엔드 역할을 하는 Swagger documentation 이 있습니다. 이것은 ASF API의 완전한 문서를 제공하고 더 쉽게 접근할 수 있게 해줍니다. 만약 API를 통해 ASF와 통신하려는 도구, 유틸리티 혹은 다른 프로젝트를 작성하려면 Swagger 문서를 확인해보는 것이 좋습니다.

가장 높은 단계로 ASF API에 기반한 ASF-ui 가 있으며, ASF 작업을 수행가능한 사용자 친화적인 방법을 제공합니다. 이것은 최종사용자를 위한 기본 IPC 인터페이스이며, ASF API로 만들수 있는 완벽한 예제입니다. 원한다면 --path 명령줄 인자 를 지정하고, 그곳에 위치한 사용자 지정 www 디렉토리를 사용하여 자신만의 사용자 지정 웹 UI를 사용할 수도 있습니다.

---

ASF-ui

ASF-ui는 최종사용자에게 사용자 친화적인 그래픽 웹 인터페이스를 만들어주는 것을 목표로 하는 커뮤니티 프로젝트입니다. 이를 달성하기 위해 ASF API 의 프론트엔드로 동작하여 사용자가 다양한 작업을 쉽게 할 수 있습니다. 이것은 ASF와 함께 제공되는 기본 UI 입니다.

위에서 설명했듯이 ASF-ui는 ASF 핵심 개발자들이 유지관리하지 않는 커뮤니티 프로젝트입니다. ASF-ui 리포 에 있는 자체 흐름을 따라가며, 이곳에서 모든 관련된 질문, 이슈, 버그 보고 및 제안이 이루어집니다.

ASF 프로세스의 일반적인 관리를 위해 ASF-ui를 사용할 수 있습니다. 예를 들어 봇 관리, 설정 변경, 명령어 전송, 그리고 평소 ASF를 통해 사용 가능한 그 외 일부 기능을 수행할 수 있습니다.

---

ASF API

ASF API는 기본 데이터 형식인 JSON에 기반한 전형적인 REST 원리를 따르는 웹 API 입니다. 위리는 HTTP 상태코드(해당하는 경우)와, 직접 파싱해서 요청이 성공했는지 혹은 왜 실패했는지를 알 수 있는 응답을 모두 사용하여 응답을 정확하게 설명하기 위해 최선을 다하고 있습니다.

ASF API는 적절한 /Api 단말에 적절한 요청을 보내서 접근이 가능합니다. 이 API 단말을 사용해서 자신만의 도우미 스크립트, 도구, GUI 등등을 만들수 있습니다. 이것이 바로 ASF-ui의 비결이고, 다른 모든 도구도 동일합니다. ASF API는 공식적으로 지원되며 ASF 핵심 팀이 유지관리합니다.

이용가능한 단말, 설명, 요청, 응답, http 상태코드와 ASF API에 대한 다른 모든 것에 대한 완전한 문서는**swagger 문서**를 참고하시기 바랍니다.

---

사용자 지정 환경설정

IPC 인터페이스는 추가 환경설정 파일을 지원합니다.IPC.config 파일을 표준 ASF config 디렉토리에 넣으십시오.

사용가능한 경우 이 파일은 ASF Kestrel http 서버의 고급 환경설정과 다른 IPC 관련 조정사항을 정의합니다. 특정한 필요가 없다면 이 파일을 사용할 이유는 없습니다. ASF는 이 경우 합리적인 기본값을 사용합니다.

환경설정 파일은 다음의 JSON 구조를 기반으로 합니다.

{
    "Kestrel": {
        "Endpoints": {
            "example-http4": {
                "Url": "http://127.0.0.1:1242"
            },

            "example-http6": {
                "Url": "http://[::1]:1242"
            },

            "example-https4": {
                "Url": "https://127.0.0.1:1242",

                "Certificate": {
                    "Path": "/path/to/certificate.pfx",
                    "Password": "passwordToPfxFileAbove"
                }
            },

            "example-https6": {
                "Url": "https://[::1]:1242",

                "Certificate": {
                    "Path": "/path/to/certificate.pfx",
                    "Password": "passwordToPfxFileAbove"
                }
            },

            "example-unix-socket": {
                "Url": "http://unix:/run/asf-asf/asf.sock"
            }
        },

        "KnownNetworks": [
            "10.0.0.0/8",
            "172.16.0.0/12",
            "192.168.0.0/16"
        ],

        "PathBase": "/"
    }
}

Endpoints - 이것은 단말의 집합입니다. 모든 단말은 example-http4와 같은 유일한 이름을 가지고 있어야 하며, Url 속성값은 Protocol://Host:Port 수신주소를 특정합니다. 기본적으로 ASF는 IPv4와 IPv6 http 주소를 수신하지만, 필요할지 몰라 사용할 수 있는 https 예시를 추가해 두었습니다. 필요한 엔드포인트만 선언해야 하며, 더 쉽게 편집할 수 있도록 위에 몇 가지 예시를 포함해두었습니다.

Host에는 localhost, 수신 대기할 인터페이스의 고정 IP 주소(IPv4/IPv6), 또는 ASF의 http 서버를 사용 가능한 모든 인터페이스에 바인딩하는 * 값을 사용할 수 있습니다. mydomain.com이나 192.168.0.*와 같은 다른 값을 사용해도 ``와 동일하게 작동하며, IP 필터링은 구현되어 있지 않습니다. 따라서 원격 접근을 허용하는 Host 값을 사용할 때는 각별히 주의해야 합니다. 그렇게 하면 ASF IPC 인터페이스는 다른 기기에서의 접근을 허용하고, 보안 위험이 될 수 있습니다. 이 경우 최소한 `IPCPassword`, 그리고 방화벽의 사용을 강력하게 권장합니다.

KnownNetworks - 신뢰할 수 있다고 간주하는 네트워크 주소를 지정하는 선택적 변수입니다. 기본적으로 ASF는 오직 루프백 인터페이스(localhost, 동일한 기기)를 신뢰하도록 설정되어 있습니다. 이 속성은 두 가지 방식으로 사용됩니다. 첫째, IPCPassword를 생략하는 경우, 보안 조치로서 알려진(신뢰하는) 네트워크의 기기만 ASF API에 접근할 수 있도록 허용하고 그 외 모든 접근은 거부합니다. 둘째, 이 속성은 ASF에 접근하는 리버스 프록시와 관련해 매우 중요합니다. ASF는 리버스 프록시 서버가 알려진(신뢰하는) 네트워크 내에 있는 경우에만 해당 헤더를 신뢰하기 때문입니다. 헤더를 신뢰하는 것은 ASF의 무차별 대입 공격 방지 메커니즘과 관련해 매우 중요합니다. 문제가 발생했을 때 리버스 프록시 자체를 차단하는 대신, 리버스 프록시가 원본 메시지의 출처로 지정한 IP를 차단하기 때문입니다. 신뢰하는 기기가 침해당하거나 잘못 설정된 경우 잠재적인 IP 스푸핑 공격 및 무단 접근이 가능해지므로, 여기서 지정하는 네트워크에는 각별히 주의해야 합니다.

PathBase - IPC 인터페이스에서 사용될 선택적 기본 경로입니다. 기본값은 /이며, 대부분의 사용 사례에서는 수정할 필요가 없습니다. 이 속성값을 변경하면 전체 IPC 인터페이스를 사용자 지정 접두사에서 호스팅하게 됩니다. 예를 들어 http://localhost:1242 가 아니라 http://localhost:1242/MyPrefix 가 됩니다. 사용자 지정 PathBase 는 특정한 URL만 프록시하기 원하는 역방향 프록시의 특정 설치와의 조합으로 사용할 수 있습니다. 예를 들어 전체 mydomain.com 도메인이 아닌mydomain.com/ASF 를 사용할 수 있습니다. 일반적으로는 mydomain.com/ASF/Api/X를 localhost:1242/Api/X로 매핑하는 rewrite 규칙을 웹 서버에 작성해야 하지만, 대신 커스텀 PathBase를 /ASF로 지정하면 mydomain.com/ASF/Api/X를 localhost:1242/ASF/Api/X로 더 간편하게 설정할 수 있습니다.

당신이 사용자 지정 기본 경로를 지정할 필요가 있다고 진심으로 믿지 않는 한, 기본값으로 두는 것이 최선입니다.

예시 config

기본 포트 변경

다음 config는 ASF의 기본 수신 대기 포트를 1242에서 1337로 단순히 변경합니다. 원하는 포트를 자유롭게 선택할 수 있지만, 1024-32767 범위를 권장합니다. 그 외의 포트는 일반적으로 등록된(registered) 포트라서, 예를 들어 Linux에서는 root 권한이 필요할 수 있습니다.

{
    "Kestrel": {
        "Endpoints": {
            "HTTP4": {
                "Url": "http://127.0.0.1:1337"
            },

            "HTTP6": {
                "Url": "http://[::1]:1337"
            }
        }
    }
}

---

모든 IP에서의 접근 허용

다음 config는 모든 소스로부터의 원격 접근을 허용하므로, 위에서 제공한 이에 관한 보안 안내를 반드시 읽고 이해했는지 확인해야 합니다.

{
    "Kestrel": {
        "Endpoints": {
            "HTTP": {
                "Url": "http://*:1242"
            }
        }
    }
}

모든 출처에서의 접근이 필요하지 않고 (예: LAN 내에서만 접근하는 경우), ASF를 호스팅하는 기기의 로컬 IP 주소(예: 192.168.0.10)를 확인하여 위 예시 설정의 * 대신 사용하는 것이 훨씬 좋습니다. 아쉽게도 이는 LAN 주소가 항상 고정되어 있는 경우에만 가능합니다. 그렇지 않다면 로컬 서브넷만 ASF 포트에 접근하도록 방화벽을 직접 설정하고, *를 사용하는 편이 대체로 더 나은 결과를 얻을 수 있습니다.

---

TCP 대신 유닉스 소켓 사용

유닉스 소켓은 Windows가 아닌 플랫폼에서 지원됩니다. asf 사용자로 저희 **systemd 서비스**를 사용 중이라면 아래 내용이 별도 설정 없이 바로 작동합니다. 그렇지 않다면, 필요에 맞게 경로를 조정하세요.

{
    "Kestrel": {
        "Endpoints": {
            "Unix": {
                "Url": "http://unix:/run/asf-asf/asf.sock"
            }
        }
    }
}

ASF에는 유닉스 소켓 생성 시 권한을 chmod를 통해 0666으로 자동 변경하는 커스텀 로직이 포함되어 있습니다. 혹시 이것이 원치 않는 경우라면, 대신 소켓의 하위 폴더 권한을 수정할 것을 권장합니다. 예를 들어 [Service] 아래 **systemd override**에서 RuntimeDirectoryMode=0700을 사용하면 됩니다.

유닉스 소켓은 이러한 유형의 통신을 지원하는 특정 소프트웨어에서 표준 TCP 소켓의 대안으로 사용할 수 있으며, 예를 들어 다양한 리버스 프록시 메커니즘의 업스트림 서버로 활용될 수 있습니다.

---

인증

ASF IPC 인터페이스는 기본적으로 IPCPassword가 null로 설정되어 있으므로 어떠한 종류의 인증도 요구하지 않습니다. 하지만 IPCPassword가 빈 값이 아닌것으로 설정되어 활성화되면, 모든 ASF API 호출은 IPCPassword에 맞는 암호를 요구할 것입니다. 인증을 생략하거나 잘못된 암호를 입력하면 401 - Unauthorized 오류가 발생합니다. 인증에 5번 실패하면(잘못된 비밀번호), 403 - Forbidden 오류와 함께 일시적으로 차단됩니다.

인증은 두가지 다른 방법으로 가능합니다.

Authentication 헤더

일반적으로 Authentication 필드에 비밀번호를 값으로 설정하여 **HTTP 요청 헤더**를 사용해야 합니다. 이 방법은 ASF IPC 인터페이스에 접근하는 실제 도구에 따라 다릅니다. 예를 들어 curl을 사용한다면 -H 'Authentication: MyPassword' 를 인자로 넣어야 합니다. 이 방법으로 실제 인증이 일어나야 하는 요청의 헤더 부분에서 인증이 통과됩니다.

쿼리문 내의 password 매개변수

또는 password 매개변수를 호출하려는 URL의 마지막에 추가할 수도 있습니다. 예를 들어 /Api/ASF 대신에 /Api/ASF?password=MyPassword로 호출합니다. 이 접근방법도 충분히 좋지만 명백하게 암호를 열린 곳에 노출하므로 항상 적절하지는 않습니다. 게다가 쿼리문의 추가 인수이므로 URL이 복잡해보이고, 암호가 ASF API 통신 전체에 적용되는데도 마치 그 URL 전용인 것 같은 느낌을 줍니다.

---

두 방법 모두 지원되며 어느 것을 사용할지는 당신의 선택입니다. 우리는 가능한 모든 곳에 HTTP 헤더를 사용할 것을 권장합니다. 예를 들었듯이 HTTP 헤더가 쿼리문보다 더 적합합니다. 하지만 헤더 요청과 관련된 다양한 제한이 있기 때문에 우리는 쿼리문도 지원을 합니다. RFC에 따르면 완전히 유효합니다만, 자바스크립트에서 웹소켓 연결 시작시 사용자 지정 헤더의 부재는 좋은 예시 입니다. 이 경우 쿼리문은 유일한 인증방법입니다.

---

Swagger 문서

IPC 인터페이스에는 ASF API, ASF-ui와 더불어 swagger 문서가 있으며 /swagger URL 로 접근이 가능합니다. Swagger 문서는 API 구현과 이를 사용하는 ASF-ui 등 다른 도구간의 중간다리 역할을 합니다. 이것은 OpenAPI 사양의 모든 API 단말의 완전한 문서이며 가능성입니다. 다른 프로젝트는 이를 쉽게 소비할 수 있으며 ASF API를 쉽게 작성하고 테스트할 수 있습니다.

Swagger 문서를 ASF API의 완전한 사양으로 사용하는 것과 별개로 주로 ASF-ui에 구현되지 않은 다양한 API 단말을 실행하는 사용자 친화적인 방법으로 사용할 수도 있습니다. Swagger 문서는 ASF 코드에서 자동으로 생성되므로 사용중인 ASF가 포함하는 API 단말과 문서가 항상 최신임을 보장합니다.

---

자주 묻는 질문(FAQ)

ASF IPC 인터페이스는 안전합니까?

ASF는 기본적으로 localhost 주소를 수신합니다. 즉 당신 자신의 기기가 아닌 다른 기기는 ASF IPC에 접속하는 것은 불가능합니다. 당신이 기본 단말을 변경하지 않는 한, 공격자는 ASF IPC에 접근하려면 당신의 기기에 직접접근할 필요가 있습니다. 따라서 가장 안전하며 LAN에 접속된 이를 포함한 다른 누군가의 접근 가능성은 없습니다.

하지만 기본 localhost 할당 주소를 다른 무언가로 바꾸기로 했다면 공인된 IP만 ASF IPC 인터페이스에 접근하도록 적절한 방화벽 규칙을직접 설정해야 합니다. 이와 함께 IPCPassword도 설정해야 합니다. ASF는 비밀번호가 없으면 다른 기기가 ASF API에 접근하는 것을 거부하며, 이는 추가적인 보안 계층을 더해줍니다. 이 경우 ASF IPC 인터페이스를 역방향 프록시 뒤에서 실행하고 싶을수도 있습니다. 이는 아래에서 추가로 설명합니다.

내 자신의 도구나 사용자스크립트로 ASF API에 접근할 수 있습니까?

예. 이것은 ASF API가 설계된 이유이며 접근을 위한 HTTP 요청을 보내는 것으로 무엇이든 할 수 있습니다. 로컬 사용자스크립트는 교차 출처 리소스 공유(CORS, Cross-origin resource sharing) 논리 구조를 따르므로, 추가 보안 조치로 IPCPassword가 설정되어 있다면 우리는 이를 위해 모든 곳(*)에서의 접근을 허용합니다. 이렇게 해서 잠재적으로 악의적인 스크립트가 자동으로 요청을 실행하는 것을 막으면서 다양한 인증받은 ASF API 요청을 실행할수 있습니다.(악의적인 스크립트는 요청 실행을 위해 IPCPassword를 알아야만 합니다.)

다른 기기 등에서 원격으로 ASF IPC에 접근할 수 있습니까?

네, 이를 위해 리버스 프록시를 사용할 것을 권장합니다. 이렇게 해서 웹서버에 전형적인 방법으로 접근할 수 있고 ASF IPC를 동일한 기기에서 접근할 수 있습니다. 다른 방법으로, 리버스 프록시 없이 운영하고 싶다면 적절한 URL로 **커스텀 설정**을 사용할 수 있습니다. 예를 들어, 기기가 10.8.0.1 주소를 가진 VPN 내에 있다면, IPC config에서 수신 대기 URL을 http://10.8.0.1:1242로 설정할 수 있으며, 이 경우 개인 VPN 내에서만 IPC 접근이 가능해지고 그 외의 곳에서는 접근할 수 없게 됩니다.

ASF IPC를 Apache나 Nginx 같은 역방향 프록시 뒤에서 사용할 수 있습니까?

예. IPC는 그런 설치와 완전히 호환되므로 원한다면 추가 보안과 호환성을 위해 당신의 도구 앞에서 호스팅해도 좋습니다. 일반적으로 ASF의 Kestrel http 서버는 인터넷에 직접 연결되었을 때 매우 안전하고 위험이 없습니다. 하지만 Apache나 Nginx 같은 역방향 프록시 뒤에 놓으면 다른 방법으로는 할 수 없는 추가 기능들, 예를 들면 ASF 인터페이스를 기초 인증(Basic auth) 으로 안전하게 하는 것 같은 기능들을 제공할지도 모릅니다.

Nginx 환경설정의 예시는 아래에 있습니다. 완전하고 완결된, 그러면서도 최소한으로 구성된 정의를 포함해두었습니다. 더 자세한 설명이 필요하면 nginx 문서(영문) 를 참고하십시오.

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

upstream asf-server {
    # You can also use unix socket if you've enabled it, e.g. unix:/run/asf-asf/asf.sock
    server 127.0.0.1:1242;
}

server {
    listen *:443 ssl;

    ssl_certificate /path/to/your/fullchain.pem;
    ssl_certificate_key /path/to/your/privkey.pem;
    ssl_trusted_certificate /path/to/your/chain.pem;

    server_name asf.mydomain.com;

    location ~* /Api/NLog {
        proxy_pass http://asf-server;

        # X-headers should always be specified when proxying requests to ASF
        # They're crucial for proper identification of original IP, allowing ASF to e.g. ban the actual offenders instead of your nginx server
        # Specifying them allows ASF to properly resolve IP addresses of users making requests - making nginx work as a reverse proxy
        # Not specifying them will cause ASF to treat your nginx as the client - nginx will act as a traditional proxy in this case
        # If you're unable to host nginx service on the same machine as ASF, you most likely want to set KnownNetworks appropriately in addition to those
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;

        # We add those 3 extra options for websockets proxying, see https://nginx.org/en/docs/http/websocket.html
        proxy_http_version 1.1;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Upgrade $http_upgrade;
    }

    location / {
        proxy_pass http://asf-server;

        # X-headers should always be specified when proxying requests to ASF
        # They're crucial for proper identification of original IP, allowing ASF to e.g. ban the actual offenders instead of your nginx server
        # Specifying them allows ASF to properly resolve IP addresses of users making requests - making nginx work as a reverse proxy
        # Not specifying them will cause ASF to treat your nginx as the client - nginx will act as a traditional proxy in this case
        # If you're unable to host nginx service on the same machine as ASF, you most likely want to set KnownNetworks appropriately in addition to those
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

다음은 아파치 환경설정의 예시입니다. 더 자세한 설명이 필요하다면 **Apache 문서**를 참고하세요.

<IfModule mod_ssl.c>
    <VirtualHost *:443>
        SSLEngine On
        SSLCertificateFile /path/to/your/fullchain.pem
        SSLCertificateKeyFile /path/to/your/privkey.pem

        ServerName asf.mydomain.com

        # TODO: Apache can't do case-insensitive matching properly, so we hardcode two most commonly used cases
        # You can also use unix socket if you've enabled it, e.g. unix:/run/asf-asf/asf.sock|ws://localhost/
        ProxyPass "/api/nlog" "ws://127.0.0.1:1242/api/nlog"
        ProxyPass "/Api/NLog" "ws://127.0.0.1:1242/Api/NLog"

        # You can also use unix socket if you've enabled it, e.g. unix:/run/asf-asf/asf.sock|http://localhost/
        ProxyPass "/" "http://127.0.0.1:1242/"
    </VirtualHost>
</IfModule>

HTTPS 프로토콜로 IPC 인터페이스에 접근할 수 있습니까?

네, 두 가지 방법으로 이를 구현할 수 있습니다. 권장하는 방법은 리버스 프록시를 사용하는 것입니다. 이 경우 평소처럼 https로 웹 서버에 접근하고, 이를 통해 같은 기기의 ASF IPC 인터페이스와 연결할 수 있습니다. 이 방법은 트래픽이 완전히 암호화되므로 이런 설치를 위해 IPC를 어떤 방식으로든 수정할 필요가 없습니다.

두 번째 방법은 ASF의 IPC 인터페이스에 **커스텀 config**를 지정하여, https 엔드포인트를 활성화하고 저희 Kestrel http 서버에 적절한 인증서를 직접 제공하는 것입니다. 이 방법은 다른 웹서버를 실행하지 않고 있으며 오직 ASF를 위해서 웹서버를 추가로 실행하고 싶지 않은 경우 추천합니다. 그렇지 않으면 역방향 프록시 구조를 사용하는 것이 설치하는데 훨씬 쉬울 것입니다.

---

IPC 시작 중에 다음과 같은 오류가 발생합니다: System.IO.IOException: Failed to bind to address, An attempt was made to access a socket in a way forbidden by its access permissions

이 오류는 기기의 다른 무언가가 이미 해당 포트를 사용 중이거나, 향후 사용을 위해 예약해둔 상태임을 나타냅니다. 같은 기기에서 두 번째 ASF 인스턴스를 실행하려는 경우 본인이 원인일 수도 있지만, 가장 흔한 경우는 Windows가 1242 포트를 사용하지 못하도록 제외해둔 것이므로, 이 경우 ASF를 다른 포트로 옮겨야 합니다. 이를 위해 위의 **예시 config**를 따라, 12420과 같은 다른 포트를 간단히 선택해보세요.

물론 무엇이 ASF의 1242 포트 사용을 막고 있는지 찾아내어 제거하는 방법도 시도해볼 수 있지만, 이는 대체로 ASF에 다른 포트를 사용하도록 지시하는 것보다 훨씬 번거로우므로 여기서는 더 자세히 다루지 않겠습니다.

---

IPCPassword를 사용하지 않을 때 왜 403 Forbidden 오류가 발생하나요?

ASF에는 추가적인 보안 조치가 포함되어 있어, config에 IPCPassword가 설정되지 않은 경우 기본적으로 루프백 인터페이스(localhost, 본인의 기기)에서만 ASF API에 접근할 수 있습니다. 이는 ASF 인터페이스를 외부로 더 노출시키기로 한 사람이라면 누구나 IPCPassword 사용을 최소한의 보안 조치로 설정해야 하기 때문입니다.

이 변경은 전 세계적으로 이를 인지하지 못한 사용자들이 호스팅하던 대량의 ASF가 악의적인 목적으로 탈취당하는 사례가 많았고, 이로 인해 대부분 계정과 아이템을 잃게 되었다는 사실에 따른 것입니다. "ASF를 외부 전체에 개방하기 전에 이 페이지를 미리 읽었으면 좋았을 텐데"라고 말할 수도 있겠지만, 그보다는 기본적으로 안전하지 않은 ASF 설정을 비활성화하고 사용자가 명시적으로 이를 허용하려는 경우에만 직접 추가 조치를 취하도록 하는 것이 더 합리적입니다. 이에 대해서는 아래에서 자세히 설명합니다.

구체적으로는, IPCPassword 없이도 ASF에 접근할 수 있도록 신뢰하는 네트워크를 지정함으로써 저희의 이 기본 정책을 재정의할 수 있습니다. 이는 커스텀 설정(config)의 KnownNetworks 속성에서 설정할 수 있습니다. 다만, 정말로 무엇을 하는지 알고 위험을 완전히 이해하고 있는 경우가 아니라면, 대신 IPCPassword를 사용해야 합니다. KnownNetworks를 지정하면 해당 네트워크에 속한 누구든 조건 없이 ASF API에 접근할 수 있게 되기 때문입니다. 정말 진지하게 드리는 말씀입니다. 실제로 많은 사람들이 자신의 리버스 프록시나 iptables 규칙이 안전하다고 믿었지만 실제로는 그렇지 않아서 스스로 문제를 자초한 사례가 있었습니다. IPCPassword는 첫 번째 방어선이자 때로는 마지막 방어선입니다. 이 간단하면서도 매우 효과적이고 안전한 메커니즘을 사용하지 않기로 한다면, 그로 인한 결과는 전적으로 본인의 책임입니다.