Рассматривается использование NLB для балансировки нагрузки двух прозрачных устройств L3, оба из которых прослушивают порт 8181. Но трафик, попадающий на эти устройства, имеет произвольные IP-адреса назначения. Когда я создал NLB, в eni по умолчанию отключена проверка IP-адресов источника / назначения. Я предполагаю, что NLB не будет заботиться о том, имеет ли входящий трафик другой IP-адрес назначения, отличный от собственного. Но это не сработало, поэтому я не знаю, моя ли это конфигурация, или NLB ее не поддерживает.
В качестве дополнительного примечания, вы можете направить произвольный трафик на NLB, используя маршрут с целью, являющейся NLB eni.
«вы можете направить произвольный трафик на NLB, используя маршрут, при этом целью будет NLB eni».
Или, по крайней мере, вы можете настроить его так, чтобы этот появляется как бы то ни было ... но я подозреваю, что это причуда правил, которые позволяют вам делать это для шлюзов NAT, экземпляров NAT и хостов EC2 VPN с отключенной проверкой src / dest.
Мне сложно представить, что NLB действительно может это сделать, поскольку логическое «устройство», подключенное к этому ENI, не ожидает того, что технически является неверно маршрутизируемым трафиком. Трафик, скорее всего, упал.
Отключение проверки источника / назначения, вероятно, является артефактом того, как NLB возвращает трафик обратно в сеть. Запустите wirehark - это странно.
Входящий трафик в экземпляре имеет MAC-адрес источника NLB ENI, конечно же MAC-адрес назначения экземпляра ... но в ответах есть MAC-адрес назначения маршрутизатора подсети по умолчанию.
NLB фактически перехватывает маршруты в сети VPC для каждого потока, который он устанавливает, позволяя экземпляру хоста отправлять ответный трафик обратно «реальному» источнику соединения, используя шлюз по умолчанию, который, конечно, фактически не направляет ответ обратно в источник, использующий таблицу маршрутизации, но вместо этого отправляет его обратно в NLB (в любом случае логически - вы не можете обнюхать эту часть), чтобы IP-адрес экземпляра мог быть отключен NAT, а ENI IP-NAT-снова включен, затем как трафик покидает VPC, интернет-шлюз переводит частный IP-адрес ENi обратно в общедоступный ... во всяком случае, концептуально, потому что все это дым и зеркала в сети VPC. Ранний тест показал, что даже не имеет значения, является ли целевой маршрут подсети бессмысленным, если он что-то в качестве маршрута по умолчанию NLB интегрирован в сетевую структуру VPC таким образом, что трафик по-прежнему возвращается к источнику, как ожидалось.
На определенном уровне NLB представляет собой динамический двусторонний механизм NAT, глубоко встроенный в сеть, транслирующий трафик с адреса ENI на адрес экземпляра и обратно. В этом свете было бы разумно, чтобы трафик, адресованный чему-либо, кроме адреса ENI, был бы отброшен, потому что попытка удвоения трафика NAT, привязанного к случайным адресам источника, кажется, выходит за рамки проекта, если вообще возможна.
Но для получения более авторитетного ответа я подозреваю, что вам нужно обратиться в службу поддержки AWS.