잘못된 Azure 개체에 접두사를 추가하면 Connected를 보고하면서 아무것도 전달하지 않는 연결이 만들어지며, 이것이 이 스택에서 가장 비싼 실수 유형입니다. 세 가지 리소스가 관련되고 그중 하나만 원격 주소 공간을 소유합니다. 가상 네트워크 게이트웨이, 원격 측을 설명하는 로컬 네트워크 게이트웨이, 그리고 둘을 잇는 연결입니다. 접두사는 로컬 네트워크 게이트웨이에 속하고, 변경 사항을 적용하려면 연결을 다시 만들어야 하며, 게이트웨이 자체는 보통 그대로 둡니다. 순서는 협상할 수 없고, 포털은 그 일부만 보여 줍니다.

세 개체 중 하나가 접두사를 보관합니다

가상 네트워크의 주소 공간은 다른 질문에 답합니다. Azure 내부에 무엇이 있는가입니다. 거기에 원격 접두사를 추가해도 트래픽이 그쪽으로 라우팅되지 않고, 플랫폼이 자신의 것이라고 여기는 공간이 넓어질 뿐이며, 실제 원격 범위와 충돌할 수 있습니다. 원격 접두사를 보관하는 개체는 로컬 네트워크 게이트웨이이고, 연결은 두 게이트웨이와 미리 공유된 키를 참조합니다.

기억해야 할 세 번째 유보 사항도 있습니다. GatewaySubnet 는 관리되는 게이트웨이 인스턴스를 호스팅하며, 정확히 그 이름을 가져야 하고, Basic이 아닌 SKU에서는 최소 /27이어야 합니다.

그 서브넷에는 다른 것이 속하지 않으며, 접두사 변경이 그것을 건드릴 이유도 없습니다. 로컬 네트워크 게이트웨이에 없는 접두사는 연결 상태가 무엇이라 하든 도달할 수 없습니다. 게이트웨이는 터널을 협상할 때 통보받은 접두사만 제공하기 때문입니다. 그래서 증상이 비대칭입니다. 터널은 올라가 있고 보안 연결은 정상인데 한 서브넷만 트래픽 선택기에 나타나지 않습니다. 이웃은 동작하는데 원격 범위 하나만 빠져 있다면 터널을 보는 것을 멈추고 로컬 네트워크 게이트웨이를 읽으십시오.

왜 연결이 제거되는가

연결 개체는 협상된 구성을 수명 동안 고정합니다. 그래서 문서화된 절차는 먼저 연결을 제거하고, 로컬 네트워크 게이트웨이를 업데이트한 다음, 같은 공유 키로 연결을 다시 만듭니다. 접두사만 바뀌는 경우 게이트웨이 인스턴스는 다시 만들어지지 않으므로, 중단은 게이트웨이 재배포가 아니라 연결 해체로 제한됩니다.

그 삭제가 곧 중단입니다. 따라서 빠른 편집이 아니라 시작과 예상 종료가 있는 계획된 변경으로 다루십시오. PowerShell에서는 순서가 짧습니다. Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, 그다음 Set-AzLocalNetworkGateway 새 -AddressPrefix 배열과 함께, 그다음 New-AzVirtualNetworkGatewayConnection 같은 -SharedKey 과 같은 게이트웨이로 실행합니다. 키를 재사용하는 것이 중요합니다. 원격 측은 재구성되지 않으며 새 키는 원격 장치 소유자와의 조정을 뜻합니다. 그 장치를 다른 팀이 운영한다면 무엇이든 제거하기 전에 그들과 시간 창을 합의하십시오.

게이트웨이 자체를 다시 만들어야 하는 경우

이 문제를 둘러싼 두 번째 답은 게이트웨이를 다시 만들고 키를 다시 교환해야 한다고 말합니다. 그것은 다른 작업 집합에 맞는 말입니다. 게이트웨이 유형이나 SKU 변경, 지점 대 사이트와 사이트 대 사이트 사이의 전환, 또는 자체 구성이 잘못된 게이트웨이의 수리입니다. 그런 변경은 실제로 게이트웨이 리소스를 바꾸므로 재구성이 정말 필요합니다.

지점 대 사이트용으로 만든 게이트웨이에 사이트 대 사이트 연결을 그냥 줄 수는 없습니다. 지점 대 사이트 구성을 제거하고 게이트웨이를 다시 만들어야 하며, 그 결과 새 공유 키와 새 클라이언트 패키지도 생깁니다.

지점 대 사이트 패키지는 만료되므로 별도 설명이 필요합니다. 포털이 만드는 파일은 수명이 짧으므로, 실무적으로는 한 번 내려받아 클라이언트 인증서와 함께 배포하는 것이 좋고, 사용자가 클릭할 때쯤이면 죽어 있을 포털 링크를 보내서는 안 됩니다. 접두사 문제에는 이 중 어느 것도 해당하지 않습니다. 두 절차를 분리해 두는 것이 전체 규율입니다. 접두사는 연결 수준의 변경이고, 게이트웨이 속성은 게이트웨이 수준의 변경입니다.

포털 배지가 아니라 상태를 읽으십시오

포털의 배지가 아니라 리소스에서 상태를 읽으십시오. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 는 ConnectionStatus 를 인바운드 및 아웃바운드 바이트 카운터와 함께 반환하며, 연결되어 있지만 아무것도 나르지 않는 터널과 한 번도 설정되지 않은 터널을 구분하는 것은 바로 이 카운터입니다.

전송 중간에 증가를 멈추는 카운터는 인증이 아니라 경로를 가리킵니다. 전혀 움직이지 않는 카운터는 접두사 집합이나 공유 키를 가리킵니다.

타이머는 VPN 탓으로 잘못 돌려지는 연결 끊김의 한 부류를 설명합니다. Azure의 부하 분산기는 구성된 제한 시간 후 유휴 흐름을 닫으며, 이 노트를 쓸 당시 기본값은 사 분이고 위로 구성할 수 있습니다. 그래서 keepalive가 없는 VM의 OpenVPN 서버는 다른 모든 것이 정상으로 보여도 몇 분마다 끊길 수 있습니다. 플랫폼이 주기적으로 재시작하는 게이트웨이도 VNet에서 Web App으로 가는 연결을 끊을 수 있습니다, 그리고 그 실패는 클라이언트 구성이 아니라 플랫폼 쪽에 있습니다. 단서는 끊김이 고정된 간격을 따르는지, 당신이 한 변경을 따르는지입니다.

세 개체와 그 값을 하나의 기록에 유지하십시오. 가상 네트워크의 주소 공간, 로컬 네트워크 게이트웨이의 접두사 목록, 연결의 공유 키 참조입니다. 사이트 대 사이트 PowerShell 문서 는 로컬 네트워크 게이트웨이 명령과 그것이 속한 순서를 문서화합니다. 접두사 변경을 기억과 비교하는 것이 동작하는 터널을 두 번 다시 만드는 방법입니다.

그다음 변경한 순서대로 확인하십시오. 로컬 네트워크 게이트웨이가 새 접두사 목록을 보여 주고, 연결이 다시 Connected이며, 새 범위의 호스트로 트래픽을 보내면 카운터가 움직입니다. 처음 두 단계가 통과하는데 세 번째가 실패하면 원격 측이 새 트래픽 선택기를 받아들이지 않은 것이고 원격 장치에 맞는 2단계 항목이 필요합니다. 그것은 터널 반대편과의 대화이지 Azure의 또 다른 변경이 아닙니다.

관련 글