왜?
개인서버로 내가 원하는 프로젝트를 운영할 수 있다면 얼마나 좋을까?
전기값만 들고 , 개발서버와 실서비스 서버를 분리하여 내 마음대로 설계, 구축이 가능해진다.
그래서 현재 개인서버를 구축하는 중이다
단기목표는 서버>hypervisor>우분투,window server를 설치 후 우분투 내부에 도커를 설치하여(2020.05.27 구현성공)
지금까지 만든 프로젝트의 api를 aws서버에서 내 개인서버로 운영하는 것이 목적이다.
하지만 목표를 달성하려면 ip, dns, 이런 개념도 알아야됨은 물론이고 보안 이슈도 해결을 해야하므로 상당한 공부가 필요해졌다.
+ 중장기 목표는 서버에 대해서 누구에게 기본적인 원리는 부담없이 설명해주고싶었다.
전부 혼자하신분.. 자세히
서버
인증
요즘 아마존 AWS나 여러 클라우드에 접속할 때에는 기존의 ID/PW 방식의 인증보다는 RSA공개키 암호를 사용해서 해당 서버에 공개키를 저장해두고, 본인은 개인키를 가지고서 접속하는 방식을 많이 사용한다.
간단한 사용법.
본인의 PC(macOS 또는 리눅스)에서 ssh-keygen을 사용한다.
1 | $ ssh-keygen -f ~/.ssh/<저장할파일명> -C <계정아이디>@\<서버주소:포트\> |
이제 ~/.ssh/ 디렉토리에는 luneos 라는 개인키(private key)파일과, luneos.pub라는 공개키(public key) 파일이 생성되어 있다.
원칙적으로 공개키 파일은 외부에 공개하는 용도이고, 개인키 파일만 잘 간직하면 된다. 어차피 본인만 사용할 것이라면, 둘다 어딘가에 숨겨놔도 크게 상관은 없다.
이제 해당 서버에 직접 접속을 하던지, 아니면 관리자에게 요청을하던지 해서
좀전에 생성한 luneos.pub 파일을 그 서버 안에 저장해두어야 한다.
luneos.pub 파일의 내용을 클립보드에 복사해두었다가, 해당 서버의 home 디렉토리에 .ssh 을 생성하고 그 안에 authorized_keys라는 파일을 만든다. (이미 생성되어 있다면 append)
1 | root@qemux86:~# root@qemux86:~# pwd |
그럼 이제부터는 ssh 접속할 때 별도로 ID 와 패스워드를 입력할 필요 없이 아래와 같이 접속하면 된다.
1 | ssh -i <개인키경로> -p 5522 root@<서버ip> |
간단히 원리를 보면 (public키로 메세지를 암호화하면 쌍이되는 private만 해석할수있다.)
- 클라이언트가 서버에 SSH 연결을 요청한다.
- 서버는 랜덤 챌린지(랜덤 데이터 스트링)를 생성해 클라이언트에게 보낸다.
- 클라이언트는 서버로 부터 받은 챌린지(C)를 자신이 가지고 있는 private 키로 암호화해서 암호화 된 메시지를 서버로 보낸다.
- 서버는 클라이언트에서 받은 암호화 된 메시지를 public 키로 해석한 후 그 결과를 2단계에서 자신이 클라이언트에게 보낸 랜덤 챌린지와 일치하는지 확인한다. (public 키로 해석할 수 있는 메시지는 그 쌍이 되는 private 키를 가진 사람만이 만들 수 있기 때문) 일치하면 클라이언트가 인증된 것이다.
기본 구조
Client
최초의 클라이언트로부터 요청 발생> 네이트워크 장비로 수신
Modem
가장 먼저 네트워크 패킷(요청할주소, 내용이 적혀있는 택배와 유사)을 받는 것이다.
통신사로부터 가장 먼저 연결되는 장비
공유기(Cable/DSL Router)
두번째로 네트워크 패킷을 전달 받는 것은 공유기로 보통 iptime, 미크로틱 같은 것
패킷은 공유기에 등록된 Port Forwarding 또는 DMZ 같은 Role에 의해 지정된 단말기에 전달된다.
클라이언트(외부)>모뎀>공유기로 요청전달됨(응답은 반대겠지…)
서버
위의 과정을 통해 페킷이 서버에 전달된다.
ESXI
서버 가상화 아키텍처인
즉, ESXI위에 올리면 윈도우, 우분투가 각각 가상머신으로 가상화 서버가 됨.
맨위의 그림에서 Virtualazation Server이하는 모두 논리적인 구성이므로, 이 위에다가 바로 linux 서버, window서버를 설치하면, 그림에서 Control, Firewall, Proxy, 가상 NAT같은 구성은 사라짐(매우위험함)
즉, 하나가 뚤리면 내부 서버나 단말기들도 공격당할 가능성이 매우 높아지는 구성임
NAT, Proxy, etc… + Server
즉, 가상화 서버 구축후 내부적으로도 Router, 방화벽 등을 구축할 수 있고 구축된 가상화 서버로부터 전달 받은 네트워크 패킷을 Router, Firewall을 거쳐 내부의 네트워크 망으로 전달하게 된다.
따라서 pfSense라는 방화벽이자, 가상의 라우팅 서버를 구성하여 논리적 망분리를 구성할 것이다.
이렇게 되면 “외부>모뎀>공유기>가상화서버>pfSense”순으로 요청 페킷이 통과하게되겠지.
NAT(Network Address Translation)
NAT구성 = 내부 네트워크, 사설망임
위의 그림에서는 개발 NAT, 실서비스 NAT으로 나눠놓음
논리적 망분리가 이뤄지지 않은 네트워크면, 하나 서버가 해킹당하면 다른곳도 접근가능해서 위험.(논리적 망분리를 하고 있는 상위개체가 해킹당하지 않는 이상..)
가상화 서버를 통해 구성된 NAT은 구성하기에 따라 논리적인 망분리를 구축하는 것도 가능한데 가상화 서버 또는 가상화 서버 내 Router또는 Firewall로 부터 전달받은 패킷을 목적지 네트워크가 수신하게 된다.
Proxy(프록시)
내부적인 망분리를 구축한 경우 내/외부의 통신을 위해 프록시 서버를 구축할 수 있다.
보통 웹 서비스를 제공하는 경우 리버스 프록시(Reverse Proxy)환경을 구축하기도한다
포워드 프록시는 요청자들이 요청할때 프록시 서버에서 모아서 해당하는 사이트 접근
리버스 프록시는 요청들이 직접 서버에 들어오는 것이아니라 리버스 프록시 서버가 먼저 요청을 받고 해당하는 내부 서버에 다시 요청.(보안!!)(외부에서 직접 해당서버 접속 불가)
모든 망을 경유하는 하나의 서버를 만들어 볼 예정입니다. 바로 Reverse Proxy 서버를 구축해 볼 예정,
이 Reverse Proxy 는 논리적 망분리가 이루어진 모든 NAT에 다리를 거치고 있어 외부에서 요청된 Domain 등에 따라 접근처리를 해 줄 것이고, 웹 서버가 받는 요청 부하를 줄여줄 수 있도록 고려할 것입니다.(nginx로 사용가능)
Server
모든 네트워크구간을 정상적으로 통과한 요청은 목적지에 도달해 처리가 되고, 발생된 응답 결과는 역순으로> 클라이언트까지 응답반환
나머지는 NAT수를 늘리고
pfSense의 Role 정의는 필요에 따라 커스터마이징 하셔서 자신이 원하는 환경을 구축하시면 되겠습니다.
라우터
외부에서 접속할 수 있는 방법은 3가지
- 포트포워드
- DMZ
- Twin IP
IP주소는 한개일때 서버 여러대
위의구성 참고하기