블라베의 취향편지

파세코 창문형 에어컨 사용설명서, 설치가이드 PWA-2100W

스캔문서 첨부합니다

Linux A 서버에서 Linux B 서버로 두 번째 로그인 시 암호를 입력하지 않고 SSH로 접속하려면, SSH 키 기반 인증을 설정해야 합니다. 아래에 이를 설정하는 방법을 단계별로 설명합니다:

1. Linux A 서버에서 SSH 키 생성

Linux A 서버의 auser 계정으로 로그인한 상태에서 다음 명령어를 실행합니다:

bash code 
ssh-keygen -t rsa

• 옵션 설명:
  -t rsa는 RSA 형식의 SSH 키를 생성합니다.
• 결과:
  • Enter file in which to save the key: 그냥 Enter를 눌러 기본 경로(~/.ssh/id_rsa)를 사용합니다.
  • Enter passphrase: 빈 칸으로 두고 Enter를 눌러 비밀번호 없이 생성합니다.
  • Enter same passphrase again: 다시 Enter를 누릅니다.

2. 생성된 공개 키를 Linux B 서버로 복사

생성된 공개 키를 buser 계정의 ~/.ssh/authorized_keys 파일에 추가해야 합니다. 다음 명령어를 사용합니다:

bash code
ssh-copy-id buser@<b서버 IP 또는 호스트 이름>

• 이 과정에서 한 번은 암호를 입력해야 합니다.

대안:
만약 ssh-copy-id 명령어가 없다면, 수동으로 공개 키를 복사할 수도 있습니다:

  1. 공개키 확인

bash code
cat ~/.ssh/id_rsa.pub

  2. 출력된 키를 복사한 후, Linux B 서버에 접속하여 buser 계정의 ~/.ssh/authorized_keys 파일에 붙여넣습니다:

bash code
mkdir -p ~/.ssh chmod 700 ~/.ssh echo "<복사한 키>" >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys

3. 접속 테스트

Linux A 서버에서 다시 한 번 Linux B 서버로 SSH 접속을 시도합니다:

bash code
ssh buser@<b서버 IP 또는 호스트 이름>

이제 암호 없이 SSH 접속이 되어야 합니다.

4. 추가 설정 (선택 사항)

1) SSH 설정 파일에서 Alias 사용

~/.ssh/config 파일에 아래 내용을 추가하면, 짧은 명령어로 접속할 수 있습니다:

bash code
Host bserver HostName <b서버 IP 또는 호스트 이름> User buser IdentityFile ~/.ssh/id_rsa

이제 아래 명령어로 접속할 수 있습니다:

bash code
ssh bserver

2) 파일 권한 확인

SSH 키 인증이 작동하지 않으면, 파일 및 디렉터리 권한을 확인하세요:

bash code
chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys chmod 600 ~/.ssh/id_rsa chmod 644 ~/.ssh/id_rsa.pub

이제 Linux A와 B 서버 간 암호 없는 SSH 접속이 설정되었습니다! 😊

꽃대 진드기 자연친화 퇴치제 만들기

* 님 오일 5 방울

* 시토로넬라 오일 3 방울

* 티트리 비누 1 스푼

* 현미식초 1 스푼

완전하게 깔끔하게 퇴치하려면 강한 농약을 써야할 수도 있지만,

식물과 토양, 그 향기를 맡아야할 인간의 건강을 생각한다면 좀 더 자연 친화적 재료를 사용하려 노력해야겠지.

어디서 들은 얘기를 정리해본다

뉴턴 이 얘기한 "시간"
  시간은 외부의 대상을 받아들이는 형식
  시간은 흐르지 않는다 - 느낄수는 있다  
  물질이 변화하는 것을 보고 시간이 흐른다고 느낄뿐이다

시간=빈 무대, 배우가 사건을 만들어내는 배경같은 것, 무대(배경)자체는 변화하지 않는다


칸트가 얘기한 "시간"
  시간은 선험적이다
  선험적이란, 경험적의 반대개념으로, 인식의 주관적인 형태, 즉, 직관적으로 이해하는 것.
  시간은 정보가 아니라, 우리가 이해하는 틀, 형식이다
  시간은 선험적 직관의 내적 형식이다.
  '내적', '주관적'의 의미는 외부에서는 알 수 없는 나만이 알 수 있는 형식
 
  공간은 선험적 직관의 외적 형식이다
  시간은 엔트로피가 증가하는 방향으로만 변화한다
    가능한 가짓수가 많은 방향, 확률이 큰 방향
    예) 유리컵이 가만히 있는 상태 > 파편으로 깨진 상태
 시간은 1차원적 움직임만 있다
 
지적생명체란,
 인간의 의식이란 미래를 예측하고, 그 예측을 실제 발생한 사건에 견주어서 끊임없이 수정하는 존재
 지적 존재란, 미래의 시간에 무슨 일이 벌어질지 예측하고
 그게 얼마나 합리적인가를 우리는 계속 끊임없이 고민하는 존재
 예측이란, 과거의 경험을 바탕으로 미래를 추측하는 행위
 시간여행이 허용되면 예측이 불가능, 지적 존재 불가능
 
 인과율 = 원인 후 결과가 존재 = 시간
 
진화 evolution
변이 variation
 
시간이란 변화를 기술하기 위해 도입한 방법일 뿐이다, 물리학을 위해 시간을 대체할 수도 있다.

https://co-no.tistory.com/entry/Linux-CentOS7-%EC%97%90%EC%84%9C-User-%EC%83%9D%EC%84%B1useradd%EA%B3%BC-User-%ED%99%88-%EB%94%94%EB%A0%89%ED%86%A0%EB%A6%AC-%EC%84%A4%EC%A0%95

https://wooono.tistory.com/371

alteon 로드밸런서의 SLB 설정 순서는 다음과 같이 진행한다.
step 0. 설정값 준비
step 1. SLB 활성화하기
step 2. Real Server 설정하기 , health check 반복주기설정하기
step 3.Real Server의 그룹 설정하기, Loadbalancing 알고리즘 포함 
step 4. Virtual Server 설정하기
step 5. Service 설정하기
step 6. 설정 저장 및 적용하기
 
[main menu]

 
[how to Layer 4 config ]

step 0. 설정값 준비

1) real server A의 정보
- number : 21 (임의로 지정한 번호이다. 주로, IP 주소의 일부값을 사용하면 편리하다)
- IP : 10.1.1.21
2) real server B의 정보
- number : 22 (임의로 지정한 번호이다. 주로, IP 주소의 일부값을 사용하면 편리하다)
- IP : 10.1.1.22
3) server Group number 
- number : 20 (관리를 위해 임의로 지정한 번호이다)
4) virtual server 정보 
- number : 20 (관리를 위해 임의로 지정한 번호이다. Group number와 같은 번호를 사용하면 편리하다)
- ip : 10.1.1.20

step 1. SLB 활성화하기

설정명령
# /cfg/slb/on

Current status: OFF
New status: ON

상태 확인
# /cfg/slb/cur

Current Layer 4 settings:
ON,   direct enabled, matrix enabled, vma sport disabled, grace disabled clrbkp disabled
...

step 2. Real Server 설정하기, health check 반복 주기 설정하기

설정명령(1) Real Server 설정하기
# /cfg/slb/real 21/ena/rip 10.1.1.21

Current status: disabled
New status:     enabled
Current real server IP address:     0.0.0.0
New pending real server IP address: 10.1.1.21


# /cfg/slb/real 22/ena/rip 10.1.1.22

Current status: disabled
New status:     enabled
Current real server IP address:     0.0.0.0
New pending real server IP address: 10.1.1.22
 
 
설정명령(2) health check 반복 주기 설정하기
사용할 메뉴
inter    - Set interval between health checks
retry    - Set number of failed attempts to declare server DOWN
restr    - Set number of successful attempts to declare server UP

# /cfg/slb/real 21/inter 2   (측정 주기를 2초로 설정)

Current interval:     2
New pending interval: 2

# /cfg/slb/real 351/retry 3  (측정 실패시 재시도 반복 횟수를 3회로 설정)

Current number of failure retries:     4
New pending number of failure retries: 3


# /cfg/slb/real 351/restr 2  (측정 실패 후 측정 성공 2회 확인되면 정상 상태로 표시하는 설정)

Current number of successful attempts:     2
New pending number of successful attempts: 2

step 3.Real Server의 그룹 설정하기, Loadbalancing 알고리즘 포함 

설정명령
# /cfg/slb/group 20/add 21/met hash  (그룹 20번에 21번 서버를 포함시키고, LB 알고리즘은 hash를 선택) 

Real server 21 added to real server group 20.
Current metric:         leastconns
New pending metric:     hash

# /cfg/slb/group 20/add 22/met hash  (그룹 20번에 22번 서버를 포함시키고, LB 알고리즘은 hash를 선택) 

Real server 22 added to real server group 20.
Current metric:         leastconns
New pending metric:     hash

 

step 4. Virtual Server 설정하기

설정명령
# /cfg/slb/virt 20/ena

Current status: disabled
New status:     enabled

step 5. Service 설정하기 

설정명령
# /cfg/slb/virt 20/ena/vip 10.1.1.20/service 80 http/group 20

Current status: disabled
New status:     enabled
Current virtual server IP address:     0.0.0.0
New pending virtual server IP address: 10.1.1.20
Current real server group:     1
New pending real server group: 20

step 6. 설정 저장 및 적용하기

설정명령
# /apply
# /save


 
 

AWS Account의 운영 업무를 맡게된 당신에게 ~

Hi OkMan,

이번에 AWS 클라우드 운영 업무를 맡아 취업하게 된 걸 축하해. 
앞으로 학교 학원에서 배운 것 이상의 다양한 환경을 마주하게 될테니 AWS Document와 더더욱 친하게 지내길 바래.
그렇다고 AWS Document 만 너무 맹신하지 말길 바래. AWS는 기능 변경이 자주 있어서 Document가 바뀐 기능을 따라가지 못하는 경우가 많아. Document에서 본 화면과 실제 접속한 Console의 메뉴 배치나 기능이 약간씩 다른 경우가 아주 많으니까 놀라지 말고, 필요한 기능은 꼭 테스트를 해본 뒤에 사용하는 것을 추천한다.

이제 회사에서 사용하는 여러개의 AWS Account의 운영 업무를 맡게 됬으니, 여러 Account의 Console을 로그인 로그아웃하면서 환경을 바꿔가면서 일을 하는게 여간 번거로운게 아닐거야.
만일, AWS Account가 두세개 정도라면 몇가지 웹브라우저(크롬, 파이어폭스, 아파치, 엣지 등)을 동시에 열어놓고, 각각 다른 Account의 Console을 로그인해두고 사용하면 되겠지.
하지만, Account 갯수가 그 보다 더 많다면 그렇게 작업하긴 곤란하겠지. 회사에 프로젝트는 여러개인데 AWS 운영자는 그보다 수가 적은게 보통이니까, 운영자 한명당 맡게 되는 AWS Account가 십여개씩 되는 건 일반적인 상황일걸.
그런 환경에서 이쪽 저쪽 Account를 옮겨다니면서 작업하는 불편을 덜어줄 수 있는 AWS 의 Switch Role을 소개해볼게.
 
SwitchRole의 기본개념은 Gateway 개념과 유사해.
먼저, 내가 주로 사용할 AWS Account를 하나를 정해야되. 일명 Gateway Acoount라고 부를게.
그리고, 관리해야할 여러개의 AWS Account들에서 위의 Gateway Account의 Console Access 권한을 허용해주는거야.
그러면, Gateway Account에만 로그인한 상태로 SwitchRole 기능을 이용해서 별도의 로그인 없이 
한번의 클릭만으로 다른 AWS Account의 Console을 접속할 수 있어.

그러면, SwitchRole을 사용하기 위한 환경 설정을 해볼게.

우선, 테스트할 환경을 소개하지.
AWS Account 두개 또는 세개를 준비해.
 AWS Account ID는 12자리 숫자로 되어있지. 여기선 별칭으로 A, B, C라고 할게.
  - AWS Account ID "A" (1111 1111 1111)   
  - AWS Account ID "B" (2222 2222 2222)   
  - AWS Account ID "C" (3333 3333 3333)

 위 ID 중에서 Account A를 Gateway 역할로 사용할게.
 그리고, 관리할 대상은 Account B와 C라고 할게.
 
그럼 이제부터 설정을 시작할거야.
 

Chapter 1. AWS Account "A" 콘솔에서 설정할 내용

 1.1) create an IAM user

    웹브라우저(예:크롬)에서 AWS Account ID "A"로 AWS Management Console에 로그인한다. 
    IAM 메뉴에서 AWS Switch Role (역할전환)에 사용할 IAM user 를 원하는 이름으로 만든다.

    내 경우에는  IAM user 를'maestro'라는 이름으로 만들었다.
    root Account를 그대로 이용할 수도 있겠지만, 
    user별 역할 분리와 보안성 강화를 위해서는 SwitchRole에 사용할 IAM user 를 이용하고,
    콘솔 로그인 옵션에 MFA(멀티 팩터 인증)을 추가할 것을 권장한다.
    물론, 기존에 사용하던 IAM user가 있다면 그대로 이용해도 관계는 없다.

    IAM user 만드는 방법과 MFA 설정하는 방법은 다른 문서를 참고하길 바란다.
    이제 Account A 콘솔에서는 더 이상 설정할 것이 없다.
  

Chapter 2. AWS Account "B"콘솔에서 설정할 내용 

 2.1) create a role for allow IAM user 'maestro' of Account "A"

    이번 작업은 다른 웹브라우저(예:파이어폭스)를 이용하는게 편할 것이다. 
    Account ID B의  AWS Management Console에 접속할 Account ID A의 maestro user를 위한 권한을 허용하는 Role을 설정을 하자.

    Account ID B의  AWS Management Console에 로그인하고, IAM 메뉴에서 아래와 깉이 역할(Role)을 하나 만든다.

    ---------------------------------------------------------------------------------------------------------------------------------
    Role Name : switchrole-maestro-of-A-to-B

    Step 1. Select trusted entity
     - Trusted entity type : select "AWS account"
     - An AWS account
       > select "Another AWS account"
       > Account id [ 111111111111 ] <-- 여기엔 AWS Account A의 ID 번호 12자리 숫자를 입력해.
       > Options : select "Require MFA"   

Step 2. Add permissions
 - Permissions policies
   . select "AdministratorAccess"
   여기에서는 maestro user에게 허용할 권한을 필요한 만큼 설정해주면 된다.
   이 예제에서는 쉬운 설명을 위해 full access 권한인 AdministratorAccess를 선택하였는데,
   실제 적용할 때는 user가 하는 일과 역할에 맞게 권한을 나눠서 주는것을 검토해보길 바래.

Step 3. Name, review, and create

   처음 계획했던 Role name을 입력하고,  필요한 tag를 추가하고,  [Create role] 버튼을 클릭하여 작업을 완료한다.
   이 단계에서는 Trust policy를 수정하지 말고, 이후에 policy를 완성한 후 필요한 부분을 수정하는 것을 추천한다.

   ---------------------------------------------------------------------------------------------------------------------------------

그러면, 역할(Role)이 아래와 같이 만들어졌어.

 2.2) Edit  role 

    위 1)과 같이 역할(Role)을 만든 후 신뢰관계(Trust relationships) 의 JSON 코드를 보면 root 계정을 기준으로 설정이 되어있다. 
처음 계획했던 대로 AWS Account "A"의 'maestro' user에게만 권한을 주기 위해 신뢰할 수 있는 엔터티(Trusted entities)의 Principal 부분의 내용을 이렇게 수정한다.

(before) "arn:aws:iam::111111111111/root"
(after)    "arn:aws:iam::111111111111:user/maestro"

 * 변경 후의 JSON code

이렇게 하면 AWS Account ID "B"에서 설정을 마쳤다.

* AWS Account ID "C"의 콘솔에서도 이 chapter 2의 내용과 동일하게 설정해주면 되므로, AWS Account ID "C"의 콘솔에서 설정할 내용은 생략한다.

Chapter 3. switchrole 링크 만들기 

이제, AWS Management Console에 Account ID A의 maestro user로 로그인했을 때,
Account ID B와 C의 콘솔로 연결되는 switchrole 링크를 만들어야 한다.

 3.1) Account ID A의 maestro user에서 역할전환(SwitchRole) 정보 등록하기

AWS Management Console에 Account ID A의 maestro user로 로그인하고,
Console 우측 상단의 "maestro" id를 클릭하면 역할전환(SwitchRole) 버튼이 보일것이다.

역할전환(SwitchRole) 버튼을 클릭하고, Account B 와 C에서 설정했던 Role 정보를 등록해주면 된다.

a. Account B(222222222222)에 만들었던 Role 정보를 등록한다 
   [Switch Role]
   Account ID : 222222222222
   IAM role name : switchrole-maestro-of-A-to-B
   Display name (optional) : maestro-of-A-to-B
   Display color (optional) : Red 
   내용 입력하고 [Switch Role] 버튼을 클릭한다.

b. Account C(333333333333)에 만들었던 Role 정보를 등록한다 
   [Switch Role]
   Account ID : 333333333333
   IAM role name : switchrole-maestro-of-A-to-C
   Display name (optional) : maestro-of-A-to-C
   Display color (optional) : Orange
   내용 입력하고 [Switch Role] 버튼을 클릭한다.

 3.2) 역할전환(SwitchRole) 링크를 클릭하여 다른 계정의 콘솔에 접속하기 

이제, WS Management Console에 Account ID A의 maestro user로 로그인하고,
Console 우측 상단의 "maestro" id를 클릭하면 역할전환(SwitchRole) 버튼 위쪽에 B와 C로 이동하는 링크가 보일 것이다. 

[maestro-of-A-to-B] 링크를 클릭하면 Account B의 Console로 접속이 된다.

ID를 클릭하면 [다시 전환] 이라는 버튼이 표시되며, 이것은 Account ID A의 maestro 의 Console로 다시 돌아갈 때 사용하는 링크이다.

정리하면,

 이제부터는 새로운 AWS 클라우드 계정을 만들 때마다 위와 같이 역할전환 설정을 해두면 되고, 
 클라우드 운영업무를 할 때는, Account ID A의 maestro user로 콘솔 로그인한 뒤, 관리할 계정으로 역할전환하면 된다.
 
그럼 오늘도 Good Luck 하길 ~
 

그룹메일계정으로 메일을 보내야할 경우가 있다. (2탄이다)

업무용으로 외부 클라우드 또는 IT 솔루션 이용계약시 내 개인메일 주소가 아닌 프로젝트 공유 수신용으로 사용하는 그룹메일주소를 솔루션 계약에 사용하게 되는 경우가 있는데, 이때 메일주소의 인증을 위해 메일회신을 해야하는 경우에 유용하다.

참고로, 앞의 1탄은 '그룹스' 기능을 이용하는 것인데, 수신자 지정과 숨은참조 지정이 안된다는 점과, 메일화면에서 그룹스 화면으로 옮겨가서 사용해야하는 등의 불편이 있었다.

이번 2탄은, 구글메일 화면에서 메일 보내기 할 때 발신자 주소를 변경하여 메일 보내는 방법이고, 여기에서 그룹메일 주소를 활용하는 것이 되겠다.

설정 과정에서 구글의 메일 인증절차가 있으니,  내가 소속된 그룹메일주소라야 진행이 편하다는 점을 참고바란다.

그럼, 아래 번호 순으로 설정해보자.

(1) ~ (2) 사용자의 구글메일 화면에서 설정 메뉴로 이동  

(3) ~ (4) "다른 이메일 주소 추가"를 클릭하고,

(5) 팝업화면의 내용을 등록하고 '확인 메일 보내기'를 클릭한다.

(6) 내 받은 편지함에서 확인메일을 찾아서 승인 링크를 클릭한다.

(7) 다시 메일 설정으로 돌아와서 주소 정보가 정상인지 확인한다.

(8) 편지 쓰기 화면에서 '보낸사람'을 클릭하여 그룹메일주소를 선택해주고 메일을 보낸다.

* 기타

  구글 Workspace 설정에서 그룹메일의 관리자 권한있는 경우만 발신될 수도 있으니 참고바람

끄읕 ~

보안 3요소 CIA (기밀성, 무결성, 가용성) 

기밀성 (Confidentiality)
1) 소유자가 원하는대로 정보의 비밀을 유지한다.
2) 명백히 허가된 대상에게만 정보가 제공되어야 한다.
3) 접근통제와 암호화로 구현한다.


무결성 (Integrity)
1) 비인가자에 의한 정보의 변경, 삭제, 생성을 막는다.
2) 정보의 정확성과 안정성을 보장한다.
3) 물리적 통제와 접근 통제로 무결성을 보장한다.

가용성 (Availability)
1) 적절한 방법으로 작동되고 정당한 방법으로 필요한 시점에 권한이 부여된 사용자에게 정보가 제공된다.
2) 백업, 중복성 유지, 위협 요소로부터의 보호 등으로 가용성을 보장한다.

회사 업무 메일이 구글워크스페이스를 사용하는데,

회사 외부의 고객, 협력사 등에 공지메일을 보내야할 때가 있는데, 내 계정이 아닌 팀 또는 회사대표성격을 띄는 메일 계정을 이용해서 메일을 보내야할 경우가 있다.

이 때, 공지메일을 보내는 발신전용의 기능만을 위해서,  유료 사용자 계정을 만들어서 메일을 보내면 되지만, 회신오는 메일을 확인하는게 번거로웠다. 그리고, 가끔 사용하는 기능을 위해서 유료 계정 한개 요금을 유지해야하는 것도 아깝기도 해서 다른 방법이 없는지 찾아보았다.

그룹메일은, 주로 부서 또는 프로젝트 단위로 단체로 메일을 받기 편하도록 만들어진 기능이고, 그룹메일은 무료라서 편리하게 많이 사용하는 기능이다. 이 그룹메일 ID를 활용해서 메일 발신을 할 수 있으면 좋지 않을까하여 Google Workspace 자료를 찾아보았지만, 그룹메일에서 메일 발신하는 설명은 찾을 수가 없었다. 셀프로 삽질을 해보기로하고, 그룹메일의 설정 기능을 살펴보면서 이것저것 테스트해보니 그룹메일에서 메일을 발송하는 방법이 있었다.

테스트한 내용은 아래와 같다.

1. 구글웍스 관리자에서, 메일 발송에 사용할 그룹메일 이름을 partner_noreply@mycompany.com 으로 생성했고, 내 계정을 이 그룹메일의 관리자로 등록했다. (그룹메일 등록 방법은 생략)

2. 내 계정으로 구글메일 로그인 후 '그룹스' 메뉴에서 이 그룹메일의 '그룹설정' 화면을 찾아 들어간다. 첨부 그림 (1) ~(5)까지 참고.

3. '그룹을 대표하여 게시할 수 있는 사용자' 항목에서 '그룹관리자'와 '그룹회원'까지 권한을 부여하고,
    '기본발신자'를 '그룹주소'로 설정하고 저장한다. 첨부그림 (6)~(8) 참고.

 여기까지 하면 준비는 되었고,

4. 그룹스의 "새 대화"를 클릭하면 메일발송 창이 뜬다. 첨부그림 (9)-(10) 참고.

  '발신자(보낸사람)' 계정은 그룹메일 계정이 입력되고, combo box에서 내 사용자계정으로 변경할 수도 있다. 

   '수신자' 라는 항목은 없고, 뒤에 결과를 보면 알겠지만, 수신자는 기본적으로 이 그룹메일 계정이 되며,
   '참조(cc)'칸에 수신자메일주소들을 입력하는 것으로 수신자 목록 작성을 대신할 수 있다.
    제목과 내용을 작성하고, 첨부파일도 넣을 수 있다.

    '메시지 게시'를 클릭하면, 그룹메일의 대화목록에 메일이 표시가 되며,
    동시에 참조 수신자에게도 메일이 전달된다.

결과,

아래와 같이 개인메일에도 메일이 전달되었다.

그룹메일에 포함된 사용자들 모두 메일을 받는 것은 기본이고, 참조에 등록한 메일주소로도 메일이 발송되었다.

단점이 있다면, 숨은참조 기능을 쓸수가없는 점이 아쉽다

p.s 다른 방법도 있다. 2탄에서 계속 

경찰 검찰 사칭 전화인지 확인하는 방법

인터넷 사기 의심 전화·계좌번호 조회

     https://www.police.go.kr/www/security/cyber/cyber04.jsp

검찰이라고 하면,

서울중앙지검 보이스피싱 찐센터 010-3570-8242
 보이스피싱 의심되는 경찰 전화나 서류를 받았다면
 해당 전화번호나 서류를 이 번호로 보내면 확인 후 연락을 준다고 한다
 문자로만 가능하며 전화 통화는 되지 않는다.
 

경찰이라고 하면,

  경찰청 민원센터 182번 또는 금융감독원 콜센터 1332번 
 전화해서 상담원과 통화하거나 음성을 남기면 확인해서 회신 준다고 한다.