ESukmean's

E_Sukmeans' 블로그

내맘대로 뽑은 8월 4째주 읽어볼만한 HackerNews 글들

https://news.ycombinator.com 을 보고 읽을만한거를 정리해봤습니다. How NAT Traversal Works https://news.ycombinator.com/item?id=24241105, https://tailscale.com/blog/how-nat-traversal-works/ NAT traversal이 어떻게 되는지를 다룬 글입니다. P2P 통신을 하게되면 NAT Traversal을 한번씩 꼭 다루게 됩니다. 일반 가정집에서는 대부분 공유기를 하나씩 사용하고 있습니다. 공유기 아래에 있는 컴퓨터는 대부분 사설 IP를… Continue Reading →

GitFS 설치 및 사용

어제자 HackerNews에 GitFS에 대한 글이 올라왔었다. GitFS는 이름에서 엿볼수 있듯, Git을 파일 시스템처럼 사용할 수 있게끔 해주는 파일 시스템 구현이다. Python으로 Fuse 구현을 한 것이기 때문에 왠만한 OS에서 문제 없이 동작한다. 일반 Git도 clone을 하면 읽고 쓰기가 가능하다. 그럼에도 GitFS를 쓰는 이유는 자동 커밋, 푸시, 패치를 해 주기 때문이다. git fetch의 경우 설정한 주기마다 서버에서 읽기를 시도한다. FUSE 구현으로 통해 파일이 새로 생겼거나 수정됨을 파악하여 알아서 commit과 push까지 해 준다. (이런식으로: https://bitbucket.org/ESukmean/gitfs-test/src/master/) 사용하려면 많은곳에서 쓸 수 있을듯 하다. 여러 서버에 동일한 파일들을 배포해야 할 때나, 수정이 빈번하여… Continue Reading →

카카오톡 멀티프로필 생일 궁금증

저번달에 내 생일을 맞아서 카카오톡 생일 알림기능을 조금 살펴보았다. 나는 전화번호가 두개고, 아이폰과 안드로이드 폰을 같이 사용한다. 아래 내용은 아이폰의 카카오톡과 안드로이드의 카카오톡을 교차로 확인한 내용이다. 추가로 지인분을 통해서 한번더 검증하였다. 멀티 프로필에서도 생일 알림이 나오는가? 나온다. 멀티프로필이어도 생일임은 정상적으로 나온다. 메인 프로필 설정에서 생일 알림을 끄거나 켤 수 있고, 멀티 프로필은 메인 프로필에서의 설정을 따라간다. 멀티프로필만 따로 생일 알림을 켜거나 끌 수는 없어 보인다. 생일 알림 기능을 켜거나 끄면 즉시 반영되는가? 아니다. 의외인 부분이어서 놀랐는데, 프로필 설정에서 “생일 알림”을 켜거나 꺼도 몇시간 후에 적용이 된다…. Continue Reading →

SSL 인증서의 DNS 이름을 통한 서버 알아내기

자신의 서버 IP를 숨기기 위해 Cloudflare같은 CDN을 이용하는 경우가 종종있다.. 이러한 CDN(일종의 Proxy 시스템)을 이용하면 DNS 조회를 했을 때 실제 서버의 주소 대신 해당 CDN의 노드 IP주소가 표시된다. 서버의 실제 IP가 노출됨을 막음으로서 DDos공격이나 기본적인 해킹 시도를 줄이거나 어렵게 만들수 있다. CDN이나 표면 서버를 앞에 두면 실제 핵심(코어) 서버의 주소를 가릴수 있다. 그렇지만 서버 프로그램에 설정을 잘 못하면 모두 헛수고가 될 수도 있다. 주의를 가져야 하는 부분은 SSL 인증서의 DNS 필드이다. SSL 인증서에는 발급대상 정보와 “도메인 주소” 주소가 담겨있다. SSL 인증서만 받아낼 수 있으면… Continue Reading →

기본적인 SSH 보안 강화

이 글에서는 SSH 접속에 관련된 보안 설정을 다뤄보려고 한다. 대단한것들은 아닐뿐더러 이미 알고 있는 내용도 많을것이다. 들어가기전에 말을 하나 하자면, 서비스(프로그램)을 돌린다면 반드시 root가 아닌, 별도의 서비스 계정을 만들어서 돌리라는 것이다. 아래와 같이 설정을 해봤자, root 권한을 가진 서비스의 취약점에… Continue Reading →

통화 녹음 솔루션: 스위치

최근 KT PC제한 시스템에 대해 포스팅 하였다. 해당 글을 보면 중간에 담당 고객센터에 전화하여 몇가지 안내를 받았다고 적혀있다. 업무용 통화나 고객센터에 따지기 위해 통화 할 때는 내용을 정리하고 종합하는것이 중요하다. 최소한 되돌려 듣기는 꼭 필요하다. 이를 위해 스위치 라는 앱을 통하여 통화를 하였다. 꽤나 물건인 듯 하여, 이번 글에서 다루어 보려고 한다. 스위치 란? ‘스위치’ 란 자동으로 통화를 녹음하고 텍스트 변환등을 통해 정리해 주는 SaaS 제품이다. 요즘 스마트폰에서는 ‘통화 녹음’ 기능이 빠지는 경우가 많다. 통화 녹음 기능이 있다고 해도 어디까지나 말 그대로 ‘녹음’까지밖에 되지 않는다. 공적인 통화일수록 상대방이 무슨 말을 했고, 내가 어느 범위까지 말을 했는지 확인할 수 있는게 꼭 필요하다. 이때 스위치를 이용하면 자동으로 통화를 녹음해 줌은 물론, 텍스트 변환을 이용하여 빠르게 전화 내용을 확인 할 수 있다. 스위치를 통해 통화를 하면 해당 앱 내에서 빠르게 대화 내용을 볼 수 있다. https://connect.getswitch.app (스위치 커넥트)를 통해 PC를 비롯해서 여러 다른 기기에서 조회 할 수도 있다. 위의 캡쳐는 실제로 KT 고객센터와 통화하면서… Continue Reading →

KT PC대수 제한 경험기(?) – 웹소켓 장애 체험기

최근에 웹소켓 서비스쪽에 작업중에 이상한 문제가 발생했다. 웹소켓을 제대로 접속을 못하는 문제가 발생한 것이다. 새로고침도 여러번 하고 브라우저도 바꾸어보아도 여전히 접속이 불가능했다. 다른분들께 부탁 하여 접속 가능여부를 체크 해 봤는데, 나에게만 발생하는 문제임을 확인했다. 그제서야 뭔가 문제가 있음을 느끼고 무슨일이 일어나고 있는지 살펴 보았다. WS 요청을 했는데 200이 온다고? 가장 먼저 개발자 도구를 열어보았다. 개발자 도구에서 네트워크 패널을 보면 브라우저가 어떻게 통신을 했는지 간단하게 볼 수 있다. 네트워크 패널을 이용하여 웹소켓 요청을 찍어봤는데, 응답 코드로 101이 아닌 200이 오는것을 확인하였다. 아니? 이게 무슨일인가! 비단 WS를 요청하면 101이 나와야 함이 정상인데 200이 온 것이다. 해당 웹소켓 서버는 내가 제작을 한 것이었는데, 기억에 분명 200을 리턴하는 코드는 작성한 적이 없었다. 혹시 특정 상황에서 내가 200을 리턴하도록 한 것이 있나? 해서 살펴 봤는데 전혀 없었다. 또한 응답 헤더에 있어서도 저런 헤더를 찍어내는 코드는 전혀 없었다. 웹소켓 백엔드 서버에서 발생하는 문제는 아닌것으로 판단하고, 그 앞단을 살펴 보기로 했다. 이 서버는 [유저 -> CDN -> WS서버] 의 접속 구조를 가지고 있다. WS서버의 문제는 아닌것을 확인했으니 CDN을 파 보아야 할 차례였다. 빠르게 해당 CDN을 경유하여 WS를 접속하는 다른 사이트를 찾아보았다.  결과는 정상이었다. 몇번을 시도해 보았고, 수신지 IP가 동일함 까지 확인해 보았다. 테스트 도중 위의 요청 헤더가 이상함을 한번 더 확인하였다. CDN 에서 요청을 내려줬으면 CDN 특유의 헤더가 찍혀야 하는데, 그런것이 전혀 없다. 일단 Response가 나온다는거면 아무리 CDN이 꼬여도 특정 헤더 하나정도는 찍혀야 마땅하다. 즉, 하나 정도는 묻혀 나와야 할 헤더가 없던 것이다. (예를 들어, Cloudflare라면 server: cloudflare 등의 헤더가 있어야 한다) 사실 처음에는 CDN 내부에서 오류가 발생했거나, GET… Continue Reading →

(단일) 실패지점

 서버를 운영하다 보면 서버 장에 대응에 대한 고민이 생긴다. 서버란 어찌되었건 “끊김이 없어야 하는 것”이다. 단 몇분이라도 서버에 장애가 발생하면 사용자는 불편을 느낄 뿐더러 신뢰성을 잃을수 조차 있다. 쇼핑몰 서버에서 피크 타임시 발생하는 장애는 하루 매출의 반 이상을 잃게 할 수도 있다. 특정 목적의 서비스 중이라면 SLA에 따라 보상금까지 물어야 할 수도 있다. 이해가 쉽도록 “서버”를 “방송”으로 바꾸어보자. 방송사의 장비에 불량이 생겨서 몇 분 동안 검은 화면만 송출되었다고 생각하면 얼마나 큰 일인지 생각할 수 있을거다. 자체 방송중에 검은화면만 나와도 큰 일인데, 광고 타임에 검은 화면만 나왔다면 (계약에 따라) 손해배상을 해야 할 수도 있다. 증상을 조기에 알아낸다고 해도 수정·패치 작업에는 또 긴 시간이 필요하다. IT운영 인력이 부족할 경우 ‘증상이 있음’을 알아내는것 조차 어려울 수 있다. 그렇기에 가장 중요한것은 애초에 장애가 나지 않도록 하는 것이다. 어느 호스팅사에서 월 1만원짜리 웹 호스팅을 받고있다고 하자. 당장 보이는건 해당 호스팅 업체에 있는 내 사이트밖에 없다. 하지만 그 아래에는 서버의 위치 (가정집, 사내, IDC)와 회선 정보, 그리고 서버 관리능력과 안정성이 깔려있다. 사실 이런 걱정을 모두 호스팅사에 넘기기 위해 (Managed) 웹 호스팅을 쓰는것은 맞지만, 어쨋든 장애가 나면 손해는 내가 보는것이다. 단순한 웹서버라고 해도 안을 까보면 상당히 많은 구성요소가 깔려있다. 당장 글을 쓰면서… Continue Reading →

유챗 봇 제작 #2 – 접속정보 처리

 이전까지의 글에서는 유챗 서버와의 통신에 필요한 맨 아랫 부분을 다루어 보았다. 여기서 부터는 밑바닥에 대한 부분에서 벗어나서 실질적으로 봇을 이용하기 위한 (일종의) 클래스를 구현해 볼 것이다.  글을 쓰는 도중에 tokio가 1.0으로 버전이 올라갔다. 아직 종속된 라이브러리들이 1.0을 지원하지 않아서 0.3버전을 바탕으로 글을 작성하였다. 1.0 버전으로 올리는 과정에 대해서는 따로 글을 쓸 것 같지는 않으니, 필요가 있으면 직접 Github의 리포를 확인해야 할 것이다.  이전글에서는 아래와 같은 코드를 이용해서 직접적으로 접속 정보를 전송하였다:  하지만 위의 코드로는 접속정보를 바꾸기가 쉽지 않다. 여러개의 방에 접속하기 위해서는 매번 접속정보를 생성 해 줘야 하며, 인증 토큰을 필요로 하는 방에 접속하려면 해줄것이 너무 많아진다. 물론 안될 것은 없겠지만 이것들을 직접 구워먹고자 하면 상당히 번거롭고 귀찮은 방법이다. 그러므로 앞으로 접속정보를 관리하는 구조체를 만들어서 관련된 작업은 모두 거기서 이루어 지게 한다.  우선 접속정보를 담아낼 수 있는 구조체를 만든다. cache_token과 profile_image는 uchat.js를 뜯어보면서 ‘이런게 있는구나~’ 를 알아냈다. 실제로는 어떻게 사용되는지 까지는 모르겠다. 겉으로는 드러나지 않지만 계속해서 내부에선 업데이트가 진행되는듯 한 것으로 보아, 언젠가 기능 구현에 쓰일지도 모르겠다. uchat.js를 뜯어봤더니, 무조건 있어야 하는 값은 방 ID 하나 뿐이었다. 접속 인증을 사용하지 않는 방은 token이 필요 없다. nick이 없으면 알아서 손님1234 같은 닉네임을 만들어 준다. auth 또한 Option으로 뺄려면 뺄 수 있으나 구현에 있어서 한단계 추가 할 것이 생겨서 UChatAuthLevel이라는 enum에 None을 추가해 놓는것으로 타협하였다. 값을 설정하는 방식으로는 builder 패턴을 이용하였다. getter / setter를 만들 필요도 없을것 같아서 저 수준에서 마감을 했다. (어짜피 필요하면 구조체 내에 접근 가능하기도 하다) … Continue Reading →

2020년 정리

1~4월  군대에 박혀 있었다. 원래 전역일자는 5월 중순이었다. 그러나 코로나 때문에 4월 말 즈음에 현지전역 제도로 집에 갔다. 코로나로 인한 출타제한 때문에 거의 20일? 정도 일찍 나오게 되었다. 대대급 내에서는 인사를 다 드리고 나왔으나, 불교 군종장교님께는 인사를 못드린게 못내 아쉽다. 나름 불교 군종병으로 활동 했었는데 아쉽게 되었다.  19년 말 부터 리눅스용 사지방 접속기를 만들고 배포하였다. 병영내 사지방 개선 사업이 진행되면서 하모니카 OS가 설치된 PC들이 보급되기 시작했었다. 사업 초기에 여러 문제가 쌓여 있었다. 그중 병사로서 가장 크게 다가온 것은 구글 및 유튜브 접속장애 문제였다. 구글·유튜브 접속에 2~3분 걸리다가 끝내 타임아웃까지 발생하는 문제였다. 이로인해 사지방의 목적인 “인터넷 검색”을 할 수 없는 환경이 된 것이다.  네트워크 장비상의 문제를 우회하지 않고서는 해결할 방법이 없었다. 윈도우 상에서는 익히 알려진 우회방법이 있었으나, 하모니카에서는 불가능한 방법이었다. (루트 권한이 없는게 가장 크다) 그래서 유저 레벨에서 사용 가능한 우회 접속기를 만들어서 사용했었다. 그 과정속에서 사지방 운영 업체측에서 파이어폭스를 전체 차단하는 병맛 가득한 수를 두어서 충격 먹기도 하였다.  네트워크… Continue Reading →

« Older posts

© 2021 ESukmean's — Powered by WordPress

Theme by Anders NorenUp ↑