네트워킹 기초 다시 쌓기 — fd, 파이프, 소켓에서 인터페이스까지 (VXLAN 3부작 ①)
VXLAN 개념을 다시 파고들다가, 정작 그 아래 깔린 IP·MAC·소켓·인터페이스 같은 기초 용어부터 흔들리고 있다는 걸 깨달았다. 파일 기술자(fd) 하나에서 출발해 파이프, 소켓, 그리고 커널 안의 net_device 구조체까지 이어지는 흐름을 정리한, VXLAN 3부작의 1편.
운영하면서 막힌 문제와 공부한 내용을 다른 사람도 읽을 수 있게 정리한 글입니다.
VXLAN 개념을 다시 파고들다가, 정작 그 아래 깔린 IP·MAC·소켓·인터페이스 같은 기초 용어부터 흔들리고 있다는 걸 깨달았다. 파일 기술자(fd) 하나에서 출발해 파이프, 소켓, 그리고 커널 안의 net_device 구조체까지 이어지는 흐름을 정리한, VXLAN 3부작의 1편.
3부작의 2편. 1편에서 다진 fd/소켓/net_device 기초 위에서, 패킷이 목적지를 찾아가는 세 단계 조회(라우팅 테이블 → neighbour → FDB)와 브릿지·VTEP·VXLAN 캡슐화를 정리했다.
3부작의 3편. 3대짜리 라즈베리파이 k3s 클러스터에서 두 노드의 flannel VXLAN MAC이 중복 등록됐던 사고 진단 기록. 처음엔 추측으로 남겨뒀던 근본 메커니즘을, 실제 리눅스 커널 소스(vxlan_set_mac, SKB_DROP_REASON_LOCAL_MAC)로 확정했다.
블로그 데이터베이스 백업이 로컬 서버에만 저장되고 있다는 걸 깨닫고, 외부 저장소로도 사본을 남기는 방법을 알아봤습니다. 그 과정에서 rclone이라는 도구를 처음 접하고, 왜 스크립트가 알아서 구글 드라이브에 로그인할 수 없는지도 이해하게 됐습니다.
hrtimer 콜백에서 시작해서 tasklet, workqueue, threaded IRQ 세 가지 bottom half 기법의 속도 차이를 직접 측정해본 기록이다. 원리를 이해하는 것과 그 원리가 실측치로 얼마나 정직하게 드러나는지 확인하는 것은 완전히 다른 문제였다.
리눅스 커널 인터럽트 처리의 top half/bottom half 구조를 실제로 구현해보는 최종 과제를 시작했습니다. 타이머 인터럽트로 접근하기로 했는데, 하드웨어 IRQ 라인이 없는 상황에서 어떻게 인터럽트를 만들지부터 막혔습니다.
라즈베리파이에 SSH로 접속하려다가 계속 비밀번호 인증에서 막혔는데, 알고 보니 원인은 SSH 자체가 아니라 터미널 환경 쪽에 있었다. TTY가 뭔지부터 다시 짚어보고, SSH 프로토콜이 실제로 어떻게 구현되어 있는지까지 파고들었다.
OCI 모니터링 알람 설정을 만지다가 pending-duration을 조금만 바꿔도 오탐이 나거나 반대로 진짜 문제를 놓치는 상황을 겪고 나서, 알람이 "판정"을 내리는 원리 자체를 제대로 파고들어봤습니다.
블로그에 자동으로 올라가던 학습 글들이 며칠째 안 보여서 이상하다 싶었는데, 원인을 추적해보니 보안 패치 하나가 파이프라인 전체를 조용히 막아버린 거였다. 로그를 뒤져서 원인을 찾고, 임시방편이 아니라 제대로 된 세션 인증 방식으로 고친 과정을 정리한다.
리눅스 커널 모듈 과제를 하다가 하드웨어 버튼 없이 인터럽트를 테스트해야 하는 상황이 생겨서, 커널 타이머로 인터럽트를 흉내 내는 방법을 공부하다가 결국 Tasklet, Work Queue, Threaded IRQ까지 후반부 처리 기법 전체를 파고들게 된 하루였습니다.
라즈베리파이 인터럽트 드라이버 스터디 4주차 과제를 받았는데, 처음엔 뭘 해야 하는지조차 감이 안 왔다. 과제 zip 파일을 열어보고 나서야 dts, c, Makefile, ko 같은 파일들이 각각 어떤 역할을 하는지, 그리고 이것들이 어떻게 연결되는지를 파고들게 됐다.
집에서 라즈베리파이로 돌리고 있는 NAS(samba)와 WireGuard VPN이 갑자기 외부에서 안 열려서 급하게 원인을 추적했습니다. 결론부터 말하면 하루 전에 방화벽 규칙을 정리하다가 실수로 VPN 포트 하나를 빠뜨린 게 원인이었습니다.
집에서 라즈베리파이로 운영하는 NAS에 외부에서 갑자기 접속이 안 돼서 원인을 찾아봤습니다. 결론적으로는 방화벽 규칙 하나가 빠진 게 문제였는데, 그 과정에서 네트워크 문제를 진단하는 순서에 대해 다시 생각해보게 됐습니다.
과거 PR 기록을 되짚어 라즈베리파이 클러스터에서 겪은 사건들을 정리하다가, 실제 운영 중인 nginx 설정과 배포 스크립트에서 위험 요소를 발견해 함께 고친 하루를 정리했습니다.
블로그 서버에 ufw를 켜는 단순한 작업이었는데, 알고 보니 SSH 접속이 끊길 수도 있고 쿠버네티스 파드 통신이 깨질 수도 있는 꽤 위험한 작업이었습니다. 왜 그런지, 어떻게 안전하게 처리했는지 정리해봤습니다.
운영 중인 개인 블로그 서버의 방문자 로그를 들여다보다가 이상한 패턴들을 발견해서 하나씩 파헤쳐봤습니다. 단순한 봇 스캔인 줄 알았는데, 파다 보니 실제로 뚫려 있던 인증 우회 취약점까지 찾게 된 하루였습니다.
블로그 관리자 페이지의 로그인 방식을 더 안전하게 바꾸고 DB 백업 체계를 만들어보려고 시작한 날의 기록입니다. 아직 구현까지 다다르진 못했고, 무엇을 먼저 정리해야 하는지 파악하는 단계에서 배운 것들을 정리했습니다.
블로그의 프로젝트 탭을 어떻게 나눠야 할지 고민하다가, 단순히 "개인/팀"으로 나누는 게 맞는지 다시 생각해보게 됐습니다.
글이 하나둘 쌓이다 보니 어느 순간부터 이 프로젝트를 어떤 순서로 만들어왔는지 한눈에 안 보인다는 걸 느꼈다. 그래서 프로젝트 페이지에 개발 기록을 시간순 트리로 보여주는 기능을 직접 만들어봤고, 그 과정에서 SVG와 API 페이지네이션에 대해서도 다시 짚어보게 됐다.
내가 운영하는 블로그에 커밋/PR 기반으로 글이 자동으로 올라오는 파이프라인이 있는데, 거기서 붙는 태그랑 글투가 계속 거슬려서 오늘 손을 봤다.