seobi

1. 설치 NodeJS가 설치돼 있어야 하고 버전 확인(https://nodejs.org/en/)에 접속해서 다운로드하자. 보통은 LTS 버전을 많이 쓰니까 나는 LTS 버전을 다운로드하였다. node --version && npm --version 그다음에 npm으로 node-red 설치 sudo npm install -g --unsafe-perm node-red 2. 실행 Terminal에서 실행을 한다. node-red 그다음에 웹브라우저에서 접속 http://127.0.0.1:1880 3. 사용 방법 왼쪽에서 요소를 그림판처럼 붙여 넣어서 테스트 구성을 할 수 있다. (신세계) 우리는 MQTT로 명령어를 전달하고 받아 볼 예정이다. 1) Publish를 하기 위해서 우선 Common의 Inject..

1. AWS 회원 가입 아마존 회원가입하고 (1달 무료) IOT 디바이스 연결 클릭하면 아마존 IOT Core로 접근한다. 2. 사물 / 정책 / 인증서 생성 1) 관리 -> 사물 -> 단일 사물 생성 사물 이름도 작성 하는데 나는 Node-red1으로 했다. 2) 다음 -> 정책 생성-> json 다른 건 건드릴 필요 없고 Action에 iot:*으로 하여 모든 권한을 준다. Resource 도 * 로 하여 모든 권한을 준다. { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iot:*", "Resource": "*" } ] } 3) 다음 -> 새인 증서 자동생성 디바이스 인증서가 CERT file이고, 루트 CA인증서가..

두 개의 서로 다른 계정의 AWS서버를 연동 하려고 할 때, 인프라 적으로 권장하는 방법이 VPC Peering 이다. 개념적으로 보았을 때는 각각의 서버 인스턴스를 가지고 있는 네트워크 위에 가상의 네트워크를 만들어서 이 가상의 네트워크 끼리 연결 한다고 보면 된다. 보안적으로도 시큐리티 그룹 생성하고 IP 제한을 하면 된다. https://docs.aws.amazon.com/ko_kr/vpc/latest/peering/what-is-vpc-peering.html

mqtt 프로토콜을 읽다보면 Qos Level이 나오는데, 아래의 그림이 가장 잘 설명하고 있다. 정리해보면, 레벨 0은 메시지를 잃을 수 있다. 레벨 2는 메시지를 정확하게 1회만 받는데, 너무 통신을 많이 해야해서..현실적으로 사용하기 어려워보이고, AWS에서도 지원을 안한다. 결국 선택은 레벨 1 밖에는 없다. 레벨 1의 단점은 같은 메시지를 2회 받을 수 있다는 점이다. -> 메시지를 설계할 때, 명령을 받는게 아니라 상태를 받게 하고 같은 메시지가 2회 오면 업데이트를 하지 않도록 해야겠다. ex) volum up (x) , volume 17(ok)

1. 상호 인증을 위해서는 우선 인증서 세트가 필요하다. RootCA인증서 (CA.crt) / 서버용 키(Server.key) /서버용 인증서 (Server.crt) / 클라이언트 키 (Client.key) / 클라이언트 인증서(Client.crt) 매우 중요한 사항 : 서버용 인증서의 CN(Common Name) 은 도메인주소(IP)를 적어야 한다. windows에서 테스트로 돌린다면 localhost 로 적자. 2. mosquitto.conf 서버 설정 파일 수정 listener 8884 cafile D:\OpenSSL\bin\ca.crt certfile D:\OpenSSL\bin\server.crt keyfile D:\OpenSSL\bin\server.key require_certificate tr..

0. windows 10 으로 테스트한다면 아래의 디렉터리에 가면 Openssl이 깔려 있다. 아니면 사이트를 뒤져서 깔아보자..... C:\Program Files\Git\usr\bin 1. CA 인증서 생성 openssl genrsa -des3 -out ca.key 2048 openssl req -new -x509 -days 1826 -key ca.key -out ca.crt root CA 인증서를 생성하고 셀프 사인을 했다 ca.crt 파일이 public key와 정보라고 보면 된다. 이제 이 public key로 다른 서버의 인증서를 암호화하자 2. server 인증서 생성 openssl genrsa -out server.key 2048 openssl req -new -out server.csr ..

-> 공개키 방식은 받는 쪽에서 공개키를 가지고 암호화해서 내가 풀어내는 것이고, -> 전자서명은 내가 Data와 공개키를 제공 해서 받는 쪽에서 해당 공개키로 풀어냄으로써 공개키에 대한 개인키를 갖고 있는 사람임을 인증하는 것이다. 공개키 방식 비공개키는 자신만이 가지고 있고, 공개키를 타인에게 제공한다. 공개키를 제공받은 타인은 공개키를 이용해서 정보를 암호화한다. 암호화한 정보를 비 공개키를 가지고 있는 사람에게 전송한다. 비공개 키의 소유자는 이 키를 이용해서 암호화된 정보를 복호화한다. 이 과정에서 공개키가 유출된다고 해도 비 공개키를 모르면 정보를 복호화할 수 없기 때문에 안전하다. 공개키로는 암호화는 할 수 있지만 복호화는 할 수 없기 때문이다. 전자 서명 비공개키의 소유자는 비 공개키를 이..

우리가 익히 알고 있는 Server Client 구조에서 Server는 Client인 APP에게 Request를 할 수 없다. Response 만 하는 구조라서, 결국 APP에서 Server로 요청을 할 수 있지만, Device로는 요청을 할 수 없다. 물론 MQTT에서 Broker에 해당하는 서버는 중계만 해 주지만 Client인 App에서 다른 Client인 Device로 message를 전달할 수 있다. Server단에 client를 하나 더 두어 메시지를 저장 하거나 관찰자 역할을 맡기기도 한다. Server단에 client를 두면 퍼포먼스가 좀 떨어지진 않을 지 의문스럽긴 하다.