Wir haben ein merkwürdiges Problem, das scheinbar mit dem Routing oder DNS zusammenhängt.
Wir haben eine „Hub-and-Spoke“-Topologie mit Unifi-Geräten (UDMPs). Jeder Standort verbindet sich über einen IPSEC-Tunnel mit einer AWS EC2-Instanz, auf der VyOS läuft, um das Kernrouting zwischen Standorten und anderer Infrastruktur in AWS abzuwickeln.
Früher, als wir eher eine hybride Topologie mit einigen lokalen Servern hatten, verfügte jeder Standort über einen weiteren IPSEC-Tunnel zur Hauptniederlassung, der für den alten VoIP-Server erforderlich war, und wir hatten einige lokale DNS-Server.
Wir haben seitdem die gesamte Infrastruktur in AWS verschoben, und diese zweiten IPSEC-Tunnel zum Hauptbüro werden nicht mehr benötigt. Ich habe die meisten Tunnel der Site, die mit dem Hauptbüro verbunden sind, abgeschaltet, und für diese anderen Sites funktioniert alles einwandfrei. Ich habe noch eine Site (Site3), die mir Probleme bereitet, wenn ich ihren Tunnel abschalte.
Das Problem: Immer wenn ich den IPSEC-Tunnel zwischen „Site 3“ und dem Hauptbüro abbaue, funktioniert alles vielleicht 10 Minuten lang, bevor die Leute anfangen, sich zu beschweren, dass sie „kein Internet haben“. Ich habe festgestellt, dass sie wahrscheinlich immer noch die alten DNS-Server vor Ort verwenden, also habe ich ihre primären DNS-Server auf die DNS-Server in AWS umgestellt, mit Google DNS als Backup. Gut, kein Problem, alles funktioniert. Ich baue den Tunnel wieder ab und bekomme Anrufe. Diesmal sagen die Benutzer, sie hätten ihre zugeordneten Laufwerke (den Dateiserver in AWS) verloren.
Seltsam ist, dass alles einwandfrei funktioniert (Verbindung von Site 3 zu AWS), wenn deren IPSEC-Tunnel zur Hauptniederlassung aktiv ist. Wenn ich ihn abbaue, funktioniert alles vielleicht 10 Minuten oder so, dann hört es auf. Man könnte meinen, ihre Site würde durch den Tunnel zur Hauptniederlassung und dann hoch zu AWS geroutet, aber das ist nicht der Fall. Ein Traceroute von einem Client-Rechner an Site3 zeigt 3 Hops zur Verbindung mit EC2-Instanzen: aus ihrem WAN, zur VyOS-IP, zur Server-IP. Ein Blick auf die Routing-Tabelle auf dem Client-Rechner an Site3 zeigt keinen Eintrag für das AWS-Netzwerk, daher wird der Datenverkehr an 0.0.0.0, ihr UDMP-Gateway, gesendet. Ein Blick auf die Routing-Tabelle auf dem UDMP von Site3 zeigt 1 Eintrag für das AWS-VPC-Netzwerk, 172.30.0.0/16, wobei der nächste Hop der VyOS-Router ist.
Ein interessantes Detail ist, dass, obwohl alles so eingestellt ist, dass ICMP zugelassen wird/auf Ping geantwortet wird, weder der UDMP- noch der Vyos-Router sich gegenseitig oder EC2-Instanzen anpingen können. Clients im Site3-Netzwerk können jedoch alles anpingen.
Ich habe die Sicherheitsregeln für die EC2-Instanzen überprüft und alle erforderlichen Netzwerke und WAN-IPs sind enthalten.
Mir gehen die Ideen aus, als ich feststelle, dass site3 udmp mit einer statischen WAN-IP konfiguriert ist, aber auch Konfigurationseinstellungen für „Router“ und zusätzliche IP-Adressen hat. Dies sind die Details:
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
Ein Blick in die Sicherheitsregeln für AWS/EC2 zeigte, dass zwar 108.x.69.250/32 zulässig ist, aber keine der anderen IPs im Subnetz eingeschlossen sind (Next-Hop-ISP-Router oder zusätzliche IPS). Ich habe den zulässigen AWS-Sicherheitseintrag auf 108.x.69.248/29 geändert, aber das ist ein verzweifelter Versuch. Ich bin nicht allzu zuversichtlich, dass dies die Lösung sein wird.
Hat jemand irgendwelche Gedanken oder Ideen? Ich kann erst nach Feierabend noch einmal testen, aber ich dachte, ich könnte vielleicht die Meinung von jemand anderem zu der Situation hören. Hat jemand Erfahrung mit der Arbeit mit UDMP mit statischem WAN, aber auch mit diesen zusätzlichen Feldern, die für Router und zusätzliche IPs konfiguriert sind?
Ich habe für Ihr Lesevergnügen ein schönes Diagramm der Topologie beigefügt!
Antwort1
Ich glaube, dass das Hinzufügen der zusätzlichen IPs im WAN /29-Netzwerk zur AWS-Zugriffsgruppe das Problem für mich behoben hat.