본문 바로가기

분류 전체보기

(39)
150명을 어떻게 옮겼는가 — 기술보다 어려웠던 부분 (Part 11) 개요병행 운영 기간을 충분히 뒀다. 신규 접속을 IPsec으로 열고 SSL VPN을 남겨둔 채 사용자를 옮겼다.전환 순서: 본인 → IT 인접 인원 → 협조적 소수 → 부서 단위 → 잔여 인원. 각 단계에서 멈출 수 있게 설계했다.문의는 기술 문제보다 "어떻게 하는지 모른다"가 압도적으로 많았다. 대응은 안내문 축약이었다.롤백 기준을 숫자로 미리 정해뒀다. 정하지 않으면 판단이 감정으로 흐른다.이 글은 누구를 위한 글인가기술 검증은 끝났고 이제 실제 사용자를 옮겨야 하는 사람. 특히 담당자가 본인 한 명인 경우.읽고 나면 무엇을 미리 준비해야 문의 폭주를 피할 수 있는지 알게 된다.1. 가장 중요한 결정: 병행 운영전환 방식은 두 가지다.방식장점단점일괄 전환 (특정일에 SSL VPN 종료)짧고 명확, 관..
하나의 게이트웨이에 PSK 터널 여러 개 붙이기 — network-id와 보조 공인 IP (Part 10) 개요같은 공인 IP에 PSK 기반 dialup 터널을 여러 개 두면 FortiGate가 어느 터널로 보낼지 구분할 수 없다. 첫 번째로 매칭되는 터널이 가져간다.구분 수단으로 network-id가 있지만, 실질적으로 EMS 관리 환경을 전제한다.EMS 없이 가능한 방법: 인터페이스에 보조 공인 IP를 추가하고 터널별로 local-gw를 분리한다.그룹 분기는 여전히 RADIUS + IP 풀로 한다. (Part 7)이 글은 누구를 위한 글인가같은 방화벽에서 직원용과 외부 파트너용 원격접속 터널을 분리하고 싶은 사람. 특히 EMS가 없는 환경.읽고 나면 왜 터널을 하나 더 만드는 것만으로는 안 되는지, 그리고 실제로 무엇이 필요한지 알게 된다.1. 하려던 것직원용 터널(ra-ipsec)은 이미 동작하고 있었다..
VPN이 아니라 무선 드라이버였다 — 서버만 보다가 놓친 것 (Part 9) 같은 증상으로 검색해 오신 분들께증상: 특정 노트북 모델에서만 IPsec VPN 접속 실패 또는 접속 후 수십 초~수 분 뒤 끊김. 다른 장비는 동일 프로파일로 정상. 환경: Windows 10/11 / Intel Wi-Fi 6 AX201 / FortiClient 7.4.3 결론: 두 가지 클라이언트 측 원인. ① 무선 드라이버가 심하게 구형 (2020년 버전), ② 어댑터 고급 설정의 MIMO 전력 절감 모드가 "SMPS" 로 되어 있어 마이크로 단절이 발생. 조치: 드라이버 최신화 + MIMO Power Save Mode를 "No SMPS" 로 변경. 추가: 장치 관리자에 남은 중복 Fortinet 가상 어댑터(#2, #3 등)도 별개 원인으로 확인됐다. 검색 키워드: Intel AX201 VPN d..
IKE-over-TCP로 절반이 실패했다 — 설정으로는 고칠 수 없는 것이었다 (Part 8) 같은 증상으로 검색해 오신 분들께증상: IPsec dialup을 TCP transport로 설정했을 때 약 50% 확률로 접속 실패. TCP 3-way handshake는 성립하고, 약 15초 무응답 후 RST. IKE 로그에는 IKE SA: created 1/1 / IPsec SA: created 0/0으로 남고 FortiClient UID는 공란. 환경: FortiGate 201F / FortiOS 7.4.11 / FortiClient 7.4.3 VPN-only / IKEv2 + EAP-TTLS 결론: 설정 계층에서 해결되지 않았다. IKE 프래그먼트가 여러 TCP 세그먼트에 걸쳐 도착할 때 재조합이 실패하는 것으로 관측됐고, 우리가 시도한 모든 설정 조정은 발생 확률만 바꿨다. 당장 할 수 있는 것..
다시 한다면 무엇을 바꿀까 — 그리고 아직 끝나지 않은 것들 (Part 12) 결과 먼저약 150명이 IPsec VPN으로 전환됐다. 추가 라이선스 비용은 0원이었다. 2단계 인증은 유지됐다.그리고 하나의 문제는 아직 해결되지 않았다. TCP transport 경로의 실패는 회피 중이고 근본 원인은 벤더 대응 대기 상태다.이 편은 자랑도 반성문도 아니다. 순서를 바꿨어야 했던 것과, 남은 부채의 목록이다.1. 다시 한다면 순서를 바꿀 것1순위 — 클라이언트 환경 조사를 먼저 한다이게 가장 큰 후회다.서버 구축부터 시작했다. 그게 재미있는 부분이니까. 그런데 실제 문제의 상당 부분은 클라이언트에서 나왔다. 6년 전 무선 드라이버, 전력 절감 옵션, 인증서 미설치, 중복 가상 어댑터. (Part 5, 9)전부 사전 조사로 발견 가능했다. 그리고 사전에 발견하면 일괄 처리가 가능한데, ..
authusrgrp를 쓰면 방화벽 정책의 그룹 매칭이 죽는다 — 문서에 없던 상호작용 (Part 7) 같은 증상으로 검색해 오신 분들께증상: IPsec dialup + EAP 구성에서 방화벽 정책에 set groups 또는 set users를 넣으면 트래픽이 매칭되지 않고 차단됨. 인증은 정상적으로 성공함. 환경: FortiGate / FortiOS 7.4.11 / Phase1에 set eap enable + set authusrgrp 결론: Phase1에서 EAP를 통해 인증하면 FortiGate가 사용자 신원을 세션에 바인딩하지 않는다. 따라서 정책 수준의 사용자/그룹 매칭이 성립하지 않는다. 우회로: 그룹별로 IP 풀 대역을 분리하고, 정책의 srcaddr에 그 대역 주소 객체를 쓴다. 검색 키워드: authusrgrp policy group match IPsec EAP user identity p..
transport_mode="tcp"는 조용히 무시된다 — 우연히 동작했던 프로파일의 정체 (Part 6) 같은 증상으로 검색해 오신 분들께증상: FortiClient 프로파일에 TCP transport를 설정했는데 실제로는 UDP로 접속됨. 오류 메시지 없음. 또는 같은 설정이라고 생각한 두 프로파일의 동작이 다름. 환경: FortiClient 7.4.3 / FortiOS 7.4.11 결론: XML의 transport_mode는 숫자만 유효하다. 0=UDP, 1=TCP, 2=Auto. "tcp" 같은 문자열은 검증 오류 없이 무시되고 UDP 기본값으로 동작한다. 추가: 2(Auto)는 7.4에서 의미가 없다. UDP→TCP 폴백은 7.6 계열의 기능이다. 검색 키워드: FortiClient transport_mode IPsec over TCP not working wrong transport phase 1 ..
IKE는 붙는데 인증이 안 된다 — 원인이 하나가 아니라 다섯 개였다 (Part 5) 같은 증상으로 검색해 오신 분들께증상: IKEv2 dialup + EAP-TTLS 구성에서 인증이 실패하거나, 인증은 성공하는데 트래픽이 통하지 않음. 실패 양상이 시도마다 다름. 환경: FortiGate 201F / FortiOS 7.4.11 / FortiClient 7.4.3 / FreeRADIUS 3.0.20 결론: 독립적인 원인 5개가 동시에 존재했다. 하나를 고칠 때마다 증상이 바뀌어서 계속 헛다리를 짚었다. 핵심 교훈: 증상이 시도마다 다르면 원인이 하나가 아니라고 가정하고, 원인을 세는 방식으로 접근한다. 검색 키워드: IKE SA created EAP-TTLS authentication failed sites-enabled FortiClient eap_method assign-ip-from..