UrlFetchApp.fetch in Google Spreadsheets kann den AWS-Back-End-Webdienst nicht verbinden

Wir haben eine EC2-Instanz für AWS, auf die wir unsere Backend-Services implementiert haben. Zunächst haben wir Google Spreadsheets (mit Google Apps Script gescriptet) verwendet, um unser Backend über einen Webservice auf unserem Server zu präsentieren. Wir haben einen spezifischen Port, von dem https (verwendet ein selbstsigniertes Zertifikat) verwendet wird, um den Webservice während des Fluges verschlüsselt zu bedienen. Wir hatten Sicherheitsgruppen (im Grunde eine Firewall-Eintragsgruppe) eingerichtet, die folgende CIDR-Bereiche für diesen bestimmten Eingangs-Port unseres Webservice enthalten:

wie in Ссылка

Diese Einrichtung hat bis vor fünf Tagen funktioniert. Dann passierte etwas Seltsames. Wenn wir das Skript hinter der Tabelle aus dem Skript-Editor-Code ausführen funktioniert einwandfrei und Anfragen an unseren Webservice retournieren erfolgreich. Aber wenn derselbe Code über einen Menüeintrag aufgerufen wurde, hat er nichts unternommen. Nach langer frustrierender Untersuchung stellten wir fest, dass die Anfrage nicht einmal unseren Server erreichte (es gab zahlreiche andere skurrile Symptome, wie zum Beispiel nur der letzte Log-Befehl auf "Execution Transcript" zu sehen war, obwohl es viele andere hätte geben müssen). Dann haben wir versucht, die Sicherheitsgruppe durch eine Regel zu ersetzen, die von jeder IP-Adresse annimmt, aber an einem bestimmten Port hat alles wieder gut funktioniert.

Hier ist ein Link zu einem scheinbar relevanten Problem auf der Seite google-apps-script-issues: Ссылка

Wir haben tcpdump tcp port <port> -i eth0 -vv ausgeführt und festgestellt, dass beim Ausführen des Codes von 'Script Editor' eine Anfrage von 66.102.7.156 (und von ähnlichen ips, die in 66.102.0.0/20 sind) angefordert wurde, wenn Code von Menüelement in aufgerufen wird Tabelle die Anfrage wurde von 72.14.199.55 (und von ähnlichen ips, die in 72.14.192.0/18 sind) gemacht. Dieser scheint der problematische IP-Bereich zu sein.

Meine Frage ist, warum ist es so, dass, wenn Anfragequellen korrekt in Firewall-Regeln enthalten sind, ein Block von ips nicht funktioniert und zu arbeiten beginnt, wenn die ip-Beschränkung für den Port aufgehoben wird (source ip 0.0.0.0/0 )? Ist es ein Fehler von Sicherheitsgruppen in AWS? Oder machen wir etwas falsch? Auch wenn unser Ansatz in keiner Weise angemessen ist, würden alternative Lösungen oder Vorschläge sehr geschätzt.