라우팅이나 DNS와 관련된 것으로 보이는 이상한 문제가 발생했습니다.
우리는 Unifi 장비(UDMP)를 사용하는 "허브 앤 스포크" 토폴로지를 가지고 있습니다. 각 사이트는 IPSEC 터널을 통해 VyOS를 실행하는 AWS EC2 인스턴스에 연결하여 사이트와 AWS의 다른 인프라 간의 핵심 라우팅을 처리합니다.
과거에는 일부 온프레미스 서버로 구성된 하이브리드 토폴로지를 더 많이 보유했을 때 각 사이트에는 기존 VoIP 서버에 필요한 본사에 연결되는 또 다른 IPSEC 터널이 있었고 온프레미스 DNS 서버도 몇 개 있었습니다.
이후 모든 인프라를 AWS로 이전했으며 본사로 연결되는 두 번째 IPSEC 터널은 더 이상 필요하지 않습니다. 나는 본사로 연결되는 대부분의 사이트 터널을 제거했고 다른 사이트에서는 모든 것이 잘 작동합니다. 터널을 무너뜨릴 때마다 문제를 일으키는 사이트(site3)가 하나 남아 있습니다.
문제: "사이트 3"과 본사 사이의 IPSEC 터널을 내려갈 때마다 사람들이 "인터넷이 없다"고 불평하기 전까지 모든 것이 약 10분 동안 작동합니다. 나는 그들이 여전히 기존 온프레미스 DNS 서버를 사용하고 있다고 판단하여 Google DNS를 백업으로 사용하여 기본 DNS 서버를 AWS의 DNS 서버로 전환했습니다. 좋습니다. 문제 없습니다. 모든 것이 작동합니다. 다시 터널을 내려가면 전화가 오기 시작합니다. 이번에는 사용자가 매핑된 드라이브(AWS의 파일 서버)를 잃어버렸다고 말합니다.
이상한 점은 본사에 대한 IPSEC 터널이 작동 중일 때 모든 것이 잘 작동한다는 것입니다(사이트 3의 aws 연결). 내가 그것을 내리면 약 10분 정도 작동하다가 작동을 멈춥니다. 그들의 사이트가 터널을 통해 본사로, 그리고 AWS로 라우팅되고 있다고 생각하겠지만, 그렇지 않습니다. site3에 있는 클라이언트 시스템의 추적 경로는 EC2 인스턴스에 연결하기 위한 3개의 홉(WAN 외부, VyOS IP, 서버 IP)을 보여줍니다. site3의 클라이언트 시스템에 있는 라우팅 테이블을 보면 AWS 네트워크에 대한 항목이 표시되지 않으므로 트래픽이 해당 UDMP 게이트웨이인 0.0.0.0으로 전송됩니다. site3 UDMP의 라우팅 테이블을 보면 aws VPC 네트워크에 대한 항목 1개(172.30.0.0/16)가 표시되며 다음 홉은 VyOS 라우터입니다.
한 가지 흥미로운 세부 사항은 모든 것이 ICMP/응답에 대한 ping을 허용하도록 설정되어 있어도 UDMP나 vyos 라우터 모두 서로 또는 ec2 인스턴스를 ping할 수 없다는 것입니다. 그러나 site3 네트워크의 클라이언트는 모든 것을 ping할 수 있습니다.
EC2 인스턴스에 대한 보안 규칙을 확인했는데 필요한 모든 네트워크와 WAN IP가 포함되어 있습니다.
site3 udmp가 고정 WAN IP로 구성되어 있지만 "라우터"에 대한 구성 설정과 추가 IP 주소도 설정되어 있다는 사실을 알았을 때 아이디어가 새롭습니다. 세부정보는 다음과 같습니다.
WAN IP=108.x.69.250
subnet mask: 255.255.255.248
Router: 108.x.69.249
Additional IP addresses: 108.x.69.251/32, 108.x.69.252/32, 108.x.69.253/32, 108.x.69.254/32, 108.x.69.255/32
AWS/EC2의 보안 규칙을 살펴보면 108.x.69.250/32는 허용되지만 서브넷의 다른 IP(다음 홉 ISP 라우터 또는 추가 IPS)는 포함되지 않는 것으로 나타났습니다. AWS 보안 허용 항목을 108.x.69.248/29로 변경했지만 이것은 만세입니다. 나는 이것이 해결될 것이라고 확신하지 않습니다.
누구든지 어떤 생각이나 아이디어가 있습니까? 몇 시간 후에 다시 테스트할 수는 없지만 상황에 대해 다른 사람의 의견을 얻을 수 있을 것이라고 생각했습니다. 정적 WAN뿐만 아니라 라우터 및 추가 IP에 대해 구성된 추가 필드를 사용하여 UDMP를 작업한 경험이 있는 사람이 있습니까?
여러분의 독서 즐거움을 위해 아름다운 토폴로지 다이어그램을 포함시켰습니다!
답변1
WAN/29 네트워크의 추가 IP를 AWS 액세스 그룹에 추가함으로써 이 문제가 해결되었다고 생각합니다.