Son IT

[ipTIME] 공유기로 VPN 서버 구성하기

sonit — Tue, 30 Apr 2024 00:52:15 +0900

대부분 가정에 공유기를 두고 사용하고 계실텐데요. 이번에는 공유기로 VPN(Virtual Private Network)을 구성해서 어디서든 안전하게 자신의 네트워크에 접속할 수 있는 환경을 만들어보도록 하겠습니다. 공유기는 ipTIME을 사용하여 설명하니 참고해주세요!

공유기 관리자 페이지 접속

먼저, 공유기가 인터넷에 연결되어 있고, PC나 모바일 기기가 해당 공유기 네트워크에 연결되어 있다면 공유기 관리자 페이지로 접속하여 로그인해줍시다. 별도 설정이 없다면 웬만한 모델은 192.168.0.1으로 접속 될 것이고, 그렇지 않다면 게이트웨이를 확인해주시면 됩니다.

[그림 1] ipTIME 공유기 로그인

별도의 아이디 패스워드를 설정하지 않았다면 디폴트인 admin/admin으로 접속이 될 것 입니다.

VPN 서버 설정

관리자 페이지에 접속하면 메뉴에서 고급 설정 > 특수기능 > VPN 서버설정을 찾아 클릭합니다.

[그림 2] ipTIME VPN 서버설정

VPN 서버 사용 옵션을 사용함으로 설정하고, VPN 타입으로는 일반적으로 PPTP와 L2TP 중 선택할 수 있습니다. PPTP는 설정이 간단하지만 보안성이 다소 떨어지고, L2TP는 설정이 복잡하지만 보안성이 높습니다.

그리고 아래에 VPN 접속 계정을 추가해줍시다.

[그림 3] 외부 IP 주소 확인

VPN 서버 접속

VPN 설정이 완료되면 외부에서 공유기의 네트워크에 접속할 때는 VPN 클라이언트 프로그램이 필요합니다. 윈도우 PC의 경우, 운영 체제에 내장된 VPN 클라이언트를 사용할 수 있습니다. 필자는 윈도우 환경이기 때문에 운영체제에 내장된 VPN을 통해 접속해보도록 하겠습니다.

[그림 5]  Windows 네트워크 및 인터넷의 VPN 설정

Windows에서는 ‘네트워크 및 인터넷 설정’에서 VPN을 추가하고, 앞서 [그림 2]에서 설정했던 계정 정보와 [그림 3]에서 확인 했던 외부 IP 주소를 입력하여 접속합니다.

[그림 6] Windows 내장된 VPN 설정 화면

스마트폰의 경우, iOS나 Android의 설정 메뉴에서 VPN을 추가하고 설정 정보를 입력하여 사용할 수 있습니다.

[그림 7] VPN 정상 연결 화면

정상적으로 VPN에 연결이 되었다면 위의 [그림 7]과 같이 연결된 것을 확인할 수 있을 것입니다.

[그림 8] VPN 연결시 IP 확인

cmd에서 ipconfig를 확인해보면 [그림 2]에서 할당해 둔 IP를 받은 것을 확인할 수 있습니다.

[그림 9] VPN 연결 후 내부 통신 확인

VPN이 연결되면 해당 네트워크 사설망과의 통신이 가능해집니다.

이상으로 ipTIME 공유기를 이용한 VPN 서버 구성 방법에 대해 알아보았습니다.

VPN을 사용하실 때 다음 내용에 주의해서 사용해주세요.

VPN 접속 시 인터넷 속도가 다소 느려질 수 있습니다.
공유기의 펌웨어 버전에 따라 지원하는 VPN 기능이 다를 수 있으니, 최신 펌웨어로 업데이트하는 것이 좋습니다.
VPN 서버를 통한 접속은 보안상의 이유로 반드시 필요한 경우에만 사용하는 것이 좋습니다.

이 방법을 통해 어디에서든 안전하게 자신의 네트워크에 접속할 수 있게 되길 바랍니다.

[Azure] 기업의 클라우드 전환 가속화를 위한 Microsoft EA 및 SCE 계약

sonit — Mon, 29 Apr 2024 21:21:17 +0900

Microsoft Azure의 Enterprise Agreement(EA)는 대규모 기업이 클라우드 서비스를 보다 유연하고 비용 효율적으로 이용할 수 있게 하는 기업 간 계약입니다. 이번 포스팅에서는 필자가 회사에서 Azure를 도입하면서 MS와 EA 및 SCE 계약을 맺으면서 이해했던 내용들을 정리하고자 합니다.

개요

현대 기업 환경에서 클라우드 컴퓨팅은 더 이상 선택이 아닌 필수가 되었습니다. 효율성, 유연성, 그리고 확장성을 제공하는 클라우드 서비스는 기업이 빠르게 변화하는 시장 환경에 적응하고, 경쟁 우위를 확보하는 데 중요한 역할을 합니다. 이러한 배경 하에, Microsoft Azure는 기업이 클라우드로의 전환을 원활하게 진행할 수 있도록 다양한 계약 옵션을 제공합니다. 본 글에서는 기업 간 클라우드 서비스 계약의 두 가지 주요 형태인 Enterprise Agreement(EA)와 Server and Cloud Enrollment(SCE)에 대해 살펴보겠습니다.

Enterprise Agreement(EA)란?

Microsoft Azure EA는 대규모 기업 고객을 대상으로 하는 계약으로, 최소 3년 동안의 약정을 통해 Azure 서비스를 이용할 수 있는 계약입니다. 이 계약을 통해 기업은 더 낮은 가격으로 Azure 서비스를 이용할 수 있으며, 사용량에 따라 비용을 지불하는 유연한 방식을 선택할 수 있습니다.

EA 계약을 통해 얻을 수 있는 장점은 다음과 같습니다.

1. 비용 절감: 큰 규모의 약정을 통해 더 낮은 가격으로 서비스를 이용할 수 있습니다.
2. 유연성: 사용량이 변동될 때 비용을 조절할 수 있어, 기업의 실제 필요에 맞춰 비용을 최적화할 수 있습니다.
3. 관리의 편리성: Microsoft Azure Portal을 통해 사용량과 비용을 쉽게 관리할 수 있습니다.

하지만, EA 계약은 일반적으로 최소 3년의 약정을 요구하며, 초기 투자 비용이 발생할 수 있습니다. 중소기업의 입장이라면 부담이 될 수 있고, 유연성 제한이나 계약 조기 종료시 발생할 수 있는 추가 비용 등 계약 조건이 다소 복잡할 수 있습니다. 따라서 기업이 EA 계약을 고려할 때는 이러한 장단점을 면밀히 검토하고, 회사의 비즈니스 요구 사항과 일치하는지 평가하는 것이 중요합니다.

Server and Cloud Enrollment(SCE)란?

SCE 계약은 Microsoft의 서버 기반 제품과 클라우드 서비스를 포함하는 계약으로, 기업이 Microsoft의 서버 솔루션과 클라우드 서비스를 통합적으로 이용할 수 있게 합니다.

SCE 계약의 주요 특징은 다음과 같습니다.

1. 통합 서비스 이용: Microsoft의 서버 솔루션과 클라우드 서비스를 하나의 계약 아래에서 이용할 수 있습니다.
2. 가격 혜택: 대량 구매를 통해 제공되는 할인 혜택을 통해 비용을 절감할 수 있습니다.
3. 커스터마이제이션: 기업의 필요에 따라 서비스를 맞춤형으로 선택하고 조정할 수 있습니다.

쉽게 말해, EA 계약 하에 클라우스 서비스를 제공하고, 유리한 가격 및 혜택을 제공해준다고 생각하면 됩니다. 필자는 계약 시 ACD(Azure Commitment Discount) 혜택이 있었고, 해당 계약 조건으로 인해 Non-RI 제품이나 AOAI 관련 리소스에 대해 할인을 받을 수 있는 계약 조건이 포함되기도 하였습니다.

ACD(Azure Commitment Discount)란?

ACD는 RI 할인 적용이 불가한 Azure 서비스에 대해 할인을 받을 수 있다고 이해해주시면 됩니다. 기본적으로 일정량의 기본 사용량을 걸어두고, 정해진 만큼의 할인을 받을 수 있도록 약속을 해두는 것입니다. 간혹 대형 프로젝트에 대해 No Commitment 조건을 걸어두는 경우도 있으니 참고해주시면 됩니다.

결론

Microsoft EA와 SCE 계약은 각각의 장점을 가지고 있으며, 기업의 요구와 상황에 따라 적절히 선택할 수 있습니다. 클라우드로의 전환은 기업이 미래 지향적인 기술 환경을 구축하는 데 있어 필수 불가결한 요소가 된지 오래되었습니다. 필자는 OpenAI 관련 프로젝트에 Involve 되어 회사에 Azure를 처음으로 도입하게 되었는데요. 직접 계약서를 검토하고, Microsoft와 Azure의 계약과 전략에 관해 다양한 시각으로 공부할 수 있었습니다. 추후 Azure를 운영하고 공부하면서 관련 포스팅도 올릴 예정이니 참고해주세요!

[IPSec VPN] Juniper JunOS 장비에서 AWS와의 Site-to-Site VPN 터널링 과정

sonit — Sun, 24 Dec 2023 01:35:47 +0900

AWS에서 Site-to-Site VPN을 설정하려면 온프레미스에 있는 IPSec VPN 장비와 터널링하는 과정이 필요합니다. 본 포스팅에서는 Juniper 기반의 IPSec VPN 장비의 GUI 환경에서 터널링하는 방법을 설명합니다. AWS에서 Site-to-Site VPN 연결을 구성하는 방법은 아래 포스팅을 참고해주시기 바랍니다.

[클라우드/AWS] - [AWS] Site-to-Site VPN 구성하기: 온프레미스 사설망과의 연결

AWS VPN 구성 정보 다운로드

앞선 포스팅에서 생성했던 VPN 연결에서 구성 다운로드를 하여 해당 구성대로 VPN 터널링을 진행하면 되는데, 그러기 위해선 터널링을 구성할 온프레미스 IPSec VPN의 구성 정보가 필요합니다. 여기서는 아래 [그림 1]과 같이 Juniper의 JunOS 버전의 장비에 구성하는 것을 설명합니다.

[그림 1] IPSec VPN 버전 정보 확인

해당 구성 정보를 바탕으로 AWS 콘솔에서 앞서 생성한 VPN 연결을 선택하여 [그림 2]와 같이 구성 다운로드를 클릭합니다.

[그림 2] VPN 연결의 구성 다운로드 클릭

Transit Gateway로 구성 변경한 후에 캡처한 화면이고, IPSec VPN에서 해야할 작업은 동일하니 참고만 해주세요.

[그림 3] VPN 구성 다운로드 항목 선택

구성에 맞게 공급 업체, 플랫폼, 소프트웨어, IKE 버전 항목들을 선택하여 다운로드하여 나온 파일을 실행시키면 다음 [그림 4]와 같은 내용을 확인할 수 있습니다.

[그림 4] IPSec VPN 구성 파일 내용

필자는 회사에서 네트워크를 주로 담당하는 인원이 아닐 뿐더러 장애가 났을 때 즉각적인 대응을 할 수 있도록
작업 내용을 이해하면서 진행하기 위해 GUI 환경에서 진행하였습니다.

위 구성 파일 내용을 이해해보면, 샵(#)은 주석이고, 주석이 없는 내용을 CLI에서 명령어를 입력하라는 내용인 것 같습니다. 주석에 명령어를 수행하는 내용들이 설명되어 있고, 본 포스팅에서는 해당 명령어에 해당하는 부분을 GUI 환경에서 하나하나 내용을 확인하면서 천천히 진행해볼 것이다.

Juniper IPSec VPN에서 Site-to-Site VPN 터널링 과정

1. IKE (Phase I) 구성

처음으로, security ike proposal 명령에 해당하는 메뉴를 [그림 5]와 같이 찾아갔습니다. Security Services > VPN > IKE (Phase I) 메뉴로 들어와 3개의 탭 중 맨 오른쪽의 Proposal을 눌러 우측 상단의 + 버튼을 클릭합니다.

[그림 5] IKE (Phase I) 설정

구성 파일 내용대로 이름은 ike-prop-vpn-0db1a14-1, authentication-algorithm은 sha1, authentication-method는 pre-shared-keys, dh-group은 group2, lifetime-seconds는 28800으로 세팅하고 OK를 눌러줍시다.

[그림 6] IKE (Phase I) Proposal 생성

다음으로, [그림 5]의 가운데 탭인 IKE Policy로 들어와 마찬가지로 우측 상단의 +를 눌러 구성 파일 내용대로 설정하여 줍시다.

[그림 7] IKE (Phase I) Policy 생성

여기서 Name은 이해하기 쉬운 이름으로 아무 이름을 입력해주시면 됩니다. 그리고 두 번째 탭인 IKE Polycy Options를 들어가면 앞선 Proposal에서 설정한 pre-shared-keys에 대한 값을 입력해줄 수 있는데, 이 또한 구성 파일에 들어있는 값을 그대로 붙여넣어주면 됩니다.

다음으로, [그림 5]의 첫 번째 탭인 Gateway로 들어와 마찬가지로 우측 상단의 +를 눌러 구성 파일 내용대로 설정하여 줍시다.

[그림 8] IKE (Phase I) Gateway 생성

앞서 생성한 Policy를 선택하고, Excernal Interface에는 각자의 환경에서 WAN으로 나갈 때 사용되는 인터페이스를 선택하여주면 됩니다. Site to Site VPN의 Remote Peer IP도 구성 파일의 내용에 있는 값을 그대로 입력하여 주고, 기타 옵션들도 동일하게 설정해주면 되겠습니다.

여기까지 설정하였으면 Phase I 구성은 끝난 것입니다.

2. IPSec (Phase II) 구성

Security Services > VPN > IPsec (Phase II) 메뉴로 들어와 Phase I과 마찬가지로 3개의 탭 중 맨 오른쪽의 Proposal을 눌러 우측 상단의 + 버튼을 클릭합니다.

[그림 9] IPSec (Phase II) Proposal 생성

Phase I 때와 같이 구성 파일 내용과 동일한 내용대로 값을 채워넣어가면 됩니다.

다음 두 번째 탭에 있는 Policy도 우측 상단의 + 버튼을 눌러 생성해줍시다.

[그림 10] IPSec (Phase II) Policy 생성

앞서 생성한 Proposal을 선택하여 넘어가면 됩니다.

다음으로, Phase II의 첫 번째 탭인 VPN을 생성하기 이전에 터널링을 위한 인터페이스를 먼저 생성해주어야 합니다. Network > Routing > Ports 메뉴로 이동하여 새로운 인터페이스를 생성해줍시다.

[그림 11] 터널링 인터페이스 생성

마찬가지로 구성 파일 내용에 있는 터널링 IP 대역을 그대로 입력하여 생성해주고, 여기서 인터페이스 번호는 st0.79입니다.

다시 돌아와서, Phase II의 첫 번째 탭인 VPN을 생성해줍시다.

[그림 12]  IPSec (Phase II) VPN 생성

앞서 생성했던 Gateway, Policy, Tunnel Interface를 선택하고, IPSec VPN Options 탭에서 VPN 모니터도 구성 파일대로 세팅해줍시다.

여기까지 정상적으로 구성했으면 VPN 터널링은 정상적으로 구성되었을 것입니다.

3. IPSec VPN의 Static Routing 추가

Network > Routing > Static Routing 메뉴로 이동해서 Destination IP에 해당하는 클라우드 대역대라면 Next-hop을 [그림 11]에서 생성한 인터페이스로 설정해줍니다.

[그림 12] Static Routing 추가

여기서는 VPC에 해당하는 모든 대역대를 지정해두었고, 해당 대역의 IP는 모두 위에서 생성한 st0.79 인터페이스를 타고 클라우드로 넘어갈 수 있도록 라우팅을 미리 설정해두었습니다.

[그림 14] 생성된 Static Routing 확인

IPSec VPN에서 라우팅까지 구성해주었으면, Commit하여 AWS 상에서 터널링이 잘 구성되었는지 확인하여 줍시다.

[그림 15] VPN Commit 수행

추가로 다른 지역이나 IPSec VPN에 연결된 네트워크 장비를 통해 해당 터널링으로 통신해야 한다면 별도의 네트워크 장비에서도 라우팅을 추가해주어야 합니다. 예를 들어, 백본에 연결된 서버 및 PC에서 위에서 구성한 VPN 터널링을 통해 클라우드와 통신해야 한다면, 아래 [그림 16]과 같이 백본에서 다음 홉을 IPSec VPN으로 타도록 설정해야 합니다.

[그림 16] 백본에서 IPSec VPN으로의 라우팅 추가

4. AWS VPN 터널링 상태 확인

위에서 터널링을 성공적으로 구성했다면 다음 [그림 17]과 같이 AWS 상에서 VPN 터널링 1번의 링크가 Up 되어 있는 것을 확인할 수 있습니다.

[그림 17] AWS 상의 VPN 터널링 상태 확인

그럼 즐거운 터널링 되세요!

[AWS] Site-to-Site VPN 구성하기: 온프레미스 사설망과의 연결

sonit — Sat, 23 Dec 2023 18:51:08 +0900

AWS Site-to-Site VPN은 온프레미스 네트워크와 AWS 클라우드 간의 안전한 연결을 제공합니다. 이 포스팅에서는 AWS 콘솔에서 Site-to-Site VPN을 설정하는 과정을 안내합니다.

1. 고객 게이트웨이 생성

AWS 콘솔에 로그인하고, VPC > VPN > 고객 게이트웨이로 이동합니다. 여기서 다음과 같이 온프레미스 네트워크에 해당하는 고객 게이트웨이를 생성합니다.

[그림 1] AWS 고객 게이트웨이 생성

이름은 고객 게이트웨이를 구분할 수 있는 이름을 입력해주면 되고, 아래 IP 주소에는 VPN 터널링을 진행할 IPsec VPN의 WAN IP를 입력해주면 됩니다.

2. 가상 프라이빗 게이트웨이 생성

이제 가상 프라이빗 게이트웨이를 생성해주겠습니다.

[그림 2] AWS 가상 프라이빗 게이트웨이 생성

자율 시스템 번호(ASN)는 고객 게이트웨이에 지정된 ASN과 달라야 하는데, 여기서는 Amazon기본 ASN을 선택하고 넘어가겠습니다.

가상 프라이빗 게이트웨이를 생성하면 VPC에 연결할 수 있습니다. 해당 vpg를 통해 통신할 VPC를 선택해줍시다.

[그림 3] 가상 프라이빗 게이트웨이 VPC 연결

[그림 4] VPC 연결 적용

3. Site-to-Site VPN 연결 생성

다음으로, VPC > VPN > Site-to-Site VPN 연결 메뉴를 눌러 들어옵니다. VPN 연결 생성을 클릭하고 필요한 정보를 입력합니다. 여기서 고객 게이트웨이와 가상 프라이빗 게이트웨이를 연결합니다.

[그림 5] Site-to-Site VPN 연결 생성

4. 라우팅 구성

VPN 연결이 생성되면 온프레미스 네트워크와 AWS VPC 간에 트래픽을 라우팅할 수 있도록 VPN 정적 경로를 수정하거나 라우팅 테이블을 구성할 수 있습니다.

[그림 6] VPN 정적 경로 수정

#. 온프레미스 네트워크 구성

마지막으로, 온프레미스 네트워크에서도 VPN 연결에 대한 구성을 수행해야 합니다. 이 단계는 온프레미스의 라우터 또는 VPN 장비에 따라 구성 방법이 다소 다릅니다. 다음 포스팅에서는 앞서 생성한 Site-toSite VPN과 온프레미스 네트워크와의 연결을 위해 Juniper 제조사의 IPsec VPN과의 터널링하는 과정을 간단하게 포스팅해볼 것 입니다.

더 자세한 내용이나 고급 설정에 대해서는 AWS 공식 문서와 온프레미스 장비 제조사의 문서를 참고해주세요!

[Windows] 원격 데스크톱 RDP(3389) 포트 변경

sonit — Thu, 7 Dec 2023 01:00:47 +0900

원격 데스크톱(Remote Desktop) 서비스의 포트는 기본적으로 3389를 사용합니다. 하지만 보안 상의 이유로 3389 포트를 그대로 사용하는 것 보다 변경하는 것이 좋습니다. 본 포스팅에서는 윈도우 서버에서 RDP 포트를 변경하는 과정을 설명합니다.

레지스트리 편집기 수정

아래 [그림 1]과 같이 Win + R 키를 눌러 실행창을 열고, regedit을 입력합니다.

[그림 1] 레지스트리 편집기 실행

레지스트리 편집기가 열리면 다음 경로로 이동해줍니다.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

해당 경로로 이동하면 PortNumber라는 레지스트리 항목을 찾아 더블클릭하여 아래 [그림 2]와 같이 수정해줍니다. 여기서는 10진수를 선택하여 3389 대신 2280이라는 포트 번호를 사용하도록 입력하였습니다.

※ 레지스트리 편집은 주의가 필요하며, 잘못된 수정은 시스템에 영향을 줄 수 있습니다. 수정 전에 백업을 진행하는 것이 좋습니다.

[그림 2] 레지스트리 편집기에서 RDP PortNumber 값 수정

RDP 서비스 재시작

RDP PortNumber 레지스트리 값을 정상적으로 수정하였다면 RDP 서비스를 재시작 해야 합니다.

이번에는 실행창에서 services.msc를 입력하여 Remote Desktop Services 라는 서비스명을 찾습니다. 해당 서비스를 클릭하고 아래 [그림 3]과 같이 다시 시작 버튼을 클릭하여 서비스를 재시작하여 줍니다.

[그림 3] Remote Desktop Services 서비스 재시작

RDP 서비스가 재시작되면 앞서 변경했던 레지스트리의 값이 적용되어 2280 포트로 원격 데스크톱 연결이 가능하도록 변경되었을 것 입니다.

방화벽 구성

다음으로 원격 데스크톱 트래픽을 허용하도록 방화벽에 변경된 포트인 2280 포트를 추가해주는 과정이 필요합니다. 이번에는 실행창에서 wf.msc를 입력하여 Windows Defender 방화벽 고급 화면을 띄워줍니다. 그리고 아래 [그림 4]와 같이 우측의 새 규칙... 을 눌러 포트를 선택하여 넘어갑니다.

[그림 4] 방화벽 새 규칙 추가

TCP 프로토콜을 선택하고 특정 로컬 포트를 선택해 레지스트리를 수정했던 RDP 포트인 2280을 입력하여 줍니다.

[그림 5] 프로토콜 선택 및 포트 번호 입력

앞서 설정한 규칙을 허용하도록 연결 허용을 선택하고 넘어갑니다.

[그림 6] 연결 허용 선택

규칙 이름을 선택하고 넘어갑니다. 여기서는 RDP TCP(2280) 이라고 입력하였습니다.

[그림 7] 규칙 이름 입력

방화벽도 추가하였으면 이제 변경된 포트 번호로 정상적으로 접속되는지 확인하면 됩니다.

혹시나 포트 변경 후 접속이 안된다면 OS 단에서 원격 데스크톱이 허용되어 있는지, 별도의 방화벽 및 네트워크 장비에서차단되어 있는 것은 아닌지 확인해보아야 합니다.

[ipTIME] WOL로 외부에서 PC 원격 켜기

sonit — Wed, 6 Dec 2023 02:19:47 +0900

본 포스팅에서는 WOL(Wake-on-LAN)을 사용하여 외부에서 ipTIME 라우터를 통해 PC를 켜는 방법에 대해 설명합니다. 여기서는 MSI MAG b660m 박격포 DDR4 메인보드를 기준으로 설명합니다. 여기서는 DDNS 설정이 되어 있다고 가정합니다. DDNS 설정 방법은 아래 포스팅을 참고해주세요.

[네트워크/ipTIME] - [ipTIME] 외부 접속을 위한 DDNS 설정 방법

개요

WOL(Wake On LAN)은 원격으로 편리하게 PC 전원을 켤 수 있는 방법 중 하나입니다. 집에서 공유기를 사용하고 있다면 WOL 기능이 있는지 확인해보시기 바랍니다. 이 글에서는 ipTIME을 이용하여 외부에서 집에 있는 PC를 원격으로 켜는 설정을 간단하게 안내하겠습니다.

메인보드 BIOS 설정

WOL 기능을 사용하기 위해서는 가장 먼저 메인보드에서 지원되는지 확인해야 합니다. 먼저 컴퓨터 전원을 켜서 BIOS 화면으로 진입합니다.

[그림 1] BIOS진입 및 WOL 활성화

위의 [그림 1]과 같이 각 메인보드에는 WOL을 활성화하는 설정이 있는데, 필자가 사용 중인 메인보드에서는 Settings > Advanced > Wake Up Event Setup 메뉴로 들어와서 설정할 수 있습니다. 해당 설정을 찾기 힘들다면 WOL 기능을 지원하는 메인보드인지, 설정하는 방법 등을 별도로 검색해보셔야 합니다.

ipTIME WOL 기능 설정

먼저 ipTIME 관리자 페이지에 접속하여 로그인 합니다. 필자의 ipTIME 관리자 페이지는 192.168.0.1로 설정되어 있습니다. 로그인 하였으면 아래 [그림 2]와 같이 고급 설정 > 특수 기능 > WOL 기능 항목으로 들어갑니다. 현재 접속된 PC의 주소로 설정 부분을 클릭하고 간단한 설명 입력 후에 추가를 입력하면 됩니다.

[그림 2] ipTIME WOL 기능 설정

ipTIME WOL 어플 설치 및 설정

BIOS와 공유기에서 WOL 설정을 했으면 외부에서 WOL 패킷을 전송하면 원격으로 등록한 PC를 켤 수 있게 됩니다. 여기서는 ipTIME WOL 앱을 통해 WOL 패킷을 전송할 수 있는 환경을 만들어보겠습니다. Play스토어에서 ipTIME WOL을 검색하여 앱을 설치하여 줍시다.

[그림 3] ipTIME WOL 앱 설치

앱을 실행하고, PC와 같은 네트워크 환경의 WIFI가 연결되어 있는 상태로 공유기 자동 검색을 클릭하면 아래 [그림 4]와 같이 자동으로 공유기가 잡히는 것을 확인할 수 있습니다.

[그림 4] ipTIME WOL 공유기 자동 검색

앞 포스팅을 통해 미리 등록해두었던 DDNS 설정들과 공유기 관리자 계정 정보를 입력하여 아래 [그림 5]와 같이 공유기를 등록하여 줍시다.

[그림 5] ipTIME WOL 외부 네트워크 공유기 등록

정상적으로 등록되었으면 아래 [그림 6]과 같이 등록된 화면을 확인할 수 있습니다.

[그림 6] ipTIME WOL 공유기 등록 화면

공유기를 클릭하면 앞서 등록해두었던 PC가 화면에 보이게 되고, 해당 PC를 클릭하면 PC를 켜겠냐는 프롬프트가 나오게 되는데, 여기서 확인을 누르면 해당 PC로 WOL 패킷 신호를 전송하게 됩니다.

[그림 7] ipTIME WOL 패킷 전송

여기까지 외부에서 ipTIME 라우터를 통해 PC를 원격으로 켜는 설정을 알아보았습니다. 이를 통해 언제 어디서나 편리하게 PC를 켤 수 있는 환경이 만들어졌습니다. 혹시나 PC가 켜지지 않는다면 수동으로 PC를 한 번 켰다가 셧다운시킨 후에 다시 시도해보시면 될 것 같습니다.

[ipTIME] 외부 접속을 위한 DDNS 설정 방법

sonit — Wed, 15 Nov 2023 01:06:37 +0900

ipTIME 공유기에서는 DDNS(Dynamic Domain Name System) 설정을 통해 외부에서도 공유기 관리 페이지에 접속할 수 있는 기능을 제공합니다. 이번 포스팅에서는 외부에서도 집에 설치되어 있는 ipTIME 공유기에 접속할 수 있도록 설정하는 방법을 다룹니다.

개요

DDNS는 동적 IP 주소를 고정적인 도메인 이름을 가질 수 있도록 도와주는 시스템입니다. 일반적으로 ISP로부터 동적으로 할당되는 IP 주소는 변경될 수 있습니다. 이런 경우, 네트워크에 연결된 기기에 접근하기 위해서는 매번 새로운 IP 주소를 알아내고 기억해야 합니다. DDNS는 이러한 문제를 해결하기 위해 동적으로 IP 주소를 갱신하고, 이에 연동된 도메인 이름을 업데이트하여 항상 최신 IP 주소로 접근할 수 있도록 합니다. 예를 들면, 집에서 사용하는 공유기나 웹캠, NAS 등과 같은 기기에 DDNS를 설정하면 외부에서도 해당 기기에 접근할 수 있게 됩니다.

DDNS 구성

본 포스팅에서는 ipTIME A2004NS-R 제품을 사용하여 구성하는 과정을 살펴볼 것 입니다. 제품 및 모델마다 메뉴와 구성 방식이 조금씩 다를 수 있으니 참고해주시면 됩니다.

먼저 공유기 관리 페이지에 접근해야 합니다. 보통 기본 게이트웨이 주소를 브라우저에서 입력하여 접속할 수 있습니다. 게이트웨이 주소는 아래 [그림 1]과 같이 cmd에서 ipconfig 명령을 수행하여 확인할 수 있습니다.

[그림 1] cmd에서 ipconfig 명령 수행 화면

ipTIME 관리 페이지에 접속하여 로그인해줍시다.

[그림 2] ipTIME 관리 페이지 접속

성공적으로 로그인하여 관리도구를 클릭하여 들어오고 나서 아래 [그림 3]과 같이 왼쪽 메뉴에서 고급 설정 - 특수기능 - DDNS 설정 메뉴에 접속하여 줍시다.

[그림 3] ipTIME DDNS 설정 메뉴

제공되는 도메인은 iptime.org으로 고정이고, 앞의 서브 도메인은 원하는 이름으로 정하여 설정할 수 있습니다. 그리고 사용자ID는 이메일 주소를 입력해주면 되겠습니다. 여기서는 서브 도메인을 sonit이라고 지정하였습니다.

정상적으로 DDNS가 등록되면 아래 [그림 4]와 같이 접속상태가 정상 등록으로 표시되는 것을 확인할 수 있습니다.

[그림 4] ipTIME DDNS 정상 등록 화면

원격 접속 포트 설정 및 접속 확인

DDNS를 설정하고 나서 해당 도메인으로 접속할 포트를 설정해보겠습니다. 왼쪽 메뉴의 고급 설정 - 보안 기능 - 공유기 접속/보안관리 메뉴에 들어오면 아래 [그림 5]와 같은 화면을 볼 수 있습니다.

[그림 5] ipTIME 공유기 접속/보안관리 화면

원격 관리 포트 사용에 체크하고, 우측의 원격 관리 포트에 사용할 포트 번호를 입력해주고 적용을 누르면 됩니다. 여기서는 9898로 입력하였습니다.

그럼 이제 앞서 설정한 DDNS와 원격 포트를 사용하여 접속해보겠습니다. 브라우저를 새로 열고 앞서 설정했던 내용대로 입력하면 내부 IP 주소로 사용되는 원격 게이트웨이 주소로 접속하는 게 아닌 외부에서 접속이 가능하게 됩니다.

SUBDOMAIN.iptime.org:9898

[그림 6] ipTIME 외부 접속 확인

외부에서 테스트해보고 싶다면 모바일로 접속해봐도 될 것 같습니다.

[AWS] Lambda를 통한 Instance 및 RDS 자동 중지 및 시작 방법

sonit — Mon, 12 Jun 2023 02:43:25 +0900

제가 작성한 AWS Lambda를 통한 EC2 인스턴스와 RDS 데이터베이스의 자동 중지 및 시작 방법에 대한 블로그 포스팅을 아래에 제시합니다. 이 포스팅은 AWS Lambda 함수를 사용하여 일정 시간이 지난 후에 EC2 인스턴스와 RDS 데이터베이스를 중지하고 다시 시작하는 방법에 대해 안내합니다.

개요

EC2 인스턴스 및 RDS는 시간당 또는 사용한 용량에 따라 비용이 청구됩니다. 이러한 비용은 인스턴스가 실행되는 동안 계속해서 발생하므로, 필요하지 않은 시간에 인스턴스가 실행되어 있는 경우 비효율적인 비용이 발생할 수 있습니다. 사용하지 않는 시간대에는 불필요한 비용이 나가지 않도록 중지시켜 두는 것이 좋습니다. 예를 들어, 회사 출근 시간에만 사용한다고 가정하면, 오전 8시부터 오후 7시까지만 켜지도록 설정할 수 있습니다. 사용 시간에 따른 비용 최적화를 위해 Lambda를 사용하여 EC2 인스턴스와 RDS를 자동으로 on/off 할 수 있도록 구성해봅시다.

Lambda 생성 및 코드 작성

Lambda는 AWS에서 제공하는 서버리스 컴퓨팅 서비스로, 특정 이벤트에 대한 리액션을 자동으로 수행하는 데 사용됩니다. Lambda 함수는 사용자가 정의한 코드를 실행하며, 이벤트 트리거를 기반으로 실행됩니다.

먼저, AWS 콘솔에서 EC2 인스턴스와 RDS를 자동으로 시작해주는Lambda에서 함수 생성을 눌러 함수를 생성합시다.

[그림 1] Instance/RDS auto-start 람다 생성

원하는 함수 이름을 입력하고, 역할은 우선 새 역할을 생성하는 것을 선택하고 넘어가겠습니다.

정상적으로 생성되면 다음 [그림 2]와 같은 화면을 볼 수 있습니다.

[그림 2] 람다 생성 후 화면

정상적으로 생성되었으면 아래 코드 소스 부분에 다음 코드를 그대로 입력해봅시다.

import boto3

region = 'ap-northeast-2'
instances = []
ec2_r = boto3.resource('ec2')
ec2 = boto3.client('ec2', region_name=region)
rds = boto3.client('rds')

for instance in ec2_r.instances.all():
    if instance.state['Name'] == 'stopped':
        for tag in instance.tags:
            if tag['Key'] == 'auto-start':
                if tag['Value'] == 'true':
                    instances.append(instance.id)

def lambda_handler(event, context):
    if len(instances) == 0:
        print('instance not found')
    else:
        ec2.start_instances(InstanceIds=instances)
        print('start your instances: ' + str(instances))
        
    dbs = rds.describe_db_instances()
    for db in dbs['DBInstances']:
        if (db['DBInstanceStatus'] == 'stopped'):
            doNotStart=1
            try:
                GetTags=rds.list_tags_for_resource(ResourceName=db['DBInstanceArn'])['TagList']
                for tags in GetTags:
                    if(tags['Key'] == 'auto-start' and tags['Value'] == 'true'):
                        result = rds.start_db_instance(DBInstanceIdentifier=db['DBInstanceIdentifier'])
                        print ("Starting instance: {0}.".format(db['DBInstanceIdentifier']))
                if(doNotStart == 1):
                    doNotStart=1
            except Exception as e:
                print ("Cannot start instance {0}.".format(db['DBInstanceIdentifier']))
                print(e)

간단하게 설명하자면, 서울 리전의 EC2 Instance와 RDS가 중지 상태이고, tags의 auto-start 키의 값이 true면 인스턴스를 시작시키게 됩니다.

Lambda 권한 설정

이대로 Deploy를 누르고 Test를 하면 Lambda에서 Instance와 RDS의 상태를 변경할 권한이 없어 실패할 것 입니다. 기본적으로 CloudWatch Log를 남기는 권한만 있는데, 구성 > 권한으로 이동하여 역할 이름을 눌러봅시다.

[그림 3] 람다 권한 확인

정책을 통해 권한을 수정하기 위해 정책 이름을 클릭합시다.

[그림 4] 정책 이름 클릭

우측의 JSON을 선택하고, 편집을 클릭하겠습니다.

[그림 5] JSON 형태로 정책 수정

기존 내용을 모두 지우고 다음 코드 내용을 붙여 넣습니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "start",
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "rds:StartDBCluster",
                "rds:StartDBInstance"
            ],
            "Resource": [
                "arn:aws:rds:*:*:db:*",
                "arn:aws:ec2:*:*:instance/*"
            ]
        },
        {
            "Sid": "describe",
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances",
                "ec2:DescribeTags",
                "ec2:DescribeInstanceStatus",
                "rds:ListTagsForResource",
                "rds:DescribeDBInstances",
                "rds:DescribeDBClusters"
            ],
            "Resource": "*"
        }
    ]
}

Tags 추가

EC2 Instance와 RDS를 시작하기 위해 필요한 권한들을 부여해두고, 자동 시작을 적용할 인스턴스의 Tags를 다음과 같이 설정해줍시다.

[그림 6] EC2 Instance의 Tags 설정

태그에서 auto-start 키에 true 값을 넣으면 람다를 실행시켰을 때 해당 인스턴스가 시작됩니다. 그리고 auto-stop도 미리 넣어두겠습니다.

Tags를 추가하고, 인스턴스를 중지를 시킨 상태에서 [그림 2]에서 Test 버튼을 눌러 앞서 생성한 람다를 실행시키면 인스턴스가 켜지는 것을 확인하실 수 있습니다.

EventBridge 트리거 추가

다음으로, [그림 2]에서 트리거 추가 버튼을 눌러 CloudWatch Events를 선택하면 Cron과 같이 스케줄 작업을 설정할 수 있습니다. 예약 표현식에서 cron 표현식을 작성할 수 있는데, 다음 [그림 7]과 같이 평일 오전 8시에 시작하도록 작성해봅시다. 참고로 UTC 시간 기준으로 +9시간을 더해야 한국 시간이 되니 참고해주세요!

[그림 7] EventBridge 생성

이렇게 EventBridge가 생성되면 평일 오전 8시마다 앞서 생성한 auto-start 람다가 실행됩니다.

auto-stop 요약 정리

기본적인 생성 방법은 auto-start 부분과 동일하고, 수정해야될 부분만 간단하게 설명합니다.

Lambda 코드는 다음과 같이 입력합니다.

import boto3

region = 'ap-northeast-2'
instances = []
ec2_r = boto3.resource('ec2')
ec2 = boto3.client('ec2', region_name=region)
rds = boto3.client('rds')

for instance in ec2_r.instances.all():
    if instance.state['Name'] == 'running':
        for tag in instance.tags:
            if tag['Key'] == 'auto-stop':
                if tag['Value'] == 'true':
                    instances.append(instance.id)

def lambda_handler(event, context):
    if len(instances) == 0:
        print('instance not found')
    else:
        ec2.stop_instances(InstanceIds=instances)
        print('stopped your instances: ' + str(instances))
        
    dbs = rds.describe_db_instances()
    for db in dbs['DBInstances']:
        if (db['DBInstanceStatus'] == 'available'):
            DoNotStop=1
            try:
                GetTags=rds.list_tags_for_resource(ResourceName=db['DBInstanceArn'])['TagList']
                for tags in GetTags:
                    if(tags['Key'] == 'auto-stop' and tags['Value'] == 'true'):
                        result = rds.stop_db_instance(DBInstanceIdentifier=db['DBInstanceIdentifier'])
                        print ("Stopping instance: {0}.".format(db['DBInstanceIdentifier']))
                if(DoNotStop == 1):
                    DoNotStop=1
            except Exception as e:
                print ("Cannot stop instance {0}.".format(db['DBInstanceIdentifier']))
                print(e)

Lambda 권한을 위한 정책의 json은 다음과 같이 입력합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "stop",
            "Effect": "Allow",
            "Action": [
                "ec2:StopInstances",
                "ec2:DescribeInstances",
                "ec2:DescribeTags",
                "ec2:DescribeInstanceStatus",
                "rds:StopDBCluster",
                "rds:ListTagsForResource",
                "rds:DescribeDBInstances",
                "rds:StopDBInstance",
                "rds:DescribeDBClusters"
            ],
            "Resource": "*"
        }
    ]
}

EventBridge의 예약 표현식은 cron(0 10 ? * MON-FRI *)으로 설정하여 오후 7시마다 auto-stop 람다가 실행되도록 설정합니다.

여기까지 정상적으로 설정되면 EC2 인스턴스 및 RDS의 태그에 auto-stop 키 값에 true를 설정하면 모든 설정이 완료됩니다.

해당 내용을 통해 비용을 최대한 절약할 수 있는 하나의 방법이 될 수 있길 바랍니다!!

[AWS] EFS 생성 및 마운트 방법

sonit — Wed, 7 Jun 2023 01:09:59 +0900

EFS(Elastic File System)는 AWS에서 암호화된 파일 스토리지를 제공하는 클라우드 스토리지 입니다. AWS 클라우드 서비스와 온프레미스 리소스 모두에서 사용할 수 있는 확장 가능하고 탄력적으로 쉽게 구성할 수 있습니다. 본 포스팅에서는 인스턴스에 EFS 마운트하는 방법을 설명합니다.

구성 환경

구성 내용은 다음과 같습니다.

AWS에서 EFS를 생성하여 두 인스턴스에 마운트
AWS AMI : al2023-ami-2023.0.20230329.0-kernel-6.1-x86_64

EFS 생성

AWS 콘솔에서 Amazon EFS > 파일 시스템으로 이동하여 파일 시스템 생성 버튼을 클릭합니다.

파일 시스템 생성 버튼을 누르면 다음 [그림 1]과 같이 생성할 EFS의 이름과 VPC를 선택할 수 있습니다.

[그림 1] 파일 시스템 생성

정상적으로 생성되고 일정 시간이 지나면 [그림 2]와 같이 파일 시스템 상태가 사용 가능으로 됩니다.

[그림 2] EFS 생성 화면

다음으로 EFS에서 사용할 보안 그룹을 생성하겠습니다. EFS는 2049 포트를 사용하니 다음 [그림 3]과 같이 인바운드 규칙을 추가하여 줍시다.

[그림 3] EFS에서 사용할 보안 그룹 생성

다시 EFS로 돌아와서 네트워크 액세스를 수정해보겠습니다. 인스턴스는 WAS 두 대를 가동한다고 가정하고, 여기서는 Private Subnet 두 개를 지정하여 각각의 보안 그룹에 앞에서 생성한 보안 그룹으로 지정하여 주겠습니다.

[그림 4] EFS 네트워크 액세스 수정

인스턴스 EFS 마운트

[그림 2]의 우측 상단에서 연결 버튼을 클릭하면 다음 [그림 5]와 같은 화면이 나타나게 됩니다.

[그림 5] EFS 연결 방법

먼저, EFS 탑재 헬퍼를 사용한 EFS 마운트를 하기 전에 인스턴스에 amazon-efs-utils 패키지를 설치해야 합니다.

$ sudo yum update
$ sudo yum install -y amazon-efs-utils

위의 예시에서는 현재 디렉토리의 efs에 마운트 하는 예시를 들었지만, 여기서는 /mnt/data 디렉토리를 만들어 해당 디렉토리에 마운트 시켜보겠습니다.

$ sudo mkdir -p /mnt/data
$ sudo mount -t efs -o tls fs-0f012345678908309:/ /mnt/data/

마운트가 정상적 완료되었으면 df 명령과 mount 명령을 통해 마운트 정보를 확인해보겠습니다.

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        4.0M     0  4.0M   0% /dev
tmpfs           3.8G     0  3.8G   0% /dev/shm
tmpfs           1.6G  456K  1.6G   1% /run
/dev/nvme0n1p1   70G  2.0G   68G   3% /
tmpfs           3.8G     0  3.8G   0% /tmp
tmpfs           778M     0  778M   0% /run/user/1000
127.0.0.1:/     8.0E     0  8.0E   0% /mnt/data

$ mount
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel)
...
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=1620384k,nr_inodes=405096,mode=700,uid=1000,gid=1000)
127.0.0.1:/ on /mnt/data type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,noresvport,proto=tcp,port=20295,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1,local_lock=none,addr=127.0.0.1)

마운트 위인 /mnt/data에 8 엑사바이트 만큼 사용할 수 있다고 나옵니다. 8 엑사바이트면.... 8,388,608GB 인가요?? 어마어마 하네요

자동 마운트 설정

인스턴스가 재부팅되어도 자동으로 마운트되도록 설정하기 위해서는 /etc/fstab 파일에서 다음과 같이 내용을 추가해주면 됩니다.

$ sudo vim /etc/fstab
...
fs-0f012345678908309:/                          /mnt/data/      efs     _netdev,tls             0       0

_netdev 옵션은 네트워크에 연결 후 마운트하라는 옵션인데, 그래야 시스템 시작 시 문제 없이 해당 네트워크 경로로 자동 마운트 되기 때문에 꼭 필요한 옵션입니다. 해당 옵션 빠지면 EC2 인스턴스가 응답을 중지할 수 있으니 참고해주세요!

테스트

두 인스턴스 모두 마운트 설정이 완료되었으면 마운트 위치인 /mnt/data 위치에서 test.txt 파일을 생성하여 아무 내용을 넣어봅시다.

$ cd /mnt/data
$ echo "Test EFS!" > test.txt

다른 인스턴스에서 /mnt/data로 이동하여 앞서 생성한 파일과 동일한 내용이 있는 것을 확인할 수 있습니다.

$ cd /mnt/data
$ ls
test.txt
$ cat test.txt
Test EFS!

[Ubuntu] apt install 중 E: Sub-process /usr/bin/dpkg returned an error code (1) 에러 해결 사례

sonit — Tue, 6 Jun 2023 02:49:35 +0900

본 포스팅에서는 E: Sub-process /usr/bin/dpkg returned an error code (1) 에러가 발생했을 때의 해결 사례를 보여줍니다. 기존에 설치되어 있는 Node.js의 버전 업을 시키는 과정에서 에러가 발생하였고, 에러를 해결하는 과정을 공유해보겠습니다.

[운영체제/Linux] - [Ubuntu] Node.js 및 npm 간단한 설치

개발 환경

현재 위의 포스팅에서와 같이 Ubuntu 22.04 LTS에서 Node.js v12.22.9 버전으로 설치되어 있는 상황입니다.

$ node -v
v12.22.9

여기서 16 버전으로 업그레이드하는 과정을 보여드리겠습니다.

에러 발생

먼저, 기존에 설치되어 있던 nodejs를 삭제하였습니다.

$ sudo apt-get purge -y nodejs

다음으로, 특정 버전을 설치할 수 있도록 가이드가 나와있는 설치 방법대로 스크립트를 실행시켰습니다.

$ curl -sL https://deb.nodesource.com/setup_16.x | sudo -E bash -

스크립트를 실행시킨 후 다시 nodejs를 설치하는 과정에서 다음과 같은 에러가 발생하였습니다.

$ sudo apt install -y nodejs
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
...
Use 'sudo apt autoremove' to remove them.
The following NEW packages will be installed:
  nodejs
0 upgraded, 1 newly installed, 0 to remove and 60 not upgraded.
Need to get 0 B/27.2 MB of archives.
After this operation, 128 MB of additional disk space will be used.
(Reading database ... 66829 files and directories currently installed.)
Preparing to unpack .../nodejs_16.20.0-deb-1nodesource1_amd64.deb ...
Unpacking nodejs (16.20.0-deb-1nodesource1) ...
dpkg: error processing archive /var/cache/apt/archives/nodejs_16.20.0-deb-1nodesource1_amd64.deb (--unpack):
 trying to overwrite '/usr/share/systemtap/tapset/node.stp', which is also in package libnode72:amd64 12.22.9~dfsg-1ubuntu3
Errors were encountered while processing:
 /var/cache/apt/archives/nodejs_16.20.0-deb-1nodesource1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

에러 해결

[그림 1] apt install 수행 시 libnode-dev 충돌 에러

해당 에러는 /var/cache/apt/archives/nodejs_16.20.0-deb-1nodesource1_amd64.deb 패키지를 설치하려고 할 때 충돌로 인해 발생한 것으로 보입니다. 충돌의 원인은 libnode-dev 패키지와의 파일 중복입니다.

에러를 해결하기 위해서는 libnode-dev 패키지를 강제로 제거하고, 에러가 발생한 패키지를 다시 설치합니다.

$ sudo apt remove libnode-dev
$ sudo dpkg --force-all -r nodejs_16.20.0-deb-1nodesource1_amd64
$ sudo apt install -f
$ sudo apt update

이제 nodejs 패키지를 다시 설치할 수 있습니다.

$ sudo apt install -y nodejs

그랬더니 에러 내용 중 충돌난 패키지가 libnode-dev에서 libnode72:amd64로 변경되었습니다.

[그림 2] apt install 수행 시 libnode72:amd64 충돌 에러

이번에는 libnode-dev 패키지와의 파일 중복 문제를 해결하기 위해 다음 명령들을 수행합니다.

$ sudo apt remove libnode72:amd64
$ sudo dpkg --force-all -r nodejs_16.20.0-deb-1nodesource1_amd64
$ sudo apt install -f
$ sudo apt update

그리고 다시 nodejs 패키지를 설치해보았습니다.

$ sudo apt install -y nodejs
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
...
Use 'sudo apt autoremove' to remove them.
The following NEW packages will be installed:
  nodejs
0 upgraded, 1 newly installed, 0 to remove and 60 not upgraded.
Need to get 0 B/27.2 MB of archives.
After this operation, 128 MB of additional disk space will be used.
(Reading database ... 66824 files and directories currently installed.)
Preparing to unpack .../nodejs_16.20.0-deb-1nodesource1_amd64.deb ...
Unpacking nodejs (16.20.0-deb-1nodesource1) ...
Setting up nodejs (16.20.0-deb-1nodesource1) ...
Processing triggers for man-db (2.10.2-1) ...

$ node -v
v16.20.0

충돌난 패키지들을 강제로 제거하고, 패키지 업데이트하여 다시 설치하여 문제를 해결하였습니다.

다른 패키지로 동일한 에러가 발생하면 이와 같이 해결할 수 있을 것입니다!