[On-premise] Ubuntu server로 구성하는 Web 3Tier 아키텍처

 

 

Web 3Tier 아키텍처

https://jaws-coding.tistory.com/9

 

3계층 아키텍처는 애플리케이션을 프레젠테이션 계층, 사용자 인터페이스, 데이터가 처리되는 애플리케이션 계층 그리고 애플리케이션과 관련된 데이터가 저장 및 관리되는 데이터 계층이라는 3개의 계층으로 나뉘는 아키텍처이다.

3계층 아키텍처의 주요 장점은 각 계층이 자체 인프라에서 실행되기 때문에 각 계층이 별도의 개발 팀에 의해 동시에 개발될 수 있으며 다른 계층에 영향을 주지 않고 필요에 따라 업데이트되거나 확장될 수 있다.

• 개선된 확장성: 필요에 따라 어느 계층이든 다른 계층과 독립적으로 확장할 수 있다.
• 개선된 신뢰성: 한 계층의 가동 중단은 다른 계층의 가용성 또는 성능에 별로 영향을 미치지 않는다.

 

3계층 구조의 특징은 모든 통신이 애플리케이션 계층을 통과한다는 것이다. 따라서 프레젠테이션 계층과 데이터 계층은 서로 간에 직접 통신할 수 없다.

• 개선된 보안: 프레젠테이션 계층과 데이터 계층이 직접 통신할 수 없으므로, 잘 설계된 애플리케이션 계층은 내부 방화벽의 일종으로 작동하여 SQL 인젝션 및 기타 악의적 공격을 방지할 수 있다.

 

 

참조: https://www.ibm.com/kr-ko/topics/three-tier-architecture

 

 

 

 

 

네트워크 구성

 

 

 

 

3티어 아키텍처를 구현해보자.

 

Web server: apache2 -> 정적인 메인 페이지만 제공

WAS: apache2, php8.1, php8.1-mysql -> 팀원의 리스트와 정보를 확인하는 동적 페이지 제공

DB server: mariadb -> 팀원의 데이터를 제공

 

Web server는 WAS와만 통신하고 DB에 접근할 수 없어야 한다.

이를 위해 router 역할의 우분투의 Iptable에 forward 규칙을 정해 줄 것이다.

 

 

 

 

내부망 설정

라우터 세팅

 

라우터는 Ubnutu의 라우팅 기능을 활용하여 진행했다.

 

netplan에서 GW로서의 ip를 넣어주자.

 

Sudo netplan apply

sudo vi /etc/sysctl.conf    #conf파일에서 라우팅 기능 활성화

net.ipv4.ip_forward=1

 

 

이후 재시작하여 net.ipv4.ip_forward =1이 적용되었는지 확인하자.

 

sudo sysctl net.ipv4.ip_forward

 

 

 

 

 

Ubnutu에서 라우팅 경로 세팅

 

WAS와 DB는 내부망에서만 접근 가능하므로 기본 라우터를 내부 라우터로 설정한다.

Bastion과 Web server는 외부와 통신하므로 기본 라우터를 외부 라우터로 설정한다.

이외의 경로는 직접 GW를 지정해주자.

 

디폴트 게이트 웨이 설정 명령어

sudo ip route add default via <게이트웨이_IP> dev enp0s3

 

라우팅 경로 설정 명령어

sudo ip route add 192.168.46.0/24 via <게이트웨이_IP> dev enp0s8

 

 

세팅 후 route로 경로 확인도 해주자.

 

 

잘못 삽입했다면, 아래 명령어로 삭제한다.

route del default gw [IP주소]

route del -net [network_IP] netmaks [subnet_mask] gw [IP주소]

 

 

 

 

 

 

 

프록시 설정

Web Server는 Proxy pass로 동적 로직을 WAS로 넘겨주어야 한다.

 

 

 

프록시란?

프록시는 리버스와 포워드 두가지 타입으로 나뉜다.

 

 

 

리버스 프록시는 아래 웹서버/WAS 앞에 놓여 있는 것을 말한다.

클라이언트는 웹서비스에 접근할때 웹서버에 요청하는 것이 아닌, 프록시로 요청하게 되고, 프록시가 배후(reverse)의 서버로부터 데이터를 가져오는 방식이다.

클라이언트쪽으로 데이터(response)를 밀어주는게 포워드라면, 그 반대편인 서버 쪽으로 데이터(request)를 밀어주는 것이 리버스 프록시 라고 보면 된다.

(참조: https://inpa.tistory.com/entry/NETWORK-📡-Reverse-Proxy-Forward-Proxy-정의-차이-정리)

 

우리는 내부 WAS로 전달하는 Web server이므로 리버스 프록시이다.

이러한 리버스 프록시는 로드 밸런서의 역할이기도 하다.

 

 

 

Apache 프록시 세팅

Apache2 Web server에 다음 프록시 설정을 적용해주자.

sudo vi /etc/apache2/sites-available/000-default.conf

 

<VirtualHost *:80>		 # 80번 포트 접근 시의 세팅
ProxyRequests Off        #off가 리버스, on이 포워드
        ProxyPreserveHost On
        <Proxy *>	
        Order deny,allow
        Allow from all		#ip 차단 없이 모두 허용
        </Proxy>
#webserver/team1접근시 WAS서버의 team_data.php로 접근하게 함.
        ProxyPass /team1 http://192.168.76.3:80/team_data.php	
 
#반대로 클라이언트에게 응답이 가는 설정이므로 동일하게 구성
        ProxyPassReverse /team1 http://192.168.76.3:80/team_data.php
</VirtualHost>

 

 

 

참조: https://enginnersnack.tistory.com/15

 

 

 

적용 후 proxy 설정을 켜준다. 

a2enmod proxy        #apache2 enable mode proxy = a2enmode

a2enmod proxy_http

systemctl restart apache2

 

 

이 세팅을 통해 web_server_IP/team1 으로 접속시 WAS 서버의 team_data.php로 프록시 된다.

 

 

이제 우리의 팀 페이지를 만들어 줄 것이다.

 

 

 

 

 

 

 

팀원 조회 서비스 페이지 구현

 

데이터 베이스 생성

MariaDB에서 사용할 데이터베이스 만들어주자.

 

create database team1;

CREATE TABLE user(ID varchar(100), NAME varchar(100), AGE varchar(100), GOAL varchar(100), SKILL varchar(100));  

 

#user 테이블을 만들고 우리 팀원들을 모두 넣어주자.

insert into user (ID,NAME,AGE,GOAL,SKILL) values ('jin','이**', '24', 'DevOps', 'aws');

insert into user (ID,NAME, AGE,GOAL,SKILL) values ('joohy','박**', '25', 'SA', 'security');

insert into user (ID,NAME, AGE,GOAL,SKILL) values ('sjk','심**', '30', 'SA', 'VMware');

insert into user (ID,NAME, AGE,GOAL,SKILL) values ('soo','안**', '31', 'SA', 'python');

 

 

 

팀 조회 php 코드

이제 php 코드를 작성해보자.

 

 

 

 

이 코드에서는 팀원을 모두 출력하고, 특정 팀원의 id를 질의하면 세부 정보를 보여주도록 만들었다.

WAS에 적용

이 파일은 WAS에서 동작해야 하는 동적 파일(DB에서 데이터를 불러오는 작업이 필수)이므로 WAS로 옮겨준다.

sudo cp /home/jin/team_data.php /var/www/html/     # Apache 폴더( /var/www/html/ )에 이동

 

 

내부망 안인 Bation에서 WAS에 접속하면 잘된다.

 

Member id에 특정 팀원의 ip를 넣으면 자세한 정보가 나온다.

 

 

 

 

 

외부망 설정

외부 라우터 ip 설정

 

 

 

NAT 세팅

NAT 적용 전에 192.168.11.3으로 접속하여 확인해보자.

 

 

 

#iptable에서 Destination Nat와 Source Nat의 변경

sudo iptables -t nat -A PREROUTING -d 100.1.2.251 -j DNAT --to-destination 192.168.11.3

sudo iptables -t nat -A POSTROUTING -s 192.168.11.3 -j SNAT --to-source 100.1.2.251

 

sudo iptables -t nat -A PREROUTING -d 100.1.2.250 -j DNAT --to-destination 192.168.10.3

sudo iptables -t nat -A POSTROUTING -s 192.168.10.3 -j SNAT --to-source 100.1.2.250

sudo iptables -t nat -L -v -n --line-number

 

 

이때 외부 망 대역인 10.1.2.0/24로 접속가능한 외부 IP를 만들면 안된다.

그 이유는 외부 망의 PC가 자신의 대역대로 인식하여 GW로 패킷을 보내지 않고,

같은 대역대 내에서만 ARP 브로드캐스트를 날리기 때문에 패킷이 GW로 전달되지 않는다.

(GNS3나 Packet Tracer에서는 라우터가 수신할 수 있지만, Ubnutu를 router로 활용하기 때문에 수신되지 않는 것 같다.)

 

 

 

외부에서 공인 ip로 접속

메인 페이지는 Web Server에서 접속

 

다른 페이지는 WAS로 동적 로딩

 

 

 

 

 

Bastion을 통해 DB접속 (터널)

배스천의 공인 IP로 ping이 잘 전달된다.

 

 

 

SSH 터널 옵션은 Bastion(100.1.2.250 = 192.168.66.3)과의 SSH 연결을 위한 옵션.

 

 

 

설정은 SSH 연결된 Bastion에서 무엇을 할지에 대한 설정이므로, DB(192.168.56.3)로의 접속을 세팅한다. 우리는 DB로 연결할 것이므로 3306 port에서 root의 아이디와 비번을 입력한다.

 

 

 

 

정상적으로 접속이 된다.

 

 

 

 

 

 

WEB Server에서 DB로의 접근차단

 

3Tier에서는 presentation 계층이 DB 계층으로 접근해서는 안된다.

우리는 ubuntu의 FORWARDING 기능으로 중계하고 있으므로 iptable의 forward 옵션에서 차단하자.

 

sudo iptables -A FORWARD -s 192.168.46.3 -d 192.168.56.3 -j DROP

source(192.168.46.3, Web Server)에서 destination(192.168.56.3, DB)로의 모든 패킷을 차단해버린다.

 

 

 

 

 

핑통신을 포함에 WEB Server에서 DB로의 접근을 모두 차단된다.