Skip to content

Server 오류 히스토리

Jump to bottom
유동현 edited this page Sep 12, 2022 · 4 revisions

# [2021-09-13 12:22]

  • 상황
    : 프로젝트 폴더를 옮긴 후 기존의 프로젝트 폴더를 삭제하자마자 발생
    : 예산 내역과 명예의 전당 페이지 렌더링 중에 not found file or directory 오류 발생
  • 해결
    : 2021-09-13 13:15 : uwsgi 프로세스 ini 시, 기존의 작동하던 프로세스가 꼬여서 새로운 프로세스가 nginx와 연결되지 못함. 기존의 프로세스가 nginx 와 붙은 채로 떨어지지를 않음
    : uwsgi 관련 모든 프로세스 강제 종료 후 올바른 권한의 계정으로 새롭게 ini 해주었음
  • 분석
    : uwsgi ini 시 프로세스의 effective user 권한이 설계와 다르게 움직이면서, 그에 따른 파일들의 권한도 꼬이게 됨..
  • 추가 방향
    : 서버 권한 및 프로세스 effective user 권한을 분석하고 설계하기

# [2022-01-11 21:20]

  • 상황
    : 07일 금요일 저녁, 홈페이지 도메인과 인증서 상의 도메인 불일치로 인해 브라우저에서 '신뢰할 수 없는 사이트'로 차단하는 현상 발생.
    : 인증서가 갑자기 *.inha.ac.kr 학교 인증서가 걸려버림.
    : 기존 서버는 학교 내부에 위치하고 있었음.

  • 분석

    1. IS 라우팅 오류로 교내 서브넷이 한꺼번에 묶였다?
      => CIDR 방식의 라우팅 테이블 특성 상 address aggregation 할 때 longest mask 가 우선하기 때문에, 해당 가정은 의미가 없다.
      => dns 라우팅 오류라기에는 *.inhabas.com 이 모두 잘 접속되었다. 다만 인증서만 기존 것이 아닌 학교 인증서가 걸렸다.
    2. nginx 까지는 접속이 잘 되는 상황. 로그를 확인해보니 ssl handshake connection close 라는 문구가 눈에 띄게 많이 늘었다.
      => 이번학기에 네트워크 수업에서 tcp handshake 를 배웠던 것이 생각남. 비슷한 방식으로 인증서를 교환하는 프로토콜이라고 판단.
      => 클라이언트와 인증서를 교환하는 서버가 원래는 우리 서버였는데, 중간에 학교측의 서버가 추가되었다는 판단
      => 즉, 게이트웨이 쪽에서 (우리 서버보다 더 앞단에), 먼저 ssh_handshake를 시도하는 새로운 서버가 나타났다.

  • 시도 방법 (08토 ~ 09일)

    1. 학교망 외부에 프록시 서버를 설치 (학교의 게이트웨이 서버보다 더 앞단에서 먼저 인증서 교환 시도)

      1. [클라이언트] -> [dns 서버] -> [aws(프록시서버)] -> [학교망 진입(*.inha.ac.kr)] -> [기존 서버(*.inhabas.com)]
      2. 클라이언트와 프록시 서버가 먼저 인증서를 교환 후 리다이렉트
      3. 결과 : 예상대로 인증서가 제대로 걸리기는 했다. 하지만 한 페이지 로딩하는데 3분 이상이 걸림 + 몇 static 파일들은 ssl_handshake 실패로 전송되지 않음. 굉장히 불안정했다.
      4. 피드백: [프록시 서버]에서 [학교망]에 도달했을 때 두 서버간 ssl 통신을 또 시도하는 느낌이었다. 그 사이에서 매우 비효율적인 통신이 일어나고 있음이 분명했다.
      5. 개선방안: CA 기관이 더 상위(그런 개념이 있을런지 모르겠지만, 지금 생각해보니 검증된 기관은 있어도 그 기관의 인증서끼리 서열은 없는 것 같다.)라면 학교망의 게이트웨이 서버가 ssl 통신을 생략할 수 있지 않을까? 두번째로는, [프록시서버] 에서 [학교망]까지 80포트로 통신하면 https 인증서 교환이 일어나지 않을테니 통신상태가 원할해질 것이라고 생각.

    2. Cloudflare 의 무료 인증서 시스템을 이용하여 서버와 통신을 시도. (dns 서버에서 인증서를 걸어주기 때문에 똑같이 프록시의 개념이라고 봐도 무방한 듯.)

      1. 위의 결과와 같았다. 인증서는 잘 걸렸지만 여전히 매우 비효율적인 통신이 일어나고 있었다. 한 페이지 로딩하는데 수 분이 걸렸다.
      2. 인증서의 종류와는 상관이 없이 ssl 교환을 한다.

    3. [프록시 서버]와 [학교망]사이의 ssl 교환을 성공시키도록 유도.

      1. nginx 에서는 [프록시 서버]와 더 뒷단의 서버 사이의 https 통신을 위해 proxy_ssl_~~ 종류의 기능을 지원하고 있었다.
      2. 앞서 시도했던 방식들은 [학교망]과 [프록시서버] 와의 https 통신을 무시한채 소위 '무대포' 통신 시도를 하고 있기 때문에 혼잡이 발생한다고 생각했다.
      3. 결과: [프록시 서버]의 nginx 를 통해 https 통신을 시도해보았으나, 계속해서 실패했다.
      4. 피드백: 해당 방식은 내가 잘 모르는 부분이 많다. 내가 잘 못하는걸수도.. 또는 내가 제대로 했다면, 학교망 게이트웨이 서버가 인증서를 직접 들고 있는게 아니라, 프록시를 통해 https 인증을 할 수도 있다는 생각이 들었다. 그래서 [프록시서버]와 [학교망] 과의 ssl_handshake 가 제대로 일어나지 않는 걸수도?

    4. 클라이언트 쪽은 https(443), 프록시 서버와 학교망까지는 http(80)을 이용하는 것이다.

      1. 학교망 게이트웨이 서버와의 ssl_handshake 가 문제였다면, 80포트로 요청했을 때 ssl 교환이 일어나지 않기 때문에 정상적으로 작동할 것이다.
      2. 결과: 성공! 응답 속도도 원래대로 돌아왔고, 학교의 인증서가 걸리는 문제를 해결했다!
      3. 피드백: 하지만 이 방식은 사용자를 기만하는 행위. 클라이언트에게는 보안상 문제가 없게끔 보이지만, [프록시서버]에서 [학교망]까지는 http 프로토콜로 통신을 한다. 학교망의 80포트를 들여다보고 있다면 우리 홈페이지 이용자의 정보가 고스란히 다 보일것. 누군가는 당장 이 방법을 사용하자고 말했지만, "만약 내가 이 사이트 이용자라면?" 나는 그런 사이트를 사용하고 싶지 않다는 마음. + 학교 정보통신망 관련 내규를 근거로 이방법은 사용하지 않기로 했다.
여기까지 하고 보니 남는 선택지는 두가지였다.
첫번째로, 학교 정보통신처에 인증서 제약을 받지 않는 서브넷ip를 할당받는 것이고, 두번째는 서버를 외부로 빼는 것이다.
첫번째 방법은 학교의 지원을 받아 서버의 운영비가 들지 않는다는 아주 큰 장점이 있다. 동아리 운영비가 한정되어 있기 때문에 아주 큰 메리트다. 
이를 위해서는 학교 정보통신처에 동아리 담당 교수님께서 직접 문의를 넣으셔야 했지만 교수님 사정상 1~2달 정도는 국내에 안계시는 상황이다. 
`학교 정보통신망 관련 내규`를 찾아 읽고서 알게 된 사실. 사실 교내 내부의 어떤 ip도 공식적인 발급 없이 사용해서는 안되고, ip를 할당 받으면 
mac 주소를 알려야한다는 규정이 있었다. 명백히 지금 교칙을 위반하고 있는 상황이었다. 그래서 1~2달은 어쩔 수 없이 이 방법을 사용하지 못한다. 
(하지만 여태껏 아무도 몰랐다며 80포트를 통해 운영하자는 내부 의견이 있었는데, 보안이슈 + 내규 등을 근거로 옳지 않다고 판단. 거절했다.) 

두번째 방법은 동아리 입장에서는 단점이 매우 명확한 선택지이다. 
서버를 외부로 빼야하는데, 물리 서버를 누군가의 자취방에 옮기거나, aws를 구동해야하는 상황이었다. 
전자는 또 다른 많은 불편함을 야기했기 때문에 aws 저렴한 모델을 사용하여 진행했다. 
(트래픽이 없는 상황에서 평균적으로 램이 3기가 밖에 돌지 않기 때문에 저렴한 모델을 사용할 수 있었다.)
  • 현재 상황 현재는 aws 로 서버 이관이 끝난 상황. 그러나 이와 별개로 dns 호스팅 업체에서 호스팅 문제가 발생하여 dns 서버를 옮겼는데 해당 기관은 cname flattening 을 지원하는 곳이라 naked domain name 을 사용하지 못한다. 기존에 구글 검색을 하면 inhabas.com 이라는 도메인이 나타나는데 현재는 해당 url 로 접속이 불가능한 상태이다. www.inhabas.com 처럼 cname이 있어야만 라우팅을 시켜준다... 도메인 네임을 ip 에 직접 연결하는 것이 아니라 변수처럼 사용하면서 더 유연하고 확장가능하면서 ddos 에 유리한 방식이라고 한다. 또 1987년에 만들어진 DNS specification 에 근거한다고 한다. dns 호스팅 업체의 문제라는 걸 알기까지도 꼬박 하루가 걸렸다... 정말 간절하게 ping, traceroute, 등등 네트워크 수업 시간에 배운거 써먹으면서 고생했다...
Clone this wiki locally