Microsoft MVP성태의 닷넷 이야기
글쓴 사람
홈페이지
첨부 파일
 

로컬 PC에서 개발 중인 ASP.NET Core 웹 응용 프로그램을 다른 PC에서도 접근하는 방법

다음의 글에 자세한 방법이 소개되어 있습니다.

External Network Access to Kestrel and IIS Express in ASP.NET Core
; https://weblog.west-wind.com/posts/2016/sep/28/external-network-access-to-kestrel-and-iis-express-in-aspnet-core

ACCESSING AN ASP .NET CORE WEB APPLICATION REMOTELY
; https://gigi.nullneuron.net/gigilabs/accessing-an-asp-net-core-web-application-remotely/

정리해 보면 dotnet으로 웹 애플리케이션을 실행하면 다음과 같은 식의 메시지가 출력되는데,

$ dotnet /home/tusr/core3web/Core3Web.dll
info: Microsoft.Hosting.Lifetime[0]
      Now listening on: http://localhost:5000
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Production
info: Microsoft.Hosting.Lifetime[0]
      Content root path: /home/tusr/core3web

저렇게 "localhost:5000"으로 메시지가 나오면 해당 웹 애플리케이션은 외부에서 접근할 수 없습니다. 이를 해제하기 위해서는 간단하게 다음과 같이 ListenAnyIP 메서드를 호출하면 됩니다.

Endpoint configuration
; https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#endpoint-configuration

public class Program
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
                webBuilder.ConfigureKestrel(serverOptions =>
                {
                    serverOptions.ListenAnyIP(6000);
                });
            });
}

위와 같이 처리해 주면 이제 메시지가 다음과 같이 변경됩니다.

# dotnet /home/tusr/core3web/Core3Web.dll
info: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[0]
      User profile is available. Using '/home/tusr/.aspnet/DataProtection-Keys' as key repository; keys will not be encrypted at rest.
info: Microsoft.Hosting.Lifetime[0]
      Now listening on: http://[::]:6000
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Production
info: Microsoft.Hosting.Lifetime[0]
      Content root path: /home/tusr/core3web

혹은, netstat로 바인딩이 모든 IP로 된 것을 확인하는 것도 가능합니다.

$ netstat -ano | grep 6000
tcp6       0      0 :::6000                 :::*                    LISTEN      off (0.00/0/0)




이제 방화벽만 없다면 외부 PC에서 해당 포트로 접근하는 것이 가능합니다. 참고로, Centos 7의 경우,

RHEL/CentOS 7 에서 방화벽(firewalld) 설정하기
; https://www.lesstif.com/pages/viewpage.action?pageId=22053128

다음과 같이 활성화된 방화벽 영역을 확인할 수 있고,

# firewall-cmd --get-active-zone
public
  interfaces: eth0

# firewall-cmd --get-default-zone
public

해당 영역에 설정된 제약들을 이렇게 볼 수 있습니다.

# firewall-cmd --info-zone=public
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources: 
  services: ssh dhcpv6-client samba
  ports: 5000/tcp
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

보는 바와 같이 현재 "services" 관련해서 "ssh", "dhcpv6-client", "samba"와 연관된 서비스들이 외부로 노출되어 있으며, "ports" 설정을 통해 명시적으로 "5000/tcp"만을 접근이 가능합니다. 따라서, 이 글에서 예제로 들고 있는 6000번 포트의 웹 애플리케이션을 접근하도록 만들고 싶다면 다음과 같이 명령을 내리면 됩니다.

# firewall-cmd --permanent --zone=public --add-port=6000/tcp
# firewall-cmd --reload




아니... 그런데 이게 웬일입니까? 여전히 "http://...:6000"으로는 접근이 안 됩니다. 그렇긴 한데, Chome 웹 브라우저의 메시지에 좀 이상한 면이 있습니다.

Chrome, Edge
Hmmm… can't reach this pageIt looks like the webpage at http://test_centos:6000/ might be having issues, or it may have moved permanently to a new web address.
ERR_UNSAFE_PORT

"ERR_UNSAFE_PORT"라고 나오는데, 사실 웹 사이트를 정상(?)적으로 접근을 못했다면 원래는 다음과 같은 식으로 나와야 했습니다.

test_centos took too long to respond
ERR_CONNECTION_TIMED_OUT

검색해 보면 ^^; Chrome은 보안을 위해 기본적으로 막아두는 포트가 있다고 합니다.

Which ports are considered unsafe by Chrome?
; https://superuser.com/questions/188058/which-ports-are-considered-unsafe-by-chrome

1,       // tcpmux
7,       // echo
9,       // discard
11,      // systat
13,      // daytime
15,      // netstat
17,      // qotd
19,      // chargen
20,      // ftp data
21,      // ftp access
22,      // ssh
23,      // telnet
25,      // smtp
37,      // time
42,      // name
43,      // nicname
53,      // domain
77,      // priv-rjs
79,      // finger
87,      // ttylink
95,      // supdup
101,     // hostriame
102,     // iso-tsap
103,     // gppitnp
104,     // acr-nema
109,     // pop2
110,     // pop3
111,     // sunrpc
113,     // auth
115,     // sftp
117,     // uucp-path
119,     // nntp
123,     // NTP
135,     // loc-srv /epmap
139,     // netbios
143,     // imap2
179,     // BGP
389,     // ldap
427,     // SLP (Also used by Apple Filing Protocol)
465,     // smtp+ssl
512,     // print / exec
513,     // login
514,     // shell
515,     // printer
526,     // tempo
530,     // courier
531,     // chat
532,     // netnews
540,     // uucp
548,     // AFP (Apple Filing Protocol)
556,     // remotefs
563,     // nntp+ssl
587,     // stmp?
601,     // ??
636,     // ldap+ssl
993,     // ldap+ssl
995,     // pop3+ssl
2049,    // nfs
3659,    // apple-sasl / PasswordServer
4045,    // lockd
6000,    // X11
6665,    // Alternate IRC [Apple addition]
6666,    // Alternate IRC [Apple addition]
6667,    // Standard IRC [Apple addition]
6668,    // Alternate IRC [Apple addition]
6669,    // Alternate IRC [Apple addition]
6697,    // IRC + TLS

재수(?) 좋게 제가 저 포트 목록에 있는 6000번을 ASP.NET Core 웹 애플리케이션에 사용했던 것입니다. 물론, chrome 브라우저에는 이 설정을 비활성화시키는 옵션이 있습니다.

Fix ERR_UNSAFE_PORT error on Google Chrome on Windows 10
; https://www.thewindowsclub.com/err_unsafe_port-error-on-google-chrome

이를 위해 일단 현재 실행 중인 "chrome.exe"의 전체 경로를 작업 관리자 등을 통해 알아내고,

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"

실행 중인 모든 chrome 인스턴스를 종료한 다음 완전히 새롭게 명령행에서 다음과 같은 식으로 실행해 주면 됩니다.

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --explicitly-allowed-ports=6000

해보시면 알겠지만, 이는 매우 번거로운 작업이기 때문에 ^^ 차라리 그냥 포트 번호를 바꾸는 것이 더 속 편할 것입니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]





[최초 등록일: ]
[최종 수정일: 12/17/2019 ]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer@outlook.com

비밀번호

댓글 쓴 사람
 




1  2  3  4  5  [6]  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12079정성태12/13/2019354오류 유형: 584. 원격 데스크탑(rdp) 환경에서 다중 또는 고용량 파일 복사 시 "Unspecified error" 오류 발생
12078정성태12/13/2019606Linux: 26. .NET Core 응용 프로그램을 위한 메모리 덤프 방법 [1]
12077정성태12/13/2019386Linux: 25. 자주 실행할 명령어 또는 초기 환경을 "~/.bashrc" 파일에 등록
12076정성태12/17/2019536디버깅 기술: 142. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅 - 배포 방법에 따른 차이
12075정성태12/18/2019566디버깅 기술: 141. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅
12074정성태12/11/2019381디버깅 기술: 140. windbg/Visual Studio - 값이 변경된 경우를 위한 정지점(BP) 설정(Data Breakpoint)
12073정성태12/10/2019599Linux: 24. Linux/C# - 실행 파일이 아닌 스크립트 형식의 명령어를 Process.Start로 실행하는 방법
12072정성태12/9/2019289오류 유형: 583. iisreset 수행 시 "No such interface supported" 오류
12071정성태12/9/2019367오류 유형: 582. 리눅스 디스크 공간 부족 및 safemode 부팅 방법
12070정성태12/9/2019471오류 유형: 581. resize2fs: Bad magic number in super-block while trying to open /dev/.../root
12069정성태12/19/2019584디버깅 기술: 139. windbg - x64 덤프 분석 시 메서드의 인자 또는 로컬 변수의 값을 확인하는 방법
12068정성태11/28/2019772디버깅 기술: 138. windbg와 Win32 API로 알아보는 Windows Heap 정보 분석 [2]파일 다운로드2
12067정성태11/27/2019578디버깅 기술: 137. 실제 사례를 통해 Debug Diagnostics 도구가 생성한 닷넷 웹 응용 프로그램의 성능 장애 보고서 설명 [1]파일 다운로드1
12066정성태11/27/2019403디버깅 기술: 136. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석 - OracleCommand.ExecuteReader에서 OpsSql.Prepare2 PInvoke 호출 분석
12065정성태11/25/2019428디버깅 기술: 135. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석파일 다운로드1
12064정성태11/25/2019700오류 유형: 580. HTTP Error 500.0/500.33 - ANCM In-Process Handler Load Failure
12063정성태11/21/2019465디버깅 기술: 134. windbg - RtlReportCriticalFailure로부터 parameters 정보 찾는 방법
12062정성태12/20/2019389디버깅 기술: 133. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례 - 두 번째 이야기
12061정성태11/20/2019419Windows: 165. CoTaskMemAlloc/CoTaskMemFree과 윈도우 Heap의 관계
12060정성태11/21/2019475디버깅 기술: 132. windbg/Visual Studio - HeapFree x64의 동작 분석
12059정성태11/20/2019446디버깅 기술: 131. windbg/Visual Studio - HeapFree x86의 동작 분석
12058정성태11/19/2019456디버깅 기술: 130. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례
12057정성태11/18/2019328오류 유형: 579. Visual Studio - Memory 창에서 유효한 주소 영역임에도 "Unable to evaluate the expression." 오류 출력
12056정성태11/18/2019566개발 환경 구성: 464. "Microsoft Visual Studio Installer Projects" 프로젝트로 EXE 서명 및 MSI 파일 서명 방법파일 다운로드1
12055정성태11/17/2019283개발 환경 구성: 463. Visual Studio의 Ctrl + Alt + M, 1 (Memory 1) 등의 단축키가 동작하지 않는 경우
12054정성태11/15/2019669.NET Framework: 869. C# - 일부러 GC Heap을 깨뜨려 GC 수행 시 비정상 종료시키는 예제
1  2  3  4  5  [6]  7  8  9  10  11  12  13  14  15  ...