Azure P2S VPN의 고정 IP: 클라이언트 주소가 바뀌는 이유

모든 Azure point-to-site 클라이언트는 인증할 때 풀에서 주소를 받고, 그 연결이 유지되는 동안만 보관합니다. 예약 테이블도, 사용자별 매핑도, “이 사람에게 항상 172.16.0.10을 주라”는 뜻의 게이트웨이 설정도 없습니다. 바로 이 하나의 메커니즘이 나중에 사람들이 겪는 두 증상을 설명합니다. 예전에 일치하던 사용자와 더 이상 일치하지 않는 NSG 규칙, 그리고 아무도 의도적으로 추가하지 않은 기계를 조용히 통과시키는 허용 목록입니다. 규칙을 더 영리한 IP 규칙으로 바꿔도 둘 다 고쳐지지 않습니다. 규칙이 지목하는 대상은 당신이 통제하지 않는 일정에 따라 다시 할당되기 때문입니다.

풀은 용량이지 신원이 아닙니다. 동시 터널이 고유한 주소를 받도록 존재하며, 임대가 끝나는 순간 그 주소를 재사용합니다. 이것이 분명해지면 유용한 질문은 “이 클라이언트를 어떻게 고정할까”가 아니라 “게이트웨이가 재사용하지 않을 무엇에 대해 규칙을 쓸 수 있을까”가 됩니다.

클라이언트가 연결할 때 게이트웨이가 실제로 하는 일

게이트웨이는 설정된 클라이언트 주소 풀을 유지하고 그것을 임대 테이블로 취급합니다. 연결 시 다음 빈 주소, 실제로는 사용 가능한 가장 낮은 주소를 가져와 클라이언트가 끊거나 임대가 만료될 때까지 터널 어댑터에 할당합니다. 결정하는 것은 순서이지 신원이 아닙니다. 조용한 기간 뒤에 가장 먼저 다시 연결한 사람이 그 순간 우연히 비어 있는 가장 낮은 주소를 가져갑니다.

풀의 크기가 동작을 감춥니다. 테스터 수보다 하나나 둘 많은 실험실 풀은 결정론적으로 보입니다. 같은 노트북이 매일 아침 같은 순서로 다시 연결하는 경향이 있기 때문입니다. 세 번째 기계를 추가하거나, 풀 크기를 바꾸거나, 점심시간 동안 세션을 연결해 두면 패턴이 깨집니다. 주소는 결코 안정적이지 않았습니다. 안정적이었던 것은 대기열입니다.

point-to-site 구성을 바꾸면 임대 공간도 초기화됩니다. 다른 인증 유형, 크기가 바뀐 풀, 새 풀 범위, 또는 철거 후 다시 만든 게이트웨이는 모두 클라이언트를 예전 주소와 더 이상 대응하지 않는 풀로 되돌립니다. 그 변경의 어느 부분도 NSG를 건드리지 않기 때문에 장애가 저절로 생긴 것처럼 보입니다.

약 일 분이면 확인할 수 있습니다. 연결하고, 클라이언트의 연결 세부 정보에서 터널 주소를 적고, 연결을 끊고, 두 번째 기계를 연결한 뒤, 첫 번째를 다시 연결하십시오. 돌려받는 주소는 두 번째 기계가 무엇을 쥐고 있느냐에 달려 있으며, 어떤 포털 설정도 요청에 따라 이전 주소를 복원하지 않습니다.

클라이언트 IP에 맞춘 NSG는 사실 연결 순서에 대한 규칙입니다

사람들이 가장 먼저 쓰는 규칙은 뻔한 것입니다. 관리 VM의 NIC나 그 서브넷에 대한 인바운드 규칙으로, 원본을 VPN 클라이언트의 내부 주소로 두는 것입니다. 짧고, 쓴 당일 테스트를 통과하며, 풀에 빈 주소가 둘 이상이 되는 순간 실패합니다.

여기서 두 가지 실패 방식이 나오고, 버그처럼 보이는 것은 하나뿐입니다. 정당한 사용자가 거부되는 것은 규칙이 지목한 주소를 지금 다른 누군가가 쥐고 있기 때문이며, 이는 성가신 지원 요청으로 나타납니다. 또는 의도하지 않은 사용자가 통과되는 것은 규칙이 아직 신뢰하는 주소를 물려받았기 때문이며, 누군가 접근을 감사하기 전까지는 아무 일도 일어나지 않은 것처럼 보입니다.

규칙이 임대를 따르므로 실효 정책은 “가장 먼저 연결한 사람이 관리 접근 권한을 얻는다”로 읽힙니다. 이것은 의도의 옷을 입은 연결 순서 설명이며, 어떤 규칙 정리로도 의도의 표현이 되지 않습니다.

클라이언트 임대와 게이트웨이 주소는 서로 다른 객체입니다

혼란의 대부분은 한 단어에서 옵니다. 게이트웨이에는 비교적 안정적인 공용 IP가 있습니다. 클라이언트에는 풀에서 나오는 사설 주소가 있고, 그것은 안정적이지 않습니다. 영역 중복이 아닌 VPN 게이트웨이의 공용 IP는 동적으로 할당되지만 크기 변경, 재설정, 일상 유지 관리를 견딥니다. 게이트웨이 자체가 삭제되고 다시 만들어질 때 바뀝니다. 영역 중복 및 영역 게이트웨이 SKU는 Standard SKU 공용 IP를 사용하며, 그 할당은 정적이어야 합니다.

그 안정성이 온프레미스 피어가 구성에 필요로 하는 것이며, 개별 클라이언트를 식별하는 것에 대해서는 아무 말도 하지 않습니다. 파트너가 어떤 주소를 보게 될지 묻는다면, 답은 site-to-site에서 게이트웨이의 공용 IP이거나 공유 NAT 범위입니다. 노트북의 터널 임대는 결코 아닙니다.

그룹 풀은 규칙을 쓸 만한 범위를 줍니다

Virtual WAN point-to-site는 사용자 그룹을 지원하며, 각 그룹에 자체 클라이언트 주소 풀을 할당할 수 있습니다. 소속은 신원으로 결정되므로 클라이언트가 떨어지는 범위가 예측 가능해집니다. 운영은 한 범위에, 계약자는 다른 범위에, 그리고 그 범위는 방화벽이나 NSG 규칙이 추측 없이 지목할 수 있는 대상입니다.

그 결과 규칙 집합은 검토할 수 있는 형태를 갖습니다.

• 대상별로 풀 하나, 인원수가 아니라 동시 세션 최대치에 맞춰 크기를 정합니다.
• 그룹 소속은 신원으로 처리하며, 누군가 들어올 때마다 규칙을 편집하는 방식이 아닙니다.
• NSG나 Azure Firewall 규칙은 풀 범위에 대해 쓰고, 개별 임대에 대해서는 결코 쓰지 않습니다.
• 결코 범위를 공유해서는 안 되는 대상에게는 별도 허브나 게이트웨이를 둡니다.

풀 전체를 허용 목록에 넣는 것은 정직하지만 거칩니다. 그 범위의 연결된 모든 클라이언트가 같은 접근을 얻습니다. 그것은 검토 중에 발견하기보다 소리 내어 말할 가치가 있는 정책 결정입니다. 여전히 사람별 답이 필요한 것은 패킷 필터가 아니라 역할 할당을 통해 리소스 쪽에 속합니다.

배포를 Virtual WAN으로 옮길 수 없을 때

많은 게이트웨이가 평범한 VPN 게이트웨이로 남아 있고, Virtual WAN으로 옮기는 것은 가벼운 변경이 아닙니다. 실용적인 답은 사용자별 결정을 패킷 필터에서 사용자가 누구인지 이미 아는 무언가로 옮기는 것입니다.

리소스 수준 신원이 가장 저렴한 버전입니다. Storage, SQL, Key Vault는 모두 사용자별 또는 그룹별 역할 할당과 함께 Entra ID 인증을 지원하므로, VPN은 네트워크 도달 가능성만 증명하면 됩니다. 이름 있는 계정을 가진 점프 호스트는 관리 작업에서 같은 역할을 합니다. 호스트가 사람을 기록하고 터널은 패킷만 나르기 때문입니다. 클라이언트를 DNS에 등록하고 숫자 대신 이름을 허용하면 규칙이 한 계층 올라갑니다. 애플리케이션 계층 신원, 즉 인증서 주체, 토큰 클레임, 그룹 소속은 결정을 요구받는 것이 네트워크가 아니라 애플리케이션일 때 작동합니다.

고정 소스 주소를 고집하는 파트너에게는 정의된 피어 접두사를 가진 site-to-site 또는 ExpressRoute가 답입니다. 상대는 피어 접두사를 허용하고, 그쪽에 나타나는 주소는 게이트웨이의 것이며, 누군가 노트북을 재부팅해도 바뀌지 않습니다.

또 다른 허용 목록을 편집하기 전에 풀을 확인하십시오

풀의 두 속성이 사람들이 클라이언트 탓으로 돌리는 동작의 대부분을 만듭니다. 너무 작은 풀은 임대를 빠르게 재사용하므로 주소가 끊임없이 움직이는 것처럼 보이고, 주소 기반 규칙은 설계상 불안정해 보입니다. 온프레미스 범위나 가상 네트워크 주소 공간과 겹치는 풀은 어떤 방화벽 규칙도 고치지 못하는 라우팅 모호성을 만듭니다.

규칙을 건드리기 전에 세 가지를 한 장에 모으십시오. point-to-site 풀, 가상 네트워크 주소 공간, 온프레미스 범위입니다. 이것들은 겹쳐서는 안 되며, 풀에는 동시 접속 클라이언트 모두를 위한 여유와 재연결을 위한 여백이 필요합니다.

그런 다음 이 순서로 고리를 닫으십시오.

• 두 기계에서 두 순서로 모두 연결해 주소를 비교하십시오. 서로 바뀔 수 있다면 주소 기반 규칙은 안전하지 않습니다.
• 게이트웨이가 Virtual WAN인지 확인하십시오. 그렇다면 주소별 규칙 대신 그룹 풀을 사용하십시오.
• 규칙이 잘못된 사람과 일치할 때 무슨 일이 생기는지 물으십시오. 답이 접근 사고라면 통제를 신원으로 옮기십시오.
• 어느 범위가 어느 그룹의 것인지 NSG 정의와 같은 저장소에 기록하십시오.
• 풀, 인증, 게이트웨이를 바꾼 뒤에는 다시 테스트하십시오. 그 변경은 알리지 않고 매핑을 다시 쓰기 때문입니다.