Azure-네트워크 구성 및 망분리

azure 에서 망분리가 먼저 선행되어야 할 과제이다.
aws 에서의 망분리는 계층적 망분리로 서브넷과 라우팅 테이블을 이용하여 망분리를 구현한다. 하지만 gcp / azure는 망분리의 개념이 좀 다르다.

서브넷을 통한 망분리가 아닌 공인IP의 유무로 망분리를 구현한다.

근래에 구성도를 작성하면서 한편으로 계층적 망구성이 구성도 그리긴 불편한 생각이 들긴한데 그래도 익숙하고 편한데 azure 와 gcp 를 보니까 aws 의 망구성이 관리의 편의성이 떨어지는 느낌이기도 하고..조금 애매한 느낌이 든다.

azure 에서는 어떤 인프라도 리소스그룹안에서 만들어진다. gcp의 프로젝트 개념과도 같다. 그렇지만 좀 다른게 리전에 종속된다.

한국리전은 중부와 남부로 나뉘는데 중부를 azure 에선 중부를 주로 추천하는데 나는 중부말고 남부를 선택했다.

요구하는 바는 구독 그룹네임 리전 리소스 그룹다음에는 virtual network 를 생성하는데 VN은 서브넷을 생성하게 된다.

가상네트웤의 최대 크기는 10.0.0.0/8 까지로 16777216개 주소 를 사용할수 있다.

서브넷을 3개로 나누었고 서브넷은

보안그룹을 서브넷에 설정하여 접근제어가 가능하다.

aws 의 구성의 경우엔 az 별 서비스별 서브넷을 설정했지만 azure 는 az가 명시적으로 지정되지 않아 서비스별 서브넷을 생성해서 사용하는것이 최선으로보인다.

서브넷의 보안그룹으로 막으려면 tag ip id 로 명시적으로 막자.

서브넷별 nsg 가 구성되는게 좋을것 같다.

가상머신은 공용아이피를 없앤 채로 생성한후 나중에 공용IP를 부여할수있었다.

직렬연결은 가상화 머신의 화면을 그대로 포워딩해주는 방식으로 보이며 공용IP가 없는 상태에서도 연결할수 있었다.

굉장히 불편한 부분은 이다음에 발생했는데 lb 는 sku 개념덕분에 혼파망이 되었다.

sku는 basic / standard 두가지로 나누어져있는데

Configures outbound SNAT for the instances in the backend pool to use the public IP address specified in the frontend.

인터넷 통신

기본적으로 VNet의 모든 리소스는 인터넷으로 아웃바운드 통신을 할 수 있습니다. 공용 IP 주소 또는 공용 Load Balancer를 할당하여 리소스에 대해 인바운드로 통신할 수 있습니다. 공용 IP 또는 공용 Load Balancer를 사용하여 아웃바운드 연결을 관리할 수도 있습니다. Azure의 아웃바운드 연결에 대한 자세한 내용은 아웃바운드 연결공용 IP 주소 및 Load Balancer를 참조하세요.

하...모든인스턴스는 인터넷과 통신이 가능하다. 이거때문에 한참을 헤멧다.

nat gw가 필요가 없다..............................충격 막으려면 NSG로 막아라.

그래서 일단 정리하자면 azure 의 모든 네트워크 접근제어는 네트워크 단위가 아니라 NSG에서 모두 컨트롤한다.

선택한 서브넷 'linuxer-subnet-pri(10.0.0.0/24)'이(가) 네트워크 보안 그룹 'pri-sub-sg'에 이미 연결되어 있습니다. 여기에 새 네트워크 보안 그룹을 만드는 대신 기존 네트워크 보안 그룹을 통해 이 가상 머신과 연결을 관리하는 것이 좋습니다.

azure LB사용할땐 가용성 집합을 이용해서 VM을 만든다.

리소스그룹-vpc-subnet-가용성집합-vm-lb 순으로 생성하게 된다.

LB는 베이직과 스텐다드..하 sku 개념이 제일짜증난다.

LB를 베이직으로 생성시에

???같은 가용성 집합인데????

음...이유는 다음에 찾아보기로 하고..

sku 가 스텐다드인경우엔 잘 된다..음 베이직이라 제한이 있는것으로 이해하고 지나가기로 한다.

상태 체크는 로드벨런스 안에서..아니면 zure monitor 을 이용하자.

근데 LB에서 페이지가 뜨는건 잘안됬다 왜지?

그리고 스터디를 마치고 집에와서 백엔드 규칙만 재생성하니 정상적으로 잘됨..뭐야이거..빡치네..

Share