Showing posts with label network. Show all posts
Showing posts with label network. Show all posts

Wednesday, June 14, 2017

라즈베리 파이를 이용한 Stratum 1 NTP 서버 구성 (원제: How to Build a Stratum 1 NTP Server Using A Raspberry Pi )

 라즈베리 파이 모델 B가 2012년 릴리즈 된 이후 수많은 유용한 애플리케이션들이 등장했습니다. 그것들 중 라즈베리파이를 Stratum 1 NTP 서버로 구성해 인터넷과 같은 네트워크에서 시간 동기화에 사용 할 수 있는 기능을 제공하는 것도 있는데 저는 이를 이용해 사무실 전체를 훨씬 효율적으로 만들 수 있었습니다.

Stratum 1 NTP란?

많은 사람들이 이미 NTP에 대해서 잘 알고 있겠지만 이 프로젝트를 시작하기 전, 다시 한 번 짚고 넘어가도록 하겠습니다. 네트워크 타임 프로토콜(NTP - Network Time Protocol)은 네트워크 상의 컴퓨터 시간을 동기화하는데 사용되는 규약이며 협정세계시(UTC - Universal Time Coordinated)를 사용하여 컴퓨터 시계를 밀리 초 혹은 그 이하 단위까지 동기화합니다. 이를 이용하면 네트워크상에 연결된 기본 시간 서버를 통해 전체 네트워크 내의 컴퓨터 시간을 동기화 할 수 있습니다. 이는 일반적으로 번거롭고 비용이 들지 않게 UTC를 이용할 수 있는 방법입니다. 컴퓨터가 UTC 소스에 연결되는 계층은 'strata'로 정의됩니다. Stratum 1 NTP 서버는 특히 위성 항법 시스템 또는 라디오 시계 등 실제 시간을 수신하는 기기와 직접 연결되며 Stratum 2는 Stratum 1 컴퓨터 등에 연결되어 작동합니다.

NTP는 왜 유용한가?

NTP 서버는 UTC 소스의 정확한 시간을 수신해 내부 컴퓨팅 자원의 시간 동기화를 제공하는, 비용 효율적인 솔루션입니다. 시간동기화는 여러 상황에서 중요한 요소가 되는데 예를들어 트러블 슈팅 시 서버 로그를 뒤져볼 때에 시간동기화가 되어 있지 않다면 매우 곤란할 것입니다. 마찬가지로, 분산 프로세스는 정확한 순서를 따르기 때문에 시간의존적이며, 보안플랫폼들 또한 데이터 암호화, 복잡한 인증시스템구현, 사이버 보안 위협 혹은 금융사기로부터 안전한 데이터 입력 및 변환 등을 위해 시간의존적입니다. 또한 수많은 시스템이 상호의존적으로 복잡하게 업데이트가 이루어지는 경우, Kali Linux와 보안매니지먼트를 위한 KrolLDiscovery에서 데이터 암호화 혹은 시스템 복구 등의 과정에서도 시간에 대한 정확성이 요구됩니다. 이러한 정확한 시간 정의를 통해 데이터 침해 가능성을 줄이고 현 시스템의 결함을 파악할 수 있습니다.  $100이 조금 넘는 금액으로 Stratum 1 NTP 서버를 구성함으로써 워크플로를 개선하고 UTC를 사용하는 장점을 모두 취할 수 있습니다.

Stratum 1 NTP Server를 구성하기 위해 필요한 것들:

  • 라즈베리 파이 (512 MB의 메모리를 가진 Model B 이상 권장)
  • PPS 출력을 가진 GPS 모듈 (Adafruit’s Ultimate GPS Breakout 권장)
  • CR1220 대체 배터리
  • 프리미엄 수-수 점퍼 와이어
  • GPS 안테나
  • 기기 보호를 위한 Raspberry Pi 용 케이스
  • SMA - uFL/u.FL/IPX/IPEX RF 어댑터 케이블
  • 하프 사이즈의 Breadboard
  • 선택사항: Chronodot (라즈베리 파이는 하드웨어 시계를 내장하고 있지 않기 때문에 Chronodot는 이 문제를 해결하기에 좋은 대안임)
  • Adafruit Assembled Pi Cobbler Breakout과 Raspberry Pi 케이블

하드웨어 구성하기

제일 먼저, 준비된 모든 퍼즐 조각들을 연결하도록 합시다. 이를위해 GPS / PPS 출력을 Pi의 23번 핀에 연결하고 GPS TXD를 라즈베리파이의 RXD에 연결합니다. VIN에 5V 전력을, GND에 GND을 을 연결합니다. 특정한 트러블슈팅을 찾기 위해서는 GPS RXD에서 Raspberry Pi TXD로 다른 케이블을 연결할 수도 있습니다.
그 다음 접착제를 사용해 브레드 보드를 라즈베리 파이 케이스에 고정하고 브레드 보드 브레이크 아웃 핀을 GPS 브레이크 아웃 보드에 납땜합니다. 그리고 배터리 하우스를 또한 납땜해야합니다. 이 작업이 처음이라면 민감한 하드웨어를 파괴하지 않기 위해 조심스럽게 진행해야 합니다.

운영체제 구성하기

OS 설치의 첫 단계는 Adafruit’s Occidentalis v0.2 이미지를 설치하는 것입니다. 해당 이미지는 Raspberry Pi의 정식 OS인 Raspbian에서는 제공하지 않는 추가 패키지들이 선탑재되어 있습니다. 해당 이미지를 다운로드 받아 다음 명령어를 이용해 SD 카드에 기록합니다.
#dd if=/path/to/occidentalis.img of=/dev/sdz
다음으로 SSH를 활성화하기 위해 SD카드를 마운트 해서 /etc/network/interface 파일을 편집합니다. 이 작업이 완료되면 가상 인터페이스가 보일 것입니다. (이 과정에 대한 설명). 그리고 나서 라즈베리파이를 부팅하고 터미널로 접속합니다.
디폴트 커널은 PPS를 지원하지 않기 때문에 커스텀 커널을 사용해야 합니다. 이를 위해 다른 사람의 3.1 커널 저장소를 사용하겠습니다.

먼저 터미널에서 root 권한으로 Git을 설치하고 다음 저장소를 사용합니다.
#apt-get install git
#git clone https://github.com/davidk/adafruit-raspberrypi-linux-pps.git
다음으로 새 커널과 모듈을 복사합니다.
# cd adafruit-raspberrypi-linux-pps
# cp kernel.img /boot/kernel.img.pps
# cp -a modules/* /lib/modules
변경 사항을 영구적으로 적용하기 위해 "pps-gpio" 모듈이 매 부팅시마다 로드되도록 해야 합니다. 다음 명령어를 사용합니다.
# echo  ‘pps-gpio’  >> /etc/modules
새 커널 적용을 위해 아래 내용을 /boot/config.txt 파일에 덧붙입니다.
kernel=kernel.img.pps
gpu_mem=16
재부팅 하고 나서 다음 명령어로 새 커널로 잘 부팅되었는지 여부와 "pps-gpio"모듈이 로드 되어 있는지 확인합니다.
# uname -a
Linux ntp.example.com 3.1.9adafruit-pps+ #21 PREEMPT Sun Sep 2 10:57:58 PDT 2012 armv6l GNU/Linux
# lsmod | grep pps-gpio
pps_gpio                2314  0 
pps_core                7808  2 pps_gpio,pps_ldisc

NTP 컴파일 하기

하드웨어와 OS가 준비되었으니 이제 NTP를 컴파일할 차례입니다. 오리지널 Raspbian 패키지는 ATOM을 지원하지 않기 때문에 NTP를 직접 컴파일해야합니다. 이를 위해 root권한으로 /etc/apt/sources.list 파일을 열어 다음 내용을 추가합니다.
deb-src http://mirrordirector.raspbian.org/raspbian/ wheezy main contrib non-free rpi
그리고 root 권한으로 다음 명령어를 입력합니다.
# apt-get update
# apt-get build-dep ntp
# apt-get source ntp
# cd ntp-4.2.6.p5+dfsg
Here’s where things get good; 'debian/rules" 파일을 수정해 "- – enable-ATOM" 을 설정에 덧붙입니다. 그리고 "debian/changelog" 파일에 "pps"를 적절한 버전 번호와 함께 덧붙입니다. 그 후, 패키지를 빌드하고 설치합니다.
# dpkg-buildpackage -b
# cd ../
# dpkg -i ntp_4.2.6.p5+dfsg-2pps_armhf.deb ntp-doc_4.2.6.p5+dfsg-2pps_all.deb

NTP 설정하기

Adafruit GPS 모듈은 NMEA GPS 으로 드라이버 20을 사용하기에 "/etc/ntp.conf 파일에 다음 내용을 추가해야합니다.
server 127.127.20.0 mode 17 noselect
fudge 127.127.20.0 flag1 0 time2 0
이 작업이 완료되면 GPS 시계가 "noselect"로 설정되어 "time2"에 대한 정확한 시간을 파악할 수 있습니다. 신호 문제로 NTP가 시간을 받는데에 조금 시간이 걸립니다. NTP를 24시간 동안 실행하고 "/etc/ntp.conf"파일의 "noselect"를 "iburst"로 추가해 PPS 프로세싱을 위한 준비를 마칩니다. 이후 NTP를 재시작합니다.
윤초를 적용하기 위해 다음 셸스크립트를 "/usr/local/bin/leap-seconds.sh"로 추가합니다.
#!/bin/sh
cd /etc/ntp
wget ftp://time.nist.gov/pub/leap-seconds.list &> /dev/null
service ntp restart &> /dev/null
이 작업의 실행을 위해 root 권한의 cron 작업을 스케쥴링합니다.
0 0 31 6,12 * /usr/local/bin/leap-seconds.sh
잊지말고 셸스크립트에 실행권한을 주는 것도 잊지맙시다.
# chmod a+x /usr/local/bin/leap-seconds.sh
마지막으로 "/etc/ntp.conf" 파일을 다시 한 번 열어 다음 내용을 파일 최상단에 추가합니다.
# leap seconds file
leapfile /etc/ntp/leap-seconds.list
이제 마지막으로 다시 한 번 NTP를 재시작합니다. 이제 수많은 컴퓨터를 연결해 동기화할 때에 "/etc/ntp.conf" 파일에 서버를 추가하기 만하면됩니다. 다만, UTC 소스에서 하나의 stratum이 멀어질수록 매 60 마이크로초가 추가된다는 점은 유의할 필요가 있습니다.
Stratum 1 NTP 서버를 구축하는 것은 시간이 많이 걸리고 어려운 작업일 수 있지만, 그 만큼의 가치가 있습니다. 이 NTP 서버를 사용하면 많은 돈을 절약 할 수 있을 뿐 아니라 과거에는 효율적으로 할 수 없었던 작업들이 가능해집니다. 










번역된 컨텐츠입니다.
Red Hat Developers Blog. Samantha Donaldson. https://developers.redhat.com/blog/2017/02/22/how-to-build-a-stratum-1-ntp-server-using-a-raspberry-pi/

Translated article.

Red Hat Developers Blog. Samantha Donaldson. https://developers.redhat.com/blog/2017/02/22/how-to-build-a-stratum-1-ntp-server-using-a-raspberry-pi/

Thursday, May 4, 2017

Azure 클라우드 네트워킹 (원제: Networking to and within the Azure Cloud)

Azure 클라우드에서의 네트워킹



 하이브리드 네트워킹을 어떻게 정의해야 것인가. '가상네트워크로의 연결'이라는 맥락에서 정의한다면 이는 ExpressRoute 프라이빗 피어링이나 VPN 연결 같이 프레미스 자원과 하나 이상의 가상네트워크(VNet)들의 연결이라 있다.   모든 것들은 작동하고 있으며 우리는 이것들을 어떻게 사용하는지 알고 있지만, 이것들은 클라우드 안에서 대체 어떻게 움직이는 것일까. 여기에는 Azure 내장된 가지 이상의 방식이 작동한다.   포스팅을 통해 그것들을 간략하게나마 설명하고자 한다.
  • 하이브리드 네트워킹 연결 옵션
  • 클라우드 내부 연결 옵션
  • 옵션 종합


하이브리드 네트워킹 연결 옵션


기본적으로 4 가지 옵션이 있다.
  • 인터넷 연결
  • 사이트 연결 VPN (Point-to-site VPN)
  • 사이트 연결 VPN (Site-to-Site VPN)
  • ExpressRoute
인터넷 연결
 이름 그대로, 인터넷 연결은 가상 네트워크 내부에 위치한 다른 퍼블릭 엔트포인트를 노출시킴으로써 여러분의 워크로드를 인터넷을 통해 접근가능하도록 준다. 이를 위해 인터넷에 연결되어있는 부하분산장치 이용하거나 아니면 단순하게 VM NIC ipconfig 오브젝트에 퍼블릭 IP 할당함으로써 목적을 달성할 있다이를통해 인터넷상의 모든 것이 해당 가상 컴퓨터에 도달 가능해지며 호스트의 방화벽, 네트워크 보안 그룹(NSG) 사용자 정의 경로 통해 해당 가상 컴퓨터에 연결할 있다. 결론적으로 옵션을 이용해 인터넷을 통한 애플리케이션 공개가 가능하다.

사이트 연결 VPN 혹은 사이트 연결 VPN
  둘은 같은 범주에 속한다. VNet VPN 게이트웨이로 워크스테이션에서 직접 VPN 클라이언트를 이용해 사이트로 연결하거나 온프레미스 VPN 디바이스 Site-to-Site VPN 종말장치 기능을 이용해 연결하며, 이를통해 온프레미스 장치들이 VNet 내부의 자원들로 접근 가능해진다. 아래에서 클라우드 내부에서의 연결에 대해 다시 다룰 것이다.

ExpressRoute
  연결은 ExressRoute 기술 개요 자세히 설명되어 있다. 사이트 VPN 옵션과 마찬가지로 ExpressRoute 사용하면 하나 이상의 VNet 퍼져 있을 있는 리소스에도 연결할 있다. SKU 따라 하나 이상 이하의 VNet 연결을 허용하며 프리미엄 애드온 이용시 대역폭에 따라 최대 100 까지 연결 가능하다. 내용 또한 아래의 클라우드 내부 연결 옵션에 다시 설명하겠다.

Background


 클라우드 내부의 네트워킹에 대해 자세히 알아보기 전에VNet 개념 VNet 이상으로 구성하는 이유에 대해 이해가 필요하다
 VNet 개념을 설명한 문서 따르면, 이는 '사용자의 니즈에 맞게 Azure 내에 만들어진 고립된 네트워크' 요약할 있다예를 들어, 가상 머신을 프레미스에서 Azure 이동하기 시작한다면 작업이 필요할 것이다. 당신이 IP 주소 공간을 선택하므로 클라우드로 이전하기 전에 IP 주소 할당을 계획하는 것이 중요하다. Azure 당신 회사의 데이터센터를 확장한다면 당신은 IP CIDR 블록 혹은 클래스리스 도메인 라우팅 등에 대해서 고려해야 것이다.
 이제 VNet 무엇인지 조금 이해했다. 그럼 여러개의 VNets 도움이 되는 것일까? 기업은 서로 분리해두어야 필요가 있는 여러 비즈니스 라인을 보유하고 있는 경우가 있기 때문이다. 이것은 다른 비즈니스 단위로 인보이스를 발행하거나 서로 다른 가상 네트워크 관련 요소들 (네트워크 보안 그룹, 사용자정의 경로 ) 각각 관리해야 하는 이슈 등이 관련되어 있다.

클라우드 내부 연결 옵션
 비즈니스 라인들 간의 데이터 교환 혹은 가상 네트워크 IP 연결 시에 Azure 3 가지 네이티브 옵션을 제공한다.
방법들이 갖는 기능과 효과를 비교해 보자.


VPN 통한 VNet-to-VNet

 VPN 통해 2 개의 VNets 서로 연결되어 있는 경우 가상 네트워크의 라우팅 테이블은 다음 그림과 같다.
 2 개의 VNet 만으로도 흥미롭지만, 스케일을 키워보자.


 VNet4 VNet5 라우트 테이블은 VNet3 도달하는 경로를 나타낸다. 하지만 VNet4 VNet5 접근할 없는데, 이를 해결할 가지 방법이 있다.
  가지 방법을 사용하면 3 개의 VNet 모두가 서로에게 접근할 있다. 당연히 이는 많은 수의 VNet 구성하는 경우에도 확장가능하다.


ExpressRoute 통한 VNet-to-VNet

 하나 이상의 VNet 동일한 ExpressRoute 서킷에 연결 재미있는 부작용을 초래한다. 예를 들어 동일한 ExpressRoute 서킷에 연결된 2 개의 VNets 있는 경우의 라우팅 테이블은 다음과 같다.


 흥미롭게도 VNets MSEE (Microsoft Enterprise Edge) 라우터를 벗어나지 않고 서로 통신할 있는데, 이는 서로간의 통신을 위해 Microsoft 백본 떠날 필요가 없다는 것을 의미한다. 이것이 중요한가. 이는 VNets 통신시 추가적인 요금부과가 없도록 준다. 요컨대, ExpressRoute Premium 서킷 사용할 경우 동일한 지역 또는 글로벌 범위에서 VNets간에 통신하는 것이 가능하다. , 전세계의 Microsoft 백본을 사용하여 여러 VNets 함께 연결할 있으며, 이렇게 동일한 ExpressRoute 서킷에 연결된 VNet-to-VNet 트래픽은 요금이 부과되지 않는다. 아래 그림은 동일한 ExpressRoute 서킷에 연결된 3개의 VNet 보여준다


 위의 그림에서 VNet 서브넷의 Effective Route Table 나타나는 여러 경로를 있다.


가상 네트워크 피어링을 이용한 VNet-to-VNet

 복수 VNet 연결을 위한 마지막 선택지는 단일 Azure 리전 내에서 사용 가능한 가상 네트워크 피어링이다. 2 개의 VNet 피어링 배열은 VNet 본질적으로 1 개의 가상 네트워크 것처럼 작동하지만 NSG 라우트 테이블을 사용하여 통신을 제어 있다


 이를 허브와 스포크 형태의 토폴로지로 표현하면 다음과 같다.


 피어링은 VNet 넘어 전파되지 않으므로 HR VNet Marketing VNet 직접 대화 없지만 HR, 마케팅 엔지니어링의 VNet 모두 도메인 컨트롤러, 모니터링 시스템, 방화벽 또는 기타 Network Virtual Appliance (NVA) 등과 같은 공유 리소스를 포함하는 허브 VNet 대화 있다
 그러나 VPN 경우와 같이 VNet 서로 통신 있어야 한다면 다음과 같은 토폴로지를 참고할 있다.  명확한 이해를 위해 완전히 메쉬되지 않은 형태의 토폴로지를 준비했다. ( 경우 HR VNet Engineering VNet 직접 대화 없다). 이것으로부터 아이디어를 얻을 있을 것이다.


 VNet 피어링을 사용할 공유 가능할 있는 중요한 리소스 하나는 게이트웨이(VPN ExpressRoute 모두)이다

  방식을 이용해 각각의 스포크 VNet ExpressRoute 또는 VPN 게이트웨이를 배포하지 않고도 허브 VNet으로 보안 스탬프 게이트웨이 액세스를 중앙 집중화 있다.

옵션 종합 정리

 이러한 여러 방법과 옵션들은 개별적으로 충분히 흥미롭지만 함께 결합되어 강력한 기능을 제공한다.

게이트웨이 공유를 이용한 VNet 전파

 아래의 토폴로지는 간단한 허브 스포크 토폴로지를 보여준다. VNet 피어링 자체에서 전파가 불가능하더라도 게이트웨이(VPN ExpressRoute) 통해 중계 라우팅이 가능하다. VNet 피어링과 게이트웨이 공유를 사용하며 Express Route 사용하는 예는 다음과 같다.

게이트웨이 공유를 이용한 VNet 전파, 2 리전의 1  ExpressRoute 서킷

 하나 이상의 Azure 리전(VNet 피어링은 단일 리전에 만들어진다.) 결합하기 위해서는 다음과 같은 토폴로지를 사용할 있다

 위의 이미지에서 서부 미국 동부 미국 모든 VNet SKU 따라 1, 2, 혹은 10Gbps 속도로 Microsoft 백본 네트워크 내에서 서로 통신한다. 미국 동부 리전을 향하는 패킷은 미국 서부 리전과 시카고 사이에서 물리적으로 라우팅 된다는 점을 주목하자. 이는 시카고가 리전 사이에 위치하기 때문이다.

게이트웨이 공유를 통한 VNet 전파, 2 리전의 2 ExpressRoute 서킷

 시카고보다 ExpressRoute 대한 연결이 필요한 곳인 경우 혹은 단일 ExpressRoute로는 탄력성이 부족할 경우 다음과 같은 토폴로지를 만들 있다.

 프레미스들이 미국 서부 동부에 위치할 경우 프레미스 연결이 나은 지연 시간을 가질 있다. 또한, 동서부 각각에 위치한 VNet 간에 패킷이 전달될 있는 2 개의 ExpressRoute 있다. 이러한 리전들은 서킷 위치와 가깝기 때문에 조금의 레이턴시가 추가되어도 문제가 되지 않는다. 게다가 이러한 구조는 별개의 위치에서 별개의 ExpressRoute 회로를 사용하기 때문에 높은 가용성을 보장한다.

게이트웨이 공유를 통한 VNet 전파, 3 리전의 3 ExpressRoute 서킷

  모델은 많은 서킷과 많은 리전으로 확장 수도 있으며 Azure Networking 툴박스를 사용하여 만들 있는 토폴로지에 대한 이해를 돕기에도 적절하다.

 최적의 라우팅을 위해서는 로컬 서킷이 중요하다. 이에 대해 ExpressRoute 라우팅 최적화 관련된 글을 참고하는 것이 좋다. 글에서는 서부에서 출발해 북유럽을 향하는 패킷이 도쿄의 ExpressRoute 서킷을 통과하지 않도록 설정하는  가상네트워크 최적의 라우팅 설정에 대해 서술하고 있다. 연결에 대해 가중치를 부여함으로써 이러한 목적달성이 가능하다.

BGP 활성화된 VPN 게이트웨이의 공유와 VPN 전파 라우팅을 통한 VNet 전파

 아래의 토폴로지는 BGP 라우팅을 사용하는 VPN 전송의 다른 재미있는 사례를 보여준다. 자세한 내용은 Azure VPN 게이트웨이 BGP 개요에서 확인 가능하다.

  그림에서는 프록시와 같은 매커니즘 없이 Azure 백본을 효과적으로 사용함으로써 개의 시설을 연결하고 있는데 서부 온프레미스 환경에 위치한 사용자가 VPN 통해 북유럽 VNet 연결된 VPN 사용자에 접근할 있도록 작동한다.











번역된 컨텐츠입니다.

Microsoft Azure. by Olivier Martin, Global Black Belt - Azure Networking. https://azure.microsoft.com/en-us/blog/networking-to-and-within-the-azure-cloud/, https://azure.microsoft.com/en-us/blog/networking-to-and-within-the-azure-cloud-part-2/, https://azure.microsoft.com/en-us/blog/networking-to-and-within-the-azure-cloud-part-3/

Translated article.

Microsoft Azure. by Olivier Martin, Global Black Belt - Azure Networking. https://azure.microsoft.com/en-us/blog/networking-to-and-within-the-azure-cloud/, https://azure.microsoft.com/en-us/blog/networking-to-and-within-the-azure-cloud-part-2/, https://azure.microsoft.com/en-us/blog/networking-to-and-within-the-azure-cloud-part