통신사 공유기는 못 들어오십니다

빌어먹을 통신사 공유기!!!!

통신사 공유기세요? 그거 안돼요 버리세요

그래도 하시겠다구요? 그럼 따라하시다가 안되면 일단 통신사 공유기 탓입니다

공유기 바꾸시는게 정신건강에 좋아요

(참고로 될 수도 있긴하다! 진짜로!! 가능성이야 있지만 나는 아니었음)

 

어떻게 알았냐고요? 15시간을 꼬박 갖다 박고 나서 알게됐어요...

그래서 어떻게 했냐고요? 공유기를 갈아치웠습니다

농담 아니다 진짜 샀음...

공유기는 TMI는 아래에

더보기

공유기는 대충 아래 조건에 따라 샀다

1) wifi6 되는거
2) 4년 이상 쓸만한거
3) 브로드컴 칩셋 (BCM)

 

wifi6는 뭐 속도 차이가 워낙 나니까 샀고, 브로드컴은 다들 칩셋 좋은거 사야한다~ 이러길래 진짜 차이가 있나 싶어서 사봤다. 근데 사실 나는 4년 전에 산 것도 그렇게 느리다는 생각 못느끼며 잘 쓰고 있었다

(브로드컴 칩셋도 아닌데 고장난 적 한번도 없음)

그래서 비슷한 사양의 가성비 모델인 AX3000SM이 있는데 이걸 샀어도 괜찮겠단 생각을 했음

근데 전자기기를 좋아하는 나로썬 지금까지 써본 공유기만 10종이 넘는데 확실하게 하나 말할 수 있다

너무 저가형 모델은 별로라는 것

값이 너무 싸면 지원하는 대역폭, 속도가 좁거나 느려서, 어느정도 돈을 쓰는게 좋다는 생각은 한다

(한번 사면 오래 쓰는 물건이니까)

 

그래도 8만원까진 필요 없었겠지만, 나는 기왕 사는거 성능이 좋은걸 사고 싶었다 히히..

AX3000SM과 AX3000BCM의 차이는 칩셋으로 듀얼코어 (1.3 GHz)와 쿼드코어 (1.7GHz) 차이다

 

뭐 무튼 교체하고 나니 기존에 쓰던 LGU+ GAPM-7100보단 확실히 wifi 빠른게 체감되더라

이 부분에서 만족! (다만 나같은 기기덕후가 아니라면, 가성비 모델로도 충분할 것 같단 생각도 들었던 구매였음)

사설이 길었는데, 아무튼 8만원짜리 Certbot 인증 지금 시작합니다

시작 전에 확실히 짚고 가야하는 것들

- 80, 443 포트를 열어뒀는지?

- DNS 주소의 IP가 내 서버의 IP가 맞는지?

- 통.신.사.공.유.기로 시도하고 있지는 않은지?

certbot으로 SSL 인증받는 방법

일단 우리는 아래와 같은 순서로 진행할 것이다

1) 디렉토리 구조 설명 (내 환경이 어떠했는지)
2) docker-compose.yml 작성 (Nginx와 certbot 컨테이너 세팅)
3) nginx의 .conf 파일 작성 (인증서 없을 때, 443 없는 버전)
4) 컨테이너 실행
5) SSL 인증서 발급 테스트 (--staging 옵션 O)
6) SSL 인증서 발급 (--staging 옵션 X)
7) nginx의 .conf 파일 수정 (인증서 있을 때, 443 있는 버전)
8) 컨테이너 재실행

목록만 보면 길다

근데 초반 3번까지만 뭘 좀 해야하고, 그 이후부턴 명령어 한줄이면 끝난다

세분화해서 진행하지 않으면 계속 꼬이길래 세분화했음

모두가 한큐에 해결되길 바라면서 마저 작성해보겠다

 

ps. 여기서 쓸 URL은 testorgforpost.duckdns.org로 포스팅을 위해 발급 받은 URL이다

따라서 이 부분을 각자의 URL로 치환해서 진행하면 된다

1. 디렉토리 구조 설명 (내 환경이 어떠했는지)

내 디렉토리 구조는 아래와 같았다

달라도 된다 그냥 경로 설정만 각자 환경에 맞춰서 해주면 됨

docker-compose/
├── docker-compose.yml
├── certbot/
│   ├── conf      		# 인증서 및 설정 파일이 저장됨
│   └── www       		# 웹루트: 인증 도전(challenge) 파일들이 저장됨
└── nginx/
    ├── conf.d			# Nginx 설정 파일
    └── html      	 	# 정적 웹 파일(예: index.html)

특히 nginx/html에는 index.html이란 샘플 html을 만들어줄 것인데 아래 코드 복붙하면 된다

<!DOCTYPE html>
<html>
<head>
    <title>Welcome to nginx!</title>
</head>
<body>
    <h1>Welcome to nginx!</h1>
</body>
</html>

성공하면 아래와 같은 페이지를 보게될 것이다

2. docker-compose.yml 작성 (Nginx와 certbot 컨테이너 세팅)

services:
  nginx:
    image: nginx:latest
    container_name: nginx
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d
      - ./nginx/html:/usr/share/nginx/html
      - ./certbot/conf:/etc/letsencrypt
      - ./certbot/www:/var/www/certbot
    restart: unless-stopped

  certbot:
    image: certbot/certbot
    container_name: certbot
    volumes:
      - ./certbot/conf:/etc/letsencrypt
      - ./certbot/www:/var/www/certbot
    restart: unless-stopped

3. nginx의 default.conf 파일 작성 (인증서 없을 때, 443 없는 버전)

아직 인증서가 없기 때문에, HTTP만 적용된 버전을 준비했다

나는 기본 세팅을 따라가서 default.conf이지만 그냥 개인 커스텀된 nginx.conf여도 상관없다

이 부분에서 443이 적용된 부분까지 전부 작성해서 진행하면 nginx가 실행도 전에 에러만 토해낸다

(쾅쾅쾅!! 인증서 달라고!!)

 

그러니까 HTTP만 적용한걸로 도커를 띄워놓고, HTTPS는 인증서 작업 진행 후에 수정해서 띄울 것이다

# 임시 HTTP 전용 서버 (인증서 발급 전)
server {
    listen 80;
    server_name testorgforpost.duckdns.org;

    location /.well-known/acme-challenge/ {
        alias /var/www/certbot/.well-known/acme-challenge/;
        try_files $uri =404;
    }

    location / {
        # 임시로 정적 페이지를 제공
        root /usr/share/nginx/html;
        index index.html;
    }
}

4. 컨테이너 실행

docker compose up -d

5. SSL 인증서 발급 테스트 (--staging 옵션 O)

staging은 쉽게 말해서 테스트용 인증서 발급이다

진짜는 아니고 발급이 제대로 되는지 테스트정도로 생각하면 됨

그래서 여기서 통과되고 나면 나중에 --staging을 지우고 제대로 발급 받는 과정을 거쳐야 함

 

이 옵션을 잊지말자!!

실수로 이 옵션을 지우고 시도하다가 5회 이상 틀리면, 7일간 해당 도메인으로 신청할 수 없다

어떻게 알았냐구요...? ㅎㅎ 저도 알고 싶지 않았어요 ㅠ

# 템플릿
docker run --rm \
  -v $(pwd)/certbot/conf:/etc/letsencrypt \
  -v $(pwd)/certbot/www:/var/www/certbot \
  certbot/certbot certonly --webroot -w /var/www/certbot \
  --email {이메일} \
  --agree-tos \
  --no-eff-email \
  --staging \
  -d {DNS 주소}

# 예시
docker run --rm \
  -v $(pwd)/certbot/conf:/etc/letsencrypt \
  -v $(pwd)/certbot/www:/var/www/certbot \
  certbot/certbot certonly --webroot -w /var/www/certbot \
  --email test@gmail.com \
  --agree-tos \
  --no-eff-email \
  --staging \
  -d testorgforpost.duckdns.org

위 옵션을 실행하고 아래와 같은 사진을 보게 된다면, 인증서 발급 테스트에 성공한 것이다

6. SSL staging 인증서 삭제 후 재발급 (--staging 옵션 X)

별것 없다 5번에서 발급된 인증서를 삭제하고, --staging 옵션을 제거한 아래 명령어로 진짜 인증서를 발급하면 된다 (삭제하고 재발급... 이 방법이 제일 쉬웠다)

 

기존 인증서 삭제

- 이 부분은 환경이 모두 다를 수 있으니, 경로를 확인하고 실행하는게 좋겠다

# 템플릿
sudo rm -rf $(pwd)/certbot/conf/live/{URL}
sudo rm -rf $(pwd)/certbot/conf/archive/{URL}
sudo rm -rf $(pwd)/certbot/conf/renewal/{URL}

# 예시
sudo rm -rf $(pwd)/certbot/conf/live/testorgforpost.duckdns.org
sudo rm -rf $(pwd)/certbot/conf/archive/testorgforpost.duckdns.org
sudo rm -rf $(pwd)/certbot/conf/renewal/testorgforpost.duckdns.org.conf

삭제 안하고 재발급하면 아래처럼 기존 인증서의 기한이 남았다면서, 기존 인증서를 유지할지 리뉴얼할지 물어본다

여기서 2번 진행해서 덮어 씌우면 되지만, 내가 진행하는 스크립트 상 입력이 불가능한 상태로 넘어가니 EOFError가 떠서 그냥 삭제하는 쪽을 택했다

 

이부분 해결이 가능하시다면 기존 것을 삭제 안해도 무방함

 

--staging 옵션 지우고 발급

docker run --rm \
  -v $(pwd)/certbot/conf:/etc/letsencrypt \
  -v $(pwd)/certbot/www:/var/www/certbot \
  certbot/certbot certonly --webroot -w /var/www/certbot \
  --email ssafytou2@gmail.com \
  --agree-tos \
  --no-eff-email \
  -d testorgforpost.duckdns.org

정상 발급되면 아까처럼 발급되는 것을 확인할 수 있다

7. nginx의 .conf 파일 수정 (인증서 있을 때, 443 있는 버전)

인증서를 적용해두었으니, HTTPS로 접속해야하고 그 접속에 대한 응답 페이지 또한 만들어두어야 한다

아래는 443을 추가해준 버전의 .conf 파일이다

server {
    listen 80;
    server_name testorgforpost.duckdns.org;  # 실제 도메인으로 변경

    # ACME challenge 요청 처리를 위해 alias 사용
    location /.well-known/acme-challenge/ {
        alias /var/www/certbot/.well-known/acme-challenge/;
        try_files $uri =404;
    }

    # HTTP 요청은 HTTPS로 리다이렉트
    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    server_name testorgforpost.duckdns.org;  # 실제 도메인으로 변경

    # 발급받은 인증서 경로 (Certbot이 저장하는 위치)
    ssl_certificate /etc/letsencrypt/live/testorgforpost.duckdns.org/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/testorgforpost.duckdns.org/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;

    location / {
        root /usr/share/nginx/html;
        index index.html;
    }
}

8. 컨테이너 재실행

docker compose down		# 컨테이너 중지
docker compose up -d 	# 컨테이너 시작

적용이 잘 되었다면... 아래처럼 HTTPS로 접속해도 페이지가 뜰 것이다..!

 

TMI - 공유기를 의심한 이유

뭐만하면 냅다 그냥 connection 안된다고 하고 authorization 없다고 하고 땡깡피고 난리도 아니었다

이유도 모르겠으니 환장할 노릇

ubuntu@ip-172-26-7-32:~/docker-compose$ docker run --rm \
>   -v $(pwd)/certbot/conf:/etc/letsencrypt \
>   -v $(pwd)/certbot/www:/var/www/certbot \
>   certbot/certbot certonly --webroot -w /var/www/certbot \
>   --email test@gmail.com \
>   --agree-tos \
>   --no-eff-email \
>   --staging \
>   -d testorgforpost.duckdns.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Account registered.
Requesting a certificate for testorgforpost.duckdns.org

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
  Domain: testorgforpost.duckdns.org
  Type:   connection
  Detail: {IP 주소} : Fetching http://testorgforpost.duckdns.org/.well-known/acme-challenge/5oSadJRPozLyD7MSphPCUwAN7EjJst2NanvfiHhAjrs: Connection refused

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

여기서 몇번이나 시도하고 실패했는지 셀수도 없다...

 

그래서 두가지 방법을 생각했다

1) 다른 지역에 있는 내 서버에 SSL 인증 테스트를 한다
2) AWS에 SSL 인증 테스트

 

1번은 건드리고 싶지 않았고, 다행히 우연찮게 남는 AWS가 있어서 여기에 똑같은 순서와 똑같은 방식과 똑같은 DNS로 DNS에 등록된 IP만 바꿔서 테스트했다

 

한번에 해냈다...

진짜 허무하고 열받았음

 

그래도 혹시나 싶어서 1번도 진행해봤다 (여기까지 오니까 오기가 생겨서...)

잘됨 ㅋㅋㅋㅋㅋㅋ 하... 

 

그러면... 진짜 의심해볼게 공유기 뿐이었다

왜냐면 1번 조건의 서버는 에 물려있기 때문에 더더욱!

아니 동일한 조건에 공유기만 다르고 모든게 똑같다면?!?!

부셔버릴 저놈이다!

사실 SSL 인증은 도메인이 내 것인지 증명하는 과정에서 이뤄진다

무슨 말이냐면 ratatou2.tistory.com에 SSL 인증을 받았으면, 추후에 ratatou2.tistory.com과 연결된 IP는 바뀌어도 된다

왜냐? 해당 도메인이 내것이라는 것을 이미 증명했으니까

 

이 말인즉, 1번 서버에서 SSL 인증을 받고, ratatou2.tistory.com에 연결된 IP를 비링크 서버로 바꾸면?

문제 없이 잘 쓸 수 있다!

SSL 인증은 해당 도메인의 주인이 맞는지 체크하는 것이라서, 인증받고나면 IP는 바뀌든 말든 상관없으니까

 

그래서 그냥 ipTIME에 물려있는 1번 서버에서 갱신 받은걸로 LGU+ 공유기에 물려있는 비링크 서버에 집어넣고, DuckDNS에 가서 도메인에 연결된 IP를 비링크 서버로 바꾸려고 했다

(실제로 1번 서버의 키를 비링크 서버로 가져온 뒤, 접속하니 성공했다)

 

그러나 SSL 인증은 90일이면 만료되기 때문에 그 전에 갱신이 필요하고, 그때가면 분명 비링크 서버에서 갱신은 불가능할 것이다

(SSL 발급 받는 과정처럼 80, 443 포트를 이용해서 통신 후에 허가 인증을 해줄 것이고, LGU+ 공유기는 이 과정을 또 막을테니까)

 

매번 1번에서 갱신받고 비링크 서버에 전달하는 스크립트나 로직을 짜도 됐겠지만, 귀찮기도 하고 뭣보다 한 서버가 기본적으로 다른 서버에 의존적인 형태가 맘에들지 않았음

그럴거면 K8S(쿠버네티스)를 시도해봤겠죠?

 

그렇다고 LGU+ 공유기가 duckdns를 지원하는 것도 아니고, DNS 인증 방식이 가능한 것도 아니었다.. (이런 쓰레ㄱ..읍읍)

 

그래서 그냥 공유기를 샀다

그리고 역시나 단번에 해결됐다 (통신사 공유기는 부셔버리..읍읍)

으아아앙 디져! 디져!

요약

결과적으로 내 통신사 공유기였던 LGU+ GAPM-7100는 포트포워딩은 되지만 80, 443으로 들어오는 특정 요청은 필터링 하는듯했다

그에 대한 반증으로 공유기만 바꾸고 테스트했는데 바로 통과됐다는 점 (다르게 행한 것은 단 하나도 없었다)

 

그러니까 나는 앞으로 통신사 공유기를 만났다? 반으로 갈라버릴 ipTIME으로 바로 교체할 것이라는, 그것이 정신 건강에 이롭다는 교훈을 얻고 SSL 인증도... 무난히 해결할 수 있는 사람이 되었다...

'Linux' 카테고리의 다른 글

Certbot 자동갱신 하기 (feat. Docker & Crontab)  (0) 2025.02.27
서버 간 핑(ping), 통신 테스트 (feat. nc, nmap, python)  (0) 2025.02.14
HDMI 뺐다 끼면 소리 안나옴 (feat. Beelink S12 Pro)  (0) 2025.02.12
Ubuntu 홈 디렉토리에 외장하드 마운트 하는 방법  (0) 2025.01.30
우분투 HDMI 재연결 시, 음성 안나오는 이슈 해결  (0) 2025.01.27

티스토리툴바