Зачем мне нужен внешний адрес для внутреннего соединения между экземплярами GCE?

У меня VPC (10.11.0.0/20) с 3 виртуальными машинами. VM2 и VM3 являются тот же самый за исключением того, что у VM2 есть внешний IP-адрес (эфемерный), а у VM3 нет. Оба они запускают образ Docker с веб-сервером, открывающим порт 80.

У меня есть правило брандмауэра "разрешить все внутренние":

NAME            NETWORK   DIRECTION  PRIORITY  SRC_RANGES    ALLOW
dev-internal    dev       INGRESS    1000      10.11.0.0/20  icmp,tcp:0-65535,udp:0-65535

Я могу выполнить оболочку в VM1, и из нее я могу пинговать как VM2, так и VM3.

Когда я nmap VM2, я вижу, что 998 портов закрыты и оба ssh и http открытый - как положено.

Когда я nmap ВМ3, у меня 999 портов фильтрованный - подразумевается, что брандмауэр их маскирует? - и просто ssh порт открыт.

Я могу curl из VM2, но время ожидания VM3 истекло.

Я ожидаю, что смогу общаться по внутренней сети без назначения внешних IP-адресов. Что я делаю не так?

(Единственная небольшая сложность заключается в том, что VPC определен в одном проекте, а VPC-Shared во втором проекте. Правила и маршруты брандмауэра определены в главном проекте VPC. Виртуальные машины находятся во втором проекте, но в общем VPC.)

Изменить: результат netstat -antp из ВМ2:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      1207/nginx: master  
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      311/sshd            
tcp        0      0 0.0.0.0:5355            0.0.0.0:*               LISTEN      299/systemd-resolve 
tcp        0      0 10.11.0.6:46458         169.254.169.254:80      ESTABLISHED 381/python2.7       
tcp        0    272 10.11.0.6:22            173.194.90.33:64360     ESTABLISHED 43364/sshd: jamie_h 
tcp        0      0 10.11.0.6:53880         169.254.169.254:80      ESTABLISHED 401/device_policy_m 
tcp        0      0 10.11.0.6:46454         169.254.169.254:80      CLOSE_WAIT  385/python2.7       
tcp        0      0 10.11.0.6:46460         169.254.169.254:80      ESTABLISHED 385/python2.7       
tcp        0      0 10.11.0.6:46456         169.254.169.254:80      ESTABLISHED 384/python2.7       
tcp6       0      0 :::5355                 :::*                    LISTEN      299/systemd-resolve 

VM3 - это идентичный - обе контейнерные ОС, на обеих запущен один и тот же образ Docker - и поскольку у меня нет внешнего IP-адреса, я не могу выполнить оболочку (без сложного танца ...).

РЕДАКТИРОВАТЬ: шаги по воспроизведению:

1. Создать VPC
2. Создайте правила брандмауэра для внешнего SSH и HTTP-доступа к подсети (я использую ssh и http теги соответственно)
3. Создайте правило брандмауэра для внутреннего трафика в VPC (источник = подсеть, цель = все экземпляры в подсети)
4. Создать виртуальную машину под названием source на VPC с использованием Debian с ssh сетевой тег и внешний IP (для поддержки SSH-соединения)
5. Создать виртуальную машину под названием target1 на VPC с использованием COS и nginxdemos/hello образ докера ("привет, мир" открыт через порт 80) с http сетевой тег и внешний IP
6. Создать виртуальную машину под названием target2 на VPC с использованием COS и nginxdemos/hello образ докера с http сетевой тег и нет внешний IP
7. SSH в source ВМ и пинг оба target1 и target2 - они отвечают
8. curl target1 и он отвечает с приветственной мировой страницей
9. curl target2 и время истекает
10. nmap -Pn target1 показывает ssh + http открыто, все остальные закрыты
11. nmap -Pn target2 показывает ssh открытым, а все остальные отфильтрованы