NAT 뒤의 FortiGate: local-gw, localid, 공인 IP

NAT 뒤의 FortiGate는 WAN 인터페이스에서 10.0.0.2 주소를 가질 수 있지만 인터넷에는 198.51.100.40 로 보이며, 두 숫자 모두 실제입니다. 장치가 바인딩하는 주소와 IKE 인증 중에 보내는 ID는 별개의 선택이며, 별개의 필드에서, 별개의 대상에 맞춰 결정됩니다. NAT는 지나가는 길에 바깥 주소를 다시 쓰지만, 인증된 ID를 원격 피어가 기대하는 값으로 다시 쓰지는 않습니다. 이 형태에서 대부분의 1단계 실패는 올바른 값을 잘못된 필드에 넣는 데서 발생합니다.

세 가지 값, 세 명의 소유자

먼저 세 값과 각각의 소유자를 정하십시오.local-gw 은 FortiGate가 외부 인터페이스에서 IKE 소스로 사용하는 주소이며, 장치가 실제로 보유한 주소여야 합니다. 공인 엔드포인트는 NAT 장치의 주소이고, 변환을 수행하는 쪽이 소유합니다. IKE ID는 피어가 자신의 구성과 대조하는 문자열이며, IP 주소일 필요는 전혀 없습니다.

필드 이름이 비슷해 대체하고 싶어지는데, 그것이 함정입니다.localid 과 localid-type 은 식별을 설명하고,local-gw 은 로컬 바인딩을 설명합니다.

예를 들어 차이를 구체화합니다. FortiGate에서 config vpn ipsec phase1-interface 를 열고, 다음으로 set interface "wan1" 와 set local-gw 10.0.0.2 를 설정합니다. 장치가 보유한 주소이며, 이것이 IKE 소켓의 바인딩을 성공시킵니다.local-gw 을 0.0.0.0 로 두면 인터페이스 주소가 사용되며, 보통 같은 값이지만 덜 명시적입니다.local-gw 을 198.51.100.40 로 설정하지 마십시오. 장치가 그 주소를 보유하지 않으므로 소켓이 바인딩되지 않습니다. 두 값을 종이 위에서 같게 보이게 하는 것은 구성이 아닙니다.

1단계: 피어가 받아들일 ID 선택

이제 ID인데, 이는 다른 결정입니다.set localid 은 피어가 비교할 값을 받고,set localid-type 는 FortiGate에 해석 방법을 알려줍니다. 주소, FQDN, 사용자 FQDN 또는 키 ID입니다.auto 의 경우 장치는 보통 나가는 인터페이스 주소에서 이를 도출하며, 이는 NAT 장치가 곧 바꿀 값과 정확히 같습니다.

이 도출 때문에 이 토폴로지에서 명시적 ID가 중요합니다. 피어가 주소 ID를 기대하면 localid-type address 와 localid 를 피어가 볼 공인 주소로 설정하고, 피어가 그 값을 라우팅 대상이 아니라 ID로 받아들이는지 확인하십시오. 피어가 FQDN을 기대하면 localid-type fqdn 와 구성된 이름을 사용하십시오. 실제로 무엇이 전송되었는지는 diagnose vpn ike gateway list 로 확인하십시오. 이는 입력하려던 값이 아니라 게이트웨이 상태와 사용 중인 식별자를 보여줍니다. ID 유형 옵션이 임의의 비로컬 주소를 받아들인다고 가정하지 말고, 먼저 릴리스의 문서화된 의미를 확인하십시오.

2단계: UDP 500과 4500을 장치로 전달

세 번째 값은 NAT 장치에 속하며, 사람들이 확인하기를 잊는 값입니다. 공인 엔드포인트는 UDP 500과 UDP 4500을 FortiGate로 전달해야 합니다. NAT-T 감지와 뒤따르는 캡슐화 ESP가 모두 이 포트들의 도착에 의존합니다.이 설계가 전제하는 것은 일대일 매핑입니다.하나의 공인 주소를 여러 피어가 포트 단위로 공유하는 것은 다른 제약을 가진 다른 토폴로지입니다.

전달은 기대가 아니라 캡처로 확인하십시오.diagnose sniffer packet any "udp port 500 or udp port 4500" 4 은 패킷이 도착하는지, 응답이 나가는지 보여줍니다.

Google Cloud VPN은 NAT 뒤의 피어에 대해 NAT-T를 사용한 일대일 NAT를 지원 구성으로 문서화하며, 원격 끝이 Cloud VPN 게이트웨이라면 이 제약에 맞춰 설계해야 합니다. 일대다 또는 포트 단위 공유는 같은 지원 구성이 아니며, 로컬 ID 조정으로는 바뀌지 않습니다. 원격 쪽이 다른 장비라면 그 장비의 문서가 어떤 값을 ID로 받아들이고 변환된 피어 주소를 허용하는지 정의합니다. 로컬 필드를 바꾸기 전에 그것을 읽으십시오. 로컬 쪽은 원격 쪽이 구현하지 않은 규칙을 협상할 수 없습니다.

3단계: 1단계가 해결하지 못하는 것 확인

NAT 트래버설은 터널을 올리고, ID 합의는 피어의 수락 여부를 정하며, 내부 프리픽스 라우팅은 실제로 무엇이 통과하는지를 정합니다. 올바른 로컬 ID는 빠진 정적 경로나 빠진 트래픽 선택자를 제공할 수 없습니다.

따라서 계층별로 확인하십시오.get vpn ipsec tunnel details 은 터널이 올라왔는지, 어떤 선택자가 협상되었는지 보여줍니다. 구성된 원격 서브넷과 협상된 선택자의 불일치는 2단계 옷을 입은 라우팅 문제입니다.execute vpn ike gateway clear 은 재협상을 강제하므로 마지막 변경 전에 수립된 세션이 아니라 현재 구성을 시험합니다. 그런 다음 원격 프리픽스의 호스트로 트래픽을 보내 카운터가 움직이는지 확인하십시오. 올라와 있지만 아무것도 통과시키지 않는 터널은 확인하기 전까지 정상 터널과 똑같아 보입니다.

세 값을 노트의 한곳에 모아 두십시오. 장치가 보유한 로컬 주소, NAT 장치가 제시하는 공인 엔드포인트, 피어가 기대하는 ID 문자열입니다. 이들은 서로 다른 이유로, 서로 다른 시점에 바뀝니다.

NAT 장치 재번호는 FortiGate의 local-gw 를 건드릴 이유가 아니며, ID 변경은 무엇인가를 재번호할 이유가 아닙니다. 둘을 섞는 것이 무관한 유지보수 창에서 정상 터널을 다시 만드는 방식입니다.Cloud VPN NAT 지침 이 해당 측의 지원 토폴로지에 대한 참조입니다.

결정적인 시험은 지루하고 빠릅니다. 외부 인터페이스에서 캡처하고, 피어에서 UDP 500과 4500이 도착하는지 확인하고, IKE 교환의 ID가 피어가 기대하도록 구성된 값과 일치하는지 확인한 다음, 협상된 선택자가 관심 있는 서브넷을 포함하는지 확인하십시오. 첫 번째 확인이 실패하면 NAT 장치가 의심 대상입니다. 두 번째가 실패하면 ID 필드입니다. 세 번째가 실패하면 NAT도 ID도 문제가 아니었습니다.