IT 잡부의 취미공간

0. 환경

MSSQL Server: Window Server 2019 Standard Version 1809 (Build 17763.9121)

Pure Storage: FA-C50R5 Purity//FA 6.9.5

1. 개요

OpenStack 기반 Window Server VM을 신규로 구성한 이후, MSSQL MSCS 클러스터 구성을 위한 초기 세팅을 진행하였다. OS(C:)와 DATA(D:)의 경우 Cinder가 관리하는 볼륨으로 생성/사용하였다.

 하지만 DB에서 사용할 볼륨의 경우 초기 클러스터 구성 시 scsi-3 pr을 통과할 수 없어 iSCSI를 이용하여 PureStorage와 직접 연결하여 구성하였다. (Cinder와 호환 이슈)

OpenStack Host에서 각 VM에 할당할 인터페이스를 물리적으로 분리 및 구분할 필요가 있었다.

(DB 통신 용도이므로 타 서비스 트래픽과 분리를 위함)

따라서 아래 구성도에 따라 인터페이스 당 2개, 총 4개 세션으로 MPIO iSCSI 연결 및 구성하였다.

처음에는 Path가 Redundant 상태였으나 윈도우 서버와 퓨어스토리지 간 iSCSI 구성을 한 이후 일정 시간이 흐르자 세션 불균형을 확인할 수 있었다. (Uneven)

스토리지 포트 연결은 각 컨트롤러에 2개씩 정상적으로 보이나 Uneven 상태인 점이 이상하여 트러블슈팅을 진행하였다.

2. 원인 분석

2-1) 스토리지에서 iSCSI 세션 연결 정보 확인

1.아래 명령어를 이용하여 연결 세션 정보를 확인하자 바로 아래와 같이 이상한 점을 확인할 수 있었다.

# purehost list --all GWSQL1

위와 같이, 모든 볼륨에 동일하게 Target Port에 동일한 CT0.ETH12가 4개 존재하는 것을 확인할 수 있었다. (GWSQL2 동일)

 개요의 구성도에서 확인할 수 있듯이 iSCSI용 인터페이스를 2개로 분리 및 각자 다른 VLAN을 할당하였기에 세션은 4개가 구성되는 것이 설계대로였다. 따라서 다음에는 윈도우 서버 쪽에서 확인을 진행하였다.

2-2) 윈도우 서버에서 iSCSI 세션 연결 정보 확인

1. 윈도우 서버에 접속하여 iSCSI 초기자 속성의 즐겨찾는 대상을 확인한 결과 7개의 세션 정보를 확인할 수 있었다. 

2. 이후 powershell에서 Get-IscsiConnection 명령어를 이용하여 확인한 결과, 아래와 같이 InitiatorAddress가 중복되어 세션이 생성된 것을 확인할 수 있었다. (0.0.0.0 2개, 10.101.92.131 1개)

3. 관련 이슈 검색

Everpure 공식 사이트에서 해당 이슈에 대한 레퍼런스가 있는 지 체크하였고, 2개의 분리된 VLAN에서 문제가 발생될 수 있음을 확인하였다.

https://support.everpuredata.com/r/microsoft-platform-guide/how-to-configure-windows-host-to-connect-via-2-separate-vlans-to-the-same-array-using-powershell

이에 대한 해결책으로 Powershell을 이용하여 Initiator IP와 Target Portal IP를 지정하여 연결을 생성하는 방식이었다.

4. 해결 및 최종 확인

아직 MSSQL 서버 구성 단계이므로 서비스에 영향은 없기에, MSSQL#2 서버부터 순차적으로 진행하였다.

4-1) MSSQL#2 서버 기존 세션 및 포털 전체 제거

1. powershell에서 아래 명령어를 이용하여 기존 iSCSI 세션을 전체 제거한다.

> Get-IscsiSession | ForEach-Object {
    Disconnect-IscsiTarget -SessionIdentifier $_.SessionIdentifier -Confirm:$false
}

2. iSCSI 초기자 속성에서 즐겨찾는 대상 탭에서 모든 대상을 전체 제거한다.

3. 아래 명령어로 포털을 모두 제거한다.

> Get-IscsiTargetPortal | Remove-IscsiTargetPortal -Confirm:$false

4. 완전히 연결이 제거되었는지 확인한다.

> Get-IscsiTargetPortal
> Get-IscsiSession
> Get-IscsiTarget

4-2) MSSQL#2 서버 iSCSI 연결 재구성

1. Everpure 사이트에서 확인한 정보를 기반으로 아래에 iSCSI 연결 재구성 스크립트를 작성 후 Powershell에서 적용한다.

** 본 작업 스크립트 (MSSQL#2 서버) **
$nic1 = "10.101.92.131"
$nic2 = "10.101.93.131"
$target1 = "10.101.92.2"
$target2 = "10.101.92.3"
$target3 = "10.101.93.2"
$target4 = "10.101.93.3"

New-IscsiTargetPortal -InitiatorPortalAddress $nic1 -TargetPortalAddress $target1 -InitiatorInstanceName "ROOT\ISCSIPRT\0000_0"
New-IscsiTargetPortal -InitiatorPortalAddress $nic2 -TargetPortalAddress $target3 -InitiatorInstanceName "ROOT\ISCSIPRT\0000_0"
Start-Sleep -Seconds 2

$targetname = (Get-IscsiTarget)[0]

Connect-IscsiTarget -InitiatorPortalAddress $nic1 -TargetPortalAddress $target1 -IsMultipathEnabled $true -NodeAddress $targetname.NodeAddress -IsPersistent $true
Connect-IscsiTarget -InitiatorPortalAddress $nic1 -TargetPortalAddress $target2 -IsMultipathEnabled $true -NodeAddress $targetname.NodeAddress -IsPersistent $true
Connect-IscsiTarget -InitiatorPortalAddress $nic2 -TargetPortalAddress $target3 -IsMultipathEnabled $true -NodeAddress $targetname.NodeAddress -IsPersistent $true
Connect-IscsiTarget -InitiatorPortalAddress $nic2 -TargetPortalAddress $target4 -IsMultipathEnabled $true -NodeAddress $targetname.NodeAddress -IsPersistent $true

4-3) 작업 정상 여부 확인 및 MSSQL#1 서버에도 동일 작업 진행

1. 아래 명령어를 이용하여 작업이 의도된 대로 진행되었는지 확인한다.

> Get-IscsiTargetPortal
> Get-IscsiSession
> Get-IscsiTarget

2. MSSQL#2 서버 리부팅 이후에도 증상이 동일한지 확인한다.

3. 장애 조치(Failover) 클러스터 관리자에서 클러스터 소유자 노드를 MSSQL#2번 서버로 넘긴 이후 MSSQL#1번 서버에서도 동일한 작업을 반복 수행한다. (단 스크립트는 IP 변경 필요)

4. MSSQL#2 서버에 작업이 완료된 이후 다시 클러스터 소유자 노드를 MSSQL#1 서버로 전환하여 작업을 완료한다.

* 장애 조치 클러스터 관리자에서 소유자 노드 변경 방법

A. 실행 창에서 cluadmin.msc 입력하여 장애 조치 클러스터 관리자 실행

B. 좌측 탭에서 클러스터 확장 -> 역할을 클릭하고 모든 객체에 대해 이동 -> 노드 선택

C. MSSQL#2 서버를 선택하고 확인을 클릭, 모든 역할에 대해 반복 수행한다.

D. 클러스터를 우클릭 -> 추가 작업 -> 코어 클러스터 리소스 이동 -> 노드 선택을 클릭한다.

E. C와 동일하게 MSSQL#2 서버를 선택하고 확인을 클릭하여 이동을 완료한다.

4-4) 스토리지 정상 여부 확인

1. 퓨어스토리지 관리 GUI 접속 이후 Health -> Connections 에서 서버가 정상적으로 Redundant 상태인지 확인한다.

2. CLI에서 purehost list --all GWSQL1, purehost list --all GWSQL2 명령어를 사용하여 정상적으로 4개 세션이 수립되었는지 확인한다.

5. 모니터링

작업 후 대략 3일이 지났으나 아직까지 해당 증상은 나타나지 않았다. 다시 관련 증상이 발생될 경우 추가적으로 수정을 진행할 예정이다.

1. 개요

FortiGate 펌웨어 v7.4.9 버전 업그레이드 이후 구글 G suite SAML SSO 연동 불가 증상이 발생하였다. SAML SSO 로그인 시도 시 아래와 같은 에러가 발생되며 더 이상 인증이 진행되지 않는 증상이 발생하였다. (400 Error)

2. 증상 및 해결책

FortiGate v7.2.12, v7.4.9, v7.6.4부터 SAML 응답에 대해 서명값을 검증하도록 동작이 변경되면서 생긴 문제로, Azure에서는 해당 기능을 지원하고 있으나 구글 G suite에서는 지원하고 있지 않아 발생되는 문제다.

https://docs.fortinet.com/document/fortigate/7.6.4/fortios-release-notes/684249/saml-certificate-verification

해결책은 현재로서 버전 다운그레이드밖에는 없으므로, 펌웨어 버전 업그레이드 이전에 G suite SAML SSO 연동을 사용 여부에 대해 확인이 필요하다.

3. 내용 업데이트 (26/09/06)

FortiOS v7.4.10 에서 해당 이슈가 수정되었다. 아래 명령어를 통해서 SAML 응답 메세지 또는 SAML assertion 중 하나만 유효하더라도 되도록 설정 변경이 가능하게 되었으며, Default로 기존 동작을 수행하게 변경되었다.

https://docs.fortinet.com/document/fortigate/7.4.10/fortios-release-notes/684249/saml-certificate-verification

1. 개요

- OS: Rocky Linux 8.6 / NFS v4 사용

문서중앙화 프로젝트 수행 중, 리눅스 서버가 Unity 스토리지에 NFS로 마운트하여 문서 파일들을 불러오는 구조로 인프라가 구성되어 있었다. 간략히 작성한 구성도는 아래와 같다.

HTTP 서비스의 경우에는 L4에서 Active-Active로 로드밸런싱되며 (Hash) DB 이중화의 경우 서버에 설치된 이중화 솔루션을 통해 Active-Passive로 이중화되어 있는 구조다.

1-1) 장애 증상

간헐적이고 불규칙적으로 30분 ~ 4시간동안 사용자의 문서 열기는 문제가 없으나 (Read) 문서를 저장할 때 (Write) 몇 분 정도의 긴 시간이 소요

1-2) 장애 발생 시간 및 대상

6건의 장애 발생 시간을 모두 분석한 결과 겹치는 시간대는 아예 없었으며, 심지어 업무 종료 이후 시간에도 발생하였다.

해당 증상은 운영서버#1에서 발생하기도 하고, 운영서버#2에서 발생하기도 하고, 동시에 발생하기도 했다.

1-3) 분석 내용

네트워크의 경우 전체적인 CPU 사용량, 메모리 사용량, 그리고 실시간 트래픽 사용량과 인터페이스 Duplex등의 상태 등 모두를 분석해보았을 때 트래픽이 많은 시간대는 아니었다. 그리고 Ping Loss 또는 지연시간이 밀리는 증상 역시 없었다.

스토리지의 경우, 스토리지의 리소스 역시도 안정적이었으며 I/O 사용량도 그렇게 많지 않았다. 

단서가 되었던 것은 서버의 경우인데 top 명령어를 입력했을 때 아래와 같이 192.168.1.4 (스토리지 NFS IP)-m 이라는 프로세스가 CPU 100%를 계속하여 점유하고 있던 것으로 확인되었다.

해당 프로세스는 커널 프로세스로, kill 커맨드로도 종료할 수 없었고 방법은 오직 서버를 리부팅하는 것 뿐이었다.

(하지만 전환 과정 동안 서비스 중단 및 데이터 유실이 우려되어 실제로는 진행하기 어려웠다)

그리고 커널 내에서 발생되는 증상이었기에 OS에서 로그를 전부 분석하더라도 NFS를 포함하여 그 어떠한 특이 로그도 확인되지 않았다.

관련된 증상에 대하여 구글링을 하더라도 그 어떤 답도 찾을 수 없었다. 다른 Side Effect로 인하여 발생된 증상으로 처음에는 추측하였기에, 모든 구간의 장비를 (서버, L4, 스토리지, 스위치, 회선, 방화벽) 전수조사하였으나 어떠한 특이점도 확인되지 않았다.

어쨌든 NFS가 관련되어 있음은 확실해 보였다.

2. 해결 과정

2-1) 커널 디버그 시행

전수조사를 했음에도 특이점이 없다고 판단, ftrace를 통해 서버의 커널 디버그를 시행하는 거 밖에는 방법이 없다고 판단하였다.

ftrace를 실행하자 해당 프로세스의 CPU가 100%에 바로 도달하였고, 확실히 무언가 이슈가 있긴 하다는 것을 짐작할 수 있었다.

그리고 결과물 파일을 열자 아래와 같은 증상을 확인할 수 있었다.

1. nfs_server_return_marked_delegations () 함수가 nfs_is_valid_delegation() 을 0.000001초 단위로 호출하고 있었다.

2. NFSv4의 delegation (위임) 상태 확인 수행 과정에서 루프가 발생하는 것으로 추측하였다.

* Delegation (위임): NFSv4의 기능으로, NFS 서버가 (스토리지) NFS 클라이언트 (서버) 에게 파일 관리를 위임하는 기능이다.

- Read Delegation: 동시 부여 가능

- Write Delegation: 동시 처리는 불가하며 순차 처리로 성능 부하 시 쓰기 속도 저하 발생 -> 현재 발생 증상과 깊은 관련 확인

즉, NFSv4에서 처리 효율화를 위한 Delegation 기능으로 인한 이슈로 볼 수 있었다.

2-2) Delegation.c 코드 분석

① nfs4_is_valid_delegation 단계에서 delegation이 반환 대상이나

② inode가 null이어서 처리 못하는 delegation이 goto restart 구문에서 루프 발생

2-3) 버그 리포팅 확인

https://bugzilla.redhat.com/show_bug.cgi?id=2176575 링크에서 동일한 증상의 버그 리포팅을 간신히 확인할 수 있었다.

그리고 실제로 해당 버그로 인해 delegation.c 소스 코드가 수정된 것도 확인할 수 있었다.

(참고 링크: https://patchwork.kernel.org/project/linux-nfs/patch/6c85bc9cc6bd8d70fe0e74b096c72944f61874a7.1692903063.git.bcodding@redhat.com/#25515705)

2-4) 조치

소스 코드는 수정되었더라도 커널 버전을 한참 올려야 했기에, NFSv3으로의 다운그레이드를 통해 delegation 기능 자체를 사용하지 않고 우회하는 것으로 결정하였다. 그 이후 간헐적으로 발생되는 증상은 아예 해소되었고 지옥에서 벗어날 수 있었다.

3. 정리

커널 버그로 인한 증상으로 네트워크에서도, 서버에서도, 스토리지에서도 그 어떠한 특이 로그를 확인할 수 없는 이슈였으며 불규칙적이고 간헐적으로 발생되는 증상으로 트러블슈팅이 매우 어려웠다. 이슈 발생 기간 동안 엄청난 공포와 스트레스였으며.. (커널 프로세스라 복구법이 리부팅) 아무튼 해결이 된 후 한참 지난 후에 내용을 공유한다.

이 증상으로 인해 고통받는 누군가가 있으면 도움이 되기를 빈다.

0. FortiCloud 로그 적재 서비스

FortiGate의 경우 무료로 7일 동안은 FortiCloud를 통해서 로그를 적재할 수 있는 기능을 지원한다.

라이선스를 구매할 경우 1년까지 로그 적재 기간이 늘어나며, 해당 기능은 IPS 등의 라이선스와 같은 1년 단위 구독 방식이다.

위와 같이 로그를 보는 창에서 FortiGate 클라우드라는 탭이 추가되며, 클라우드에서 로그를 불러와 사용자에게 FortiGate의 UI에서도 로그를 확인할 수 있도록 기능을 제공해준다.

(빨간 하이라이트 버튼을 클릭할 경우 메모리도 확인 가능 / Summary의 경우 메모리에서 확인 불가능하며 Logs 버튼을 클릭하여 확인해야 함)

1. 이슈 개요

FortiGate 클라우드로 로그를 불러오려고 하자 로그 자체의 데이터가 없다고 나오는 증상이 발생하였다. 하나의 고객사가 아닌 다수의 고객사에서 동시다발적으로 발생하였다. (25년 10/07일부터 발생)

2. 이슈 원인

FortiOS가 최신버전이 아닐 경우 FortiCloud Free 라이선스 사용자는 로그 적재 서비스가 정상적으로 연동되지 않는다.

해당 내용의 근거는 아래 메일과 같다.

따라서, 최신 펌웨어로 업그레이드를 해야만 (글 작성 시점 v7.2버전의 경우 v7.2.12) 정상적으로 적재가 가능하다.

3. 예외사항?

일부 오래된 펌웨어 버전의 경우 그대로 적재되는 증상이 있는데, 해당 기준에 대해서는 명확하게 확인하지 못했다. 해당 내용에 대해서는 디테일하게 알기 위해서는 TAC 문의가 필요할 것으로 보인다.

얼마 전 신규로 SSL VPN 용도로 장비를 구축했던 고객사 담당자님께서 Windows 특정 PC 인터넷 불가로 인해 문의를 주셨다. SSL VPN 그룹은 하나로 관리되고 non-split 구성이었다. (모든 인터넷 트래픽이 VPN으로 향함)

SSL VPN의 경우 다양한 사용자 PC 환경이 존재하고 충돌될 수 있는 프로그램도 (타 VPN 프로그램) 존재하기에 사용자 PC부터 방화벽까지 모든 구간을 확인해야 하므로 꽤나 번거롭고 실제로 이슈가 간헐적으로 발생한다.

(심지어 장애 시 업무 불가이기 때문에 꽤나 민감한 문제다)

심지어 책임 소재도 애매한데, 다른 사용자가 정상이라면 문제가 발생된 사용자의 환경 문제로 치부할 수 있어 정말 발생될 때마다 머리가 지끈거리는 문제라고 볼 수 있겠다.

사용자의 현상을 정리하면 아래와 같다.

1. SSL VPN 연결 시 인터넷 통신 불가

2. FortiClient를 통해 SSL VPN 연결은 정상

3. 테더링으로 연결 후 SSL VPN 사용 시에는 정상

장비 접속 전 예상되는 원인을 머리 속으로 정리했다.

1. Windows와 FortiClient 간 호환성 이슈

1. 해당 이슈로 라우팅 테이블을 정상적으로 받아오지 못함 (아직 해당 case는 본 적 없다)

2. 사용자 PC 내 FortiClient의 가상 인터페이스로 IP 할당이 되지 않음 (윈도우 KB2693643 업데이트 이슈)

https://community.fortinet.com/t5/FortiClient/Troubleshooting-Tip-VPN-SSL-connected-but-no-IP-address-in/ta-p/248143 

-> 해당 이슈일 경우 사용자 PC 환경은 동일하여 테더링으로 연결했을 때에도 증상이 동일했어야 한다. 그러므로 제외.

이외에도 정말 수많은 것이 떠오르기에 나중에 따로 정리하겠다..

2. 모종의 사유로 인한 FortiGate에서 패킷을 전달하지 않음

해당 이유도 테더링 시 정상이었기에 생각하기 어렵다.

3. 그럼 뭘까?

문제가 되는 사용자분께 접속 테스트를 요청드린 뒤, 무적의 패킷 스니핑으로 원인을 분석했다.

트래픽은 FortiGate로 정상적으로 도달했고, 몇몇 패킷도 정상 통과함을 확인했다.

다만 사용자 PC의 DNS 서버가 사설 IP로 설정되어 있는 점을 확인하였다.

(추측해보면 이 DNS 서버는 내부 DNS고, 어느정도 네트워크가 구성된 공간에서 원격 근무 중이라고 유추할 수 있다.)

원래 사용자의 환경으로 내부에서 진행되어야 할 DNS 통신이 FortiGate로 향하면서 발생된 문제임을 알 수 있다.

(사설 IP를 가진 내부 DNS이므로)

FortiGate의 SSL VPN 기본 설정은 "Same as client system DNS" 설정으로, 클라이언트의 (사용자 PC) DNS 설정을 따르도록 되어 있다. 그래서 이걸 "Specify" 옵션을 통해 ISP의 DNS 주소로 변경하도록 설정을 진행하였다.

이후 사용자 분께 다시 접속을 요청드리니 정상 접속을 확인하였다. 빠르게 해결할 수 있어 다행임에 안도하며 다시 일을 하러 가자..

FortiGate는 FortiOS 7.0 버전 이후부터 ACME (Automated Certificate Management Environment) 를 이용하여 Let's Encrypt와 연동 후 SSL 인증서를 무료로 사용할 수 있는 기능을 제공하고 있습니다. 인증서는 90일 단위로 갱신이 필요하며 FortiGate는 자동으로 갱신 처리를 진행하기에 계속 인증서를 사용할 수 있습니다.

Let's Encrypt란? 

무료 인증서 보급을 통해 HTTPS를 확산시키겠다는 취지로 시작된 비영리 프로젝트입니다. 

사용하기 위한 제약조건은 아래와 같습니다.

1. FortiGate는 공인 IP를 가지고 있어야 하며, 그 공인 IP와 매핑된 도메인이 필요합니다. (A 레코드)
2. ACME 인터페이스는 인터넷 구간과 연동이 될수 있어야 하며, 80 (HTTP) 또는 443 (HTTPS) 포트에 대한 VIP 설정 (NAT, 포트포워딩) 이 없어야 합니다.
3. SAN 필드가 매핑된 도메인으로 자동으로 설정되어 편집이 불가하기에 와일드카드도 사용 불가하며 여러 개의 SAN을 따로 추가할 수 없습니다.

Let's Encrypt를 통해 인증서를 발급받고 나면 할 수 있는 내용은 아래와 같습니다.

1. 방화벽의 웹 인증서를 사설 인증서 -> Let's Encrypt로 발급받은 공인 인증서로 변경함으로서 웹 UI 접근 시 발생되는 보안 경고창 제거 가능
2. FortiClient를 통한 SSL VPN 접속 시, 사설 인증서 사용으로 인해 사용자 연결 단계 40%에서 표출되는 신뢰할 수 없는 인증서 팝업 제거 가능
3. HTTPS -> HTTP 리버스 프록시 구성을 통해 내부 서버에 대한 HTTP (비암호화) 통신을 HTTPS로 암호화 가능

그럼, 아래 과정을 통해 Let's Encrypt를 통해 인증서를 발급받고, 실제로 활용하는 방법에 대해서 다루도록 하겠습니다.

1. Let's Encrypt를 통해 FortiGate에서 인증서 발급

A. GUI에서 인증서 창 활성화를 위해 System -> Feature Visibility -> Certificates, Load Balance 활성화 후 "Apply' 클릭

B. System -> Certificates -> Create/Import -> Certificate 클릭

C. Use Let's Encrypt 클릭

D. 아래 정보들을 적당히 입력한 후, Create 버튼을 클릭합니다.

1) Certificate name: 인증서 이름을 자유롭게 입력

2) Domain: 도메인 주소 입력 (A 레코드 등록 필요) ex) abc.co.kr

3) Email: 관리 이메일 입력 필요 (적당히 입력)

E. ACME 인터페이스는 외부 인터페이스 (wan) 으로 설정한 뒤 대기

F. 문제가 없을 경우 시간이 흐른 뒤 정상적으로 생성되었다는 메세지 표출

2. 발급받은 인증서를 FortiGate에 적용

1) SSL VPN에 적용

• VPN -> SSL-VPN Settings -> Server Certificate를 발급받은 인증서로 변경 -> Apply 버튼을 눌러 적용

2) 웹 GUI에 적용

• System -> Settings -> HTTPS server certificate를 발급받은 인증서로 변경 -> Apply 버튼을 눌러 적용

3. 적용 테스트

1) SSL VPN

• FortiClient의 연결 설정 창에서 IP 대신 방화벽과 매핑한 도메인 정보를 입력한 뒤, 40%에서 보안 경고창이 표출되는지 확인

2) 관리 웹 UI 접속

• 매핑한 도메인을 통해 ex)https://abc.co.kr 접속 시도한 후 보안 경고창이 표출되는지 확인

*** HTTPS (443) 포트를 포트포워딩으로 사용하고 있을 경우

HTTP (80) 또는 HTTPS (443) 포트를 ACME 데몬이 사용하는데, 외부 HTTPS (443) 포트에 대한 VIP 객체가 있을 경우 즉시 HTTP (80) 포트로 ACME 데몬이 시도하게 하기 위해 아래 설정을 진행합니다.

A. System -> Settings -> Telnet port를 443으로 변경 

위 과정을 거치게 되면 ACME 데몬은 HTTPS (443) 포트 대신 HTTP (80) 포트로 즉시 시도하게 됩니다.

참고로 텔넷 포트로 설정한 이유는 보안 상의 이유로 잘 쓰지 않는 프로토콜이기 때문입니다.

참고 링크

https://docs.fortinet.com/document/fortigate/7.0.0/new-features/822087/acme-certificate-support

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Let-s-Encrypt-failing-to-provision-due-to-VIP/ta-p/265830

SAML을 이용해 FortiGate를 SP(Service Provider) 로 하고, keycloak을 idP로 하여 keycloak의 계정을 통해 FortiClient SSO로 SSL VPN을 연결하는 방법에 대해서 다루겠습니다.

이를 위해서 저의 경우에는 1. 쿠버네티스에서 keycloak을 배포하고 2. Let's Encrypt를 통해 인증서를 발급받고 3. Load Balance 기능을 통해 https 통신을 리버스 프록시 구성으로  keycloak 서버에 http로 전달하고 4. SAML SSO 연동 설정을 통해 keycloak에 생성된 계정으로 SSL VPN 연결하는 과정까지 진행하도록 하겠습니다.

1. 쿠버네티스에서 keycloak 배포

A. yaml 파일 작성

저의 경우 Ingress를 사용하지 않고 간단하게 nodePort 설정을 통해 구성하였습니다.

• 최초 접속 포트: http://쿠버네티스 서버 IP:[노드 포트] yaml 파일 상 30082 포트
• 최초 접속 계정: admin / admin

vi dep.yaml

apiVersion: v1
kind: Service
metadata:
  name: keycloak
  labels:
    app: keycloak
spec:
  ports:
    - name: http
      nodePort: 30082
      port: 8080
      targetPort: 8080
  selector:
    app: keycloak
  type: NodePort
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: keycloak
  labels:
    app: keycloak
spec:
  replicas: 1
  selector:
    matchLabels:
      app: keycloak
  template:
    metadata:
      labels:
        app: keycloak
    spec:
      containers:
        - name: keycloak
          image: quay.io/keycloak/keycloak:26.0.2
          args: ["start-dev"]
          env:
            - name: KEYCLOAK_ADMIN
              value: "admin"
            - name: KEYCLOAK_ADMIN_PASSWORD
              value: "admin"
            - name: KC_PROXY
              value: "edge"
          ports:
            - name: http
              containerPort: 8080
          readinessProbe:
            httpGet:
              path: /realms/master
              port: 8080

B. keycloak namespace 생성

kubectl create namespace keycloak

C. keycloak namespace에 배포 진행

# 배포 진행 (service, deployment 생성 확인)
kubectl apply -f dep.yaml -n keycloak
service/keycloak created
deployment.apps/keycloak created

# pod 상태 확인
kubectl get pods -n keycloak
NAME                        READY   STATUS    RESTARTS   AGE
keycloak-5bb4bd5c44-wh9w9   1/1     Running   0          107s

D. http://[쿠버네티스 서버 IP]:[노드 포트] 로 접속

yaml 파일 기준

• 접속정보: http://[쿠버네티스 서버 IP]:30082
• 계정: admin / admin

여기까지 했으면 keycloak은 우선 접어두고, 방화벽에서의 설정을 진행하겠습니다.

24.10.30 추가

만약 keycloak을 접속하시는 IP가 사설 IP가 아니실 경우, (즉 쿠버네티스의 IP가 사설 IP가 아닐 경우) https로의 로그인이 강제됩니다. 

해당 사유는 HTTPS required 설정 때문인데 Default는 External requests 설정이기 때문입니다.

(localhost 또는 사설 IP는 http로 접속 허용 / 이외 통신은 https 강제)

위 상황에서는 해당 설정을 직접 pod으로 접속하여 수정이 필요합니다. (또는 yaml 파일 수정하여 https 포트 설정 추가)

# pod 이름 확인

$ kubectl get pod -n keycloak
NAME                        READY   STATUS    RESTARTS   AGE
keycloak-849cc54dcd-ppnnx   1/1     Running   0          3d5h

# pod bash shell 접속
kubectl exec keycloak-849cc54dcd-ppnnx -n keycloak -it -- bash

# /opt/keycloak/bin/ 경로로 이동 (26 버전 기준)
cd /opt/keycloak/bin

# 로그인 진행, 패스워드 입력
$ ./kcadm.sh config credentials --server http://localhost:8080 --realm master --user admin (계정명)
Logging into http://localhost:8080 as user admin of realm master

# Required SSL 설정 변경
./kcadm.sh update realms/master -s sslRequired=NONE

2. Let's Encrypt를 통해 FortiGate에서 인증서 발급

아래 링크를 참고하여 설정을 진행합니다.

https://ratril.tistory.com/49

3. FortiGate의 Load Balance 기능을 통해 HTTPS 통신을 HTTP로 keycloak에 전달

A. System -> Feature Visibility -> Load Balance -> Apply를 적용하여 기능을 GUI에서 보이게 설정

B. Policy & Objects -> Virtual Servers -> Create New 클릭

C. 아래와 같이 각자의 환경에 맞게 정보를 입력합니다.

1. Name: 식별하기 쉬운 객체명 입력
2. Type: HTTPS
3. Interface: 회선 연결 인터페이스
4. Virtual server IP: Let's Encrypt로 인증서 발급받은 도메인의 공인 IP
5. Virtual server port: 외부에서 접근할 포트 정보
6. SSL offloading: Client <-> FortiGate로 설정 (Client - FortiGate는 HTTPS 통신, FortiGate - Server는 HTTP 통신)
7. Certificate: Let's Encrypt로 발급받은 인증서로 설정
8. Create New 버튼 누른 뒤 Address는 내부 Keycloak 서버 IP, 포트는 접속 포트로 설정

D. 우선 인터페이스 설정만 옳게 들어간 설정을 GUI에서 추가한 뒤, CLI에서 아래 추가 설정을 진행합니다.

(이유: 정책 inspection-mode가 Proxy여야 객체를 추가할 수 있으나, FG-40F 같은 메모리가 적은 소형 장비의 경우 GUI에서 해당 설정 변경 불가)

config firewall policy
edit <생성한 정책 ID>
set inspection-mode proxy
set srcaddr all
set dstaddr keycloak 
end

E. Keycloak에 로그인 후, Realm settings -> Frontend URL을 https://[Virtual server IP(도메인 IP)]:[Virtual Server Port] 로 변경 후 Save 버튼을 클릭합니다.

F. E에서 설정한 Frontend URL로 정상 접속이 가능한지 확인합니다.

* 이 과정은 정상적으로 외부 접속이 가능한 지 테스트하는 과정으로, Master realm은 굳이 외부 접속이 필요하지 않기 때문에 추후 외부 접속 차단을 권고합니다.

4. FortiGate와 Keycloak 간 SSO 연동

1. 신규 realm 생성 및 기본 정보 확인

A. 새로운 적당한 이름으로 realm을 생성합니다.

B. 좌측 탭 Realm settings -> Fronted URL을 입력 (https://서버 IP:포트) -> Save 버튼을 클릭합니다.

* 여기서의 Frontend URL이 실질적으로 사용자가 SSL VPN 로그인 시 연결되는 주소입니다.

C. SAML 2.0 Identity Provider Metadata를 클릭하여 새 창을 열고, 해당 창은 우선 띄워둡니다.

2. Keycloak의 인증서 추출 및 FortiGate에 등록

A. 1의 마지막 과정에서 확인한 SAML 메타데이터의 ds.X509Certificate 헤더 내에 있는 값을 복사한 뒤 메모장을 열고

-----BEGIN CERTIFICATE-----

ds.X509Certificate 헤더 내 값 복사

-----END CERTIFICATE-----

위와 같이 입력한 후, "REMOTE_Cert_1.cer" 이라는 이름으로 저장합니다.

* 타 이름으로 저장 시 방화벽에서 Import 시 형식 에러 발생됨

B. FortiGate에 접속한 후 System -> Certificates -> Create/Import -> Remote Certificate 버튼을 클릭합니다.

C. A의 과정에서 생성한 인증서 파일을 선택하고 OK 버튼을 클릭합니다.

3. FortiGate에서 SSO 설정

A. User & Authentication -> Single Sign-On -> Create new 버튼을 클릭합니다.

B. 아래 내용을 참고하며 내용을 입력합니다.

• Name: 적당히 입력
• Address: [도메인]:[SSL VPN 설정 포트] ex) abc.co.kr:10443
• Entity ID, Assertion consumer service URL, Single logout service URL 는 keyclaok에서 입력해야 하므로 복사해두기

C. 1의 마지막 단계에서 에서 띄워둔 창을 기반으로 하여 아래를 참고하여 그대로 입력 후 Submit을 눌러 저장합니다.

• Certificate: 2번 단계에서 생성한 인증서 지정
• Attribute used to identify users: username
• Attribute used to identify groups: group

4. Keycloak에서 Client 설정을 통한 연동

A. keycloak으로 돌아와서 좌측 탭에 Clients 클릭 후 Create client 버튼을 클릭합니다. 

B. 아래 이미지를 참고하여 정보를 입력 후 Next 버튼을 클릭합니다.

• Client type :SAML
• Client ID: http://[도메인]:[ssl vpn 포트]/remote/saml/metadata
• Name: 적당히 입력

C. 아래 이미지를 참고하여 정보를 입력 후 Save 버튼을 클릭합니다.

• Valid redirect URIs: https://[도메인]:[ssl vpn 포트]/remote/saml/login
• Valid post logout redirect URIs: https://[도메인]:[ssl vpn 포트]/remote/saml/logout

D. FortiGate의 Attribute와 연동하기 위해 Client scopes -> URI-dedicated 를 클릭합니다.

E. Configure a new mapper 버튼을 클릭합니다.

F. User Attribute를 선택합니다.

G. 아래 이미지와 같이 설정 후 Save 버튼을 클릭합니다.

H. 다시 창으로 돌아와서, Add mapper -> By configuration 버튼을 클릭합니다.

I. Group list를 선택합니다.

J. 아래와 같이 입력한 후 Save 버튼을 클릭합니다.

K. Keys 탭을 클릭한 뒤 Client signature required를 비활성화 합니다.

5. Keycloak의 그룹 및 계정 생성

A. 좌측 탭의 Groups를 클릭한 후 Create Group을 클릭합니다.

B. 그룹 이름을 적당히 입력한 뒤 Create 버튼을 클릭합니다.

C. 좌측 탭의 Users 클릭 -> Create new user 버튼을 클릭합니다.

D. 적당한 username을 입력하고 B의 과정에서 생성한 그룹에 적용시킨 후 Create 버튼을 클릭하여 사용자를 생성합니다.

E. Credentials 탭을 누른 뒤 Set password 버튼을 클릭합니다.

F. 패스워드와 패스워드 확인 란을 반복 입력합니다. Temporary의 경우 임시 패스워드로 지정할 지 여부인데, 활성화되어 있을 경우 사용자가 패스워드를 재설정하게 합니다. 현재 테스트 중이므로 해당 기능은 Off 하였습니다.

6. 새로 생성한 realm에 대하여 Load Balance 설정을 통해 외부 접속 허용

3에서 이미 다뤘던 내용입니다. 로드 밸런싱 객체의 Virutal Server Port (외부 포트)에 대한 설정만 다르므로, 새로 생성한 sslvpn realm에 대한 Frontend URL 정보를 참조하여 해당 과정을 따라 객체를 생성하고 정책에 적용합니다.

7. SAML 연동 group 생성 및 SSL VPN 연관 설정

A. CLI로 접속한 뒤 아래 명령어를 입력합니다.

 # con user group 
 (group) # edit techteam [생성할 그룹 명]
new entry 'techteam' added

 (techteam) # set member keycloak [생성 SSO 객체명]
 (techteam) # con match
 (match) # edit 1
new entry '1' added

 (1) # set server-name keycloak [생성 SSO 객체명] 
 (1) # set group-name techteam [keycloak에서 생성한 그룹명]
 (1) # end 
 (techteam) # end

B. VPN -> SSL-VPN Settings -> Portal에 생성한 그룹 추가 -> Apply를 클릭합니다.

C. 기존에 적용되어 있는 SSL VPN 정책에 새로 생성한 그룹을 추가합니다.

8. 접속 테스트

A. FortiClient의 설정을 아래와 같이 변경합니다. (FortiClient v7.0.13 사용)

B. SAML Login 버튼을 클릭합니다.

C. 아까 생성한 ID와 PW를 입력한 후 Sign In 버튼을 클릭합니다.

D. 정상적으로 연결이 완료됩니다.

어제.. 일요일 방화벽 교체 작업 진행 중 DHCP 관련 처음 보는 증상이 발생하여 처리 내역을 공유합니다.

1. 작업 내역

- 노후화 방화벽 교체 작업

# 기존: FG-100D (v5.6.13) -> 신규: FG-100F (v7.2.10)

2. 증상

- 방화벽 교체 (FG-100D -> FG-100F) 이후 특정 포트에서 DHCP IP 할당 불가 이슈 발생.

3. 확인 내역

1) port 67로 패킷 스니핑하여 DHCP Discover 패킷에 대해 정상적으로 방화벽이 응답을 주는지 확인

dia sni pack any 'port 67' 4

50.424415 internal in 0.0.0.0.68 -> 255.255.255.255.67: udp 300

위 패킷만 확인되고, 방화벽에서의 응답 패킷이 확인되지 않음.

2) DHCP 설정 이상 없고 임대할 IP가 충분함에도 방화벽이 응답을 주지 않는걸로 파악, dhcps debug 진행

dia debug application dhcps -1
dia debug enable

[debug]locate_network prhtype(1) pihtype(1)

[warn]Can't locate subnet in shared network of packet and packet is not a DHCPREQUEST and htype(1) != intf htype(1)..dropping

[debug]locate_network prhtype(1) pihtype(1)

??? 이게 뭐지. 방화벽에서 dropping 하는 Debug를 확인. 해당 내역 확인 결과 언제 설정된건지 모를 DHCP vci 패턴 매칭 설정으로 인한 이슈로 확인됨.

config system dhcp server
edit 2
    set dns-service default
    set ntp-service default
    set default-gateway 192.168.0.1
    set netmask 255.255.255.0
    set interface "internal"
    config ip-range
    	edit 1
        	set start-ip 192.168.0.2
            set end-ip 192.168.0.254
        next
    end
 set timezone-option default
 set vci-match enable   --> 문제의 Config 부분
 set vci-string "FortiSwitch" "FortiExtender" --> 문제의 Config 부분
 next

config system dhcp server

edit 2

set vci-match disable

end

명령어 입력 이후 정상 IP 할당 확인됨.

분명 Config 그대로 마이그레이션했는데 왜 이게 포함되었을까?

- 기존 장비 Config 확인 시에 해당 Config는 확인되지 않음.

- 펌웨어 버전도 v7.2.10 그대로 올렸기에 업그레이드 과정도 없었음

- 기존 장비 Config를 부분마다 스크립트 업로드로 올렸기에 이상하게 넣었을 리도 없음

- 다른 포트는 안들어가있으니 default로 넣어버리거나 하는 건 아닌 듯..

아무튼 저게 왜 들어갔는지는 의문이나 빠르게 해결 완료.

내용 추가 (24.10.16)

곰곰히 생각해보니 문제의 vci Config는 장비에 Default로 포함된 Fortiswitch 연동 관련 DHCP 컨피그입니다.

고객사의 DHCP ID와 Default 설정으로 된 FortiSwitch 연동을 위한 ID가 겹치면서 설정이 덮어씌워지며 발생된 증상으로 보입니다.

따라서, DHCP 서버 설정 관련하여 마이그레이션을 할 때, 모든 Default DHCP Server 설정을 지우고서 마이그레이션 하시는 것이 좋을 것 같습니다.

참고 링크

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Devices-are-unable-to-get-an-IP-address-from-DHCP/ta-p/230320

https://docs.fortinet.com/document/fortigate/7.2.2/administration-guide/59285/vci-pattern-matching-for-dhcp-assignment

어느 정도 FortiGate 장비를 다뤄 보신 분은 잘 아시겠지만, 혹시라도 막히시는 분이 계실 수도 있을 것 같아, 마침 작업 할일이 생겨 변환 방법을 간단히 정리합니다.

1. 장비에 로그인 이후, 우측 상단의 >_ 아이콘을 클릭하여 CLI 콘솔을 엽니다. (또는 SSH, 콘솔 케이블 통해 접근)

2. 아래 명령어를 순차적으로 입력합니다.

con sys interface
edit fortilink
set fortilink disable
end

con sys settings
set opmode transparent
set manageip <IP/서브넷> ex) 192.168.1.99/24
end

3. 정상적으로 모드 변경이 확인됩니다.

* 주의사항

위 fortilink disable 과정을 거치지 않으면 아래 에러 메세지가 발생하니 꼭 해당 과정을 거치도록 합니다.

Cannot Change to Transparent mode because this vdom contains managed switches and switchctl-vlans.

Please clear managed-switches, disable fortilink and retry.

node_check_object fail! for opmode transparent

value parse error before 'transparent'

Command fail. Retrun code -7610

인프런 일프로님의 쿠버네티스 어나더 클래스 강의를 수강하며, 저희 사내 환경에 맞게 쿠버네티스를 설치하는 내용을 다루도록 하겠습니다.

환경

PC: Windows 10

IDE: vscode

HCI: Proxmox VE v8.1.4

IaC: Terraform

OS: Rocky linux 8.10

우선, 제가 구축할 환경은 아래와 같습니다. (빨간색 점선 부분이 추가 부분)

강의에서는 VirtualBox를 사용하였으나, 현재 저는 사내 데스크탑에 Proxmox 서버를 구축해 둔 관계로, 제공해주신 스크립트를 Proxmox에 맞춰 변경하는 작업이 필요합니다. 저는 굳이 VirtualBox를 사용하지 않기 때문에, Terraform을 이용하여 스크립트를 다시 작성하도록 하겠습니다.

Terraform은 아래의 과정을 수행합니다.

1. 템플릿을 기반으로 VM 생성 (CPU, 메모리, SSH Key 등..)
2. SSH key를 이용하여 서버에 접속한 후 쉘 스크립트로 쿠버네티스 설치 진행

1. Proxmox Template 생성

제가 작성한 아래 게시물의 링크를 참조합니다.

https://ratril.tistory.com/42

2. Proxmox API Key 생성

Proxmox 관리 UI 접속 이후 아래 과정을 따릅니다.

- Datacenter 클릭 -> API Tokens 클릭 -> Add 클릭 -> Token ID에 식별할 수 있는 값 자유롭게 입력 -> Priveilege Separation 체크 해제 -> Add 버튼 클릭

이후 표출되는 Secret 값을 복사한 후 잘 저장해둡니다. (생성 시에만 확인 가능)

3. Terraform 코드 작성

일프로님이 작성하신 Vagrant 스크립트를 기반으로 하여 테라폼으로 배포할 수 있도록 스크립트를 아래와 같이 작성하였습니다. 테라폼을 제대로 처음 작성해보는 관계로 코드가 좋지 않을 수 있어 양해 부탁드립니다.

스크립트를 그대로 사용하실 경우 유의하실 점은

1. terraform.tfvars 파일을 자신의 환경에 맞게 적절히 수정
2. ssh private key와 public key를 모두 같은 폴더에 넣고 파일명에 맞춰 terraform.tfvars 내 변수 수정
3. install_k8s.sh 의 경우 파일명을 그대로 유지하며 같은 폴더에 넣을 것

윈도우와 vscode 환경에서 테라폼 구성 시에는 잘 모르시겠다면 아래 제가 진행하다가 작성한 링크를 참고해주세요.

https://ratril.tistory.com/category/IaC/Terraform

A. backend.tf

terraform {
  required_providers {
    proxmox = {
      source  = "Telmate/proxmox"
      version = "3.0.1-rc4"
    }
  }
  backend "local" {
  }
}

B. provider.tf

provider "proxmox" {
  pm_api_url = var.proxmox_endpoint
  pm_api_token_id = var.proxmox_api_token_id
  pm_api_token_secret = var.proxmox_api_secret
  pm_tls_insecure = true  # TLS 검증 비활성화

  # debug
  pm_log_enable = true
  pm_log_file = "terraform-plugin-proxmox.log"
  pm_debug = true
  pm_log_levels ={
    _default = "debug"
    _capturelog = ""
  }
}

C. main.tf

# 마스터 노드 설정
resource "proxmox_vm_qemu" "master_node" {
  name        = "k8s-master"
  target_node = "vm"
  vmid        = 600
  cores       = 4
  memory      = 6144
  scsihw      = "virtio-scsi-pci"
  bootdisk = "order=scsi0"
  clone = var.template_name
  os_type = "cloud-init"
  cpu = "host"
  ipconfig0 = "ip=${var.k8s_ip},gw=${var.k8s_gw}"
  sshkeys = file("${path.module}/${var.pub_ssh_key}")

    disks {
        ide {
            ide2 {
                cloudinit {
                    storage = "main-hdd"
                }
            }
        }

        scsi {
            scsi0 {
                disk {
                    size            = 50
                    storage         = "main-hdd"
                    iothread        = true
                    discard         = true
                }
            }
        }
    }


  # 네트워크 설정
  network {
    model  = "virtio"
    bridge = "vmbr0"
    tag = 56
    firewall = false
    link_down = false
  }

  # 시리얼 포트 추가
  serial {
    id   = 0
    type = "socket"
  }

  connection {
    host = replace(var.k8s_ip, "/24", "")
    type = "ssh"
    user = "rocky"
    private_key = file(var.pri_ssh_key)
  }

  # install_k8s.sh 파일 업로드 및 실행
  provisioner "file" {
    source      = "install_k8s.sh"  # 로컬의 스크립트 경로
    destination = "/tmp/install_k8s.sh"  # 원격 VM 내 저장 경로
  }

  provisioner "remote-exec" {
    inline = [
      "chmod +x /tmp/install_k8s.sh",  # 실행 권한 부여
      "/tmp/install_k8s.sh"            # 스크립트 실행
    ]
  }
}

D. variables.tf

variable "proxmox_endpoint" {
  description = "Proxmox API endpoint URL"
}

variable "proxmox_api_token_id" {
  description = "Proxmox API token id"
}

variable "proxmox_api_secret" {
  description = "Proxmox password or API token"
}

variable "proxmox_node" {
  description = "Proxmox node name"
}

variable "template_name" {
  description = "Proxmox template name"
  type = string
}

variable "pub_ssh_key" {
  description = "Public SSH Key file Name"
}

variable "pri_ssh_key" {
  description = "Private SSH Key file Name"
}

variable "k8s_ip" {
  description = "K8s Master Node IP and subnet"
}

variable "k8s_gw" {
  description = "K8s Master Node GW"
}

F. terraform.tfvars (직접 환경에 맞는 변수를 입력하셔야 합니다)

proxmox_endpoint = "https://[Proxmox IP]:8006/api2/json"
proxmox_api_token_id = "[계정명]@pam![토큰 ID] ex)root@pam!terraform"
proxmox_api_secret = "[토큰 secret]"
proxmox_node = "[proxmox node명 입력] ex)pxe"
template_name = "[proxmox template 이름 입력] ex) rocky-8-10-server-template"
pri_ssh_key = "[ssh private key 파일명 입력] ex) proxmox_key"
pub_ssh_key = "[ssh public key 파일명 입력] ex) proxmox_key.pub"
k8s_ip = "[k8s 마스터 노드 IP/Subnet 입력] ex)192.168.56.30/24"
k8s_gw = "[k8s 마스터 노드 gw 입력] ex)192.168.56.1"

G. install_k8s.sh

(테라폼 숙련도 이슈로 root 권한 자체로 스크립트 실행하는 방법을 몰라 일프로님의 스크립트에서 sudo 명령어를 추가 및 이외 수정 작업 진행)

* kubectl 명령어에서는 앞에 sudo 입력 시 아래 에러 표출됨

[rocky@k8s-master ~]$ sudo kubectl create -f [URL]
The connection to the server localhost:8080 was refused - did you specify the right host or port?

#!/bin/bash

echo '======== [4] Rocky Linux 기본 설정 ========'
echo '======== [4-1] 패키지 업데이트 ========'
# 강의와 동일한 실습 환경을 유지하기 위해 Linux Update 주석 처리
# yum -y update

echo '======== [4-2] 타임존 설정 ========'
sudo timedatectl set-timezone Asia/Seoul

echo '======== [4-3] Disk 확장 / Bug: soft lockup 설정 추가========'
sudo yum install -y cloud-utils-growpart
sudo growpart /dev/sda 4
sudo xfs_growfs /dev/sda4
sudo echo 0 > /proc/sys/kernel/hung_task_timeout_secs
sudo echo "kernel.watchdog_thresh = 20" >> /etc/sysctl.conf

echo '======== [4-4] tc 관련 패키지 설치 ========'
sudo yum install -y yum-utils iproute-tc

echo '======= [4-4] hosts 설정 =========='
sudo cat << EOF >> /etc/hosts
192.168.56.30 k8s-master
EOF

echo '======== [5] 방화벽 해제 ========'
sudo systemctl stop firewalld && systemctl disable firewalld

echo '======== [5] Swap 비활성화 ========'
sudo swapoff -a && sed -i '/ swap / s/^/#/' /etc/fstab

echo '======== [6] 컨테이너 런타임 설치 ========'
sudo touch /etc/modules-load.d/k8s.conf
sudo cat <<EOF |sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

sudo touch /etc/sysctl.d/k8s.conf
sudo cat <<EOF |sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF

sudo sysctl --system

sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
sudo yum install -y containerd.io-1.6.21-3.1.el8
sudo systemctl daemon-reload
sudo systemctl enable --now containerd

sudo bash -c "containerd config default > /etc/containerd/config.toml"
sudo sed -i 's/ SystemdCgroup = false/ SystemdCgroup = true/' /etc/containerd/config.toml
sudo systemctl restart containerd

echo '======== [7] kubeadm 설치 ========'
sudo cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.27/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.27/rpm/repodata/repomd.xml.key
exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni
EOF

sudo setenforce 0
sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
sudo yum install -y kubelet-1.27.2-150500.1.1.x86_64 kubeadm-1.27.2-150500.1.1.x86_64 kubectl-1.27.2-150500.1.1.x86_64 --disableexcludes=kubernetes
sudo systemctl enable --now kubelet

echo '======== [8] kubeadm으로 클러스터 생성 ========'
sudo kubeadm init --pod-network-cidr=20.96.0.0/16 --apiserver-advertise-address 192.168.56.30

sudo mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

kubectl create -f https://raw.githubusercontent.com/k8s-1pro/install/main/ground/k8s-1.27/calico-3.26.4/calico.yaml
kubectl create -f https://raw.githubusercontent.com/k8s-1pro/install/main/ground/k8s-1.27/calico-3.26.4/calico-custom.yaml
kubectl taint nodes k8s-master node-role.kubernetes.io/control-plane-

echo '======== [9] 쿠버네티스 편의기능 설치 ========'
sudo echo "source <(kubectl completion bash)" >> ~/.bashrc
sudo echo 'alias k=kubectl' >>~/.bashrc
sudo echo 'complete -o default -F __start_kubectl k' >>~/.bashrc

kubectl create -f https://raw.githubusercontent.com/k8s-1pro/install/main/ground/k8s-1.27/dashboard-2.7.0/dashboard.yaml
kubectl create -f https://raw.githubusercontent.com/k8s-1pro/install/main/ground/k8s-1.27/metrics-server-0.6.3/metrics-server.yaml

4. Terraform으로 배포 진행

A. vscode를 연 뒤 테라폼 코드를 저장한 폴더를 열고 Open in integrated Terminal 버튼을 클릭합니다.

B. 아래 명령어를 입력하여 테라폼으로 배포를 시작합니다.

> terraform init
Initializing the backend...
Initializing provider plugins...
- Reusing previous version of telmate/proxmox from the dependency lock file
- Using previously-installed telmate/proxmox v3.0.1-rc4

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

> terraform plan
각종 정보 확인..

> terraform apply

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: -> yes 입력 후 진행

C. 완료되었는지 확인합니다. 정상적일 경우 아래와 같이 메세지가 표기됩니다.

D. 쿠버네티스 대시보드로 접속하여 잘 설치되었는지 확인합니다. ex) https://192.168.56.30:30000

(테라폼 완료 후에도 약간의 시간 소요되니 대기 필요)