Puncte:0

Pe AWS, cum poate ENI-ul proxy-ului meu squid să devină o gaură neagră în tabelul meu de rute dacă instanța EC2 încă există?

drapel zw

introduceți descrierea imaginii aici

Am căutat pe Google ca un nebun și nu am găsit un răspuns. Avem trei AZ/subrețele de când suntem în Ohio. Dar această diagramă este suficient de apropiată pentru a explica problema.

Am configurat proxy squid pentru a filtra traficul de ieșire de la unul dintre serviciile noastre.

  1. Pentru fiecare AZ, serverele de aplicații sunt într-o subrețea privată.
  2. Apoi există un proxy în fiecare public subrețea pentru acel AZ.
  3. Tabelul de rute pentru subrețeaua privată indică 0.0.0.0 către ENI-ul proxy-ului în subrețeaua publică corespunzătoare.

De-a lungul timpului, traficul de ieșire din fiecare subrețea a murit. Ne-a luat puțin să ne dăm seama ce nu mergea bine, așa că, pe măsură ce fiecare subrețea a murit, am eliminat cazurile din acea subrețea din ALB pentru serviciu și am pornit cu un serviciu defect în timp ce ne-am cercetat. Ieri a treia subrețea a murit și am decis să „rutăm” proxy-urile direct către gateway-ul NAT pentru fiecare subrețea. Când am ajuns la tabelul de rute, am observat că ENI-ul fiecărui proxy era listat ca o gaură neagră.

Am inspectat

  1. Jurnalele instanțelor proxy
  2. timpii de alocare ENI, și
  3. Jurnalele Cloudtrail

...căutând orice indicație cu privire la motivul pentru care ENI-urile deveniseră invalide, rupând rutele noastre implicite. Nimic util deloc.

  1. Instanțele sunt în curs de peste trei săptămâni
  2. Timpul de alocare ENI se potrivește cu ora de creare a instanței
  3. Jurnalele de pornire nu arată nicio repornire
  4. Cloudtrail nu afișează nicio modificare la ENI/instanțele.

Suntem nedumeriți. Cum poate tabelul nostru de rute să conțină „deodată” o rută către un ENI care nu există?

drapel cn
Dacă proxy-ul se află în aceeași subrețea în care ruta pentru 0/0 rută către proxy, nu este aceasta o rută circulară? Nu ați dori proxy-ul într-o subrețea și serviciul în alta?
drapel zw
@shearn89 mulțumesc pentru răspuns. Trebuie să-mi actualizez descrierea. Serverele de aplicații sunt într-o subrețea privată, fără acces la internet. Proxy-urile sunt într-o subrețea publică cu un gateway NAT. Ruta de subrețea privată are 0.0.0.0 > ENI de proxy în subrețeaua publică corespunzătoare (aceeași AZ). Rută de subrețea publică, 0.0.0.0 > gateway nat. Problema aici este că, fără nicio explicație, subrețeaua privată RTB a arătat brusc ruta 0.0.0.0 ca o gaură neagră.
Tim avatar
drapel gp
Tim
@Taylor dacă doriți să vă actualizați întrebarea, vă rugăm să o editați, mai degrabă decât să comentați. Probabil ar trebui să desenați o diagramă pentru a ajuta oamenii să vă înțeleagă configurația/scenariul și, în mod ideal, să vă spargeți peretele de text în paragrafe pentru a fi lizibil.
Tim avatar
drapel gp
Tim
Ați putea lua în considerare utilizarea AWS Network Firewall în loc de proxy squid. Probabil că este mult mai scump, dar este și probabil mult mai fiabil. https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/ Mă întreb dacă ENI-urile dvs. s-au transformat în rute de găuri negre, deoarece instanța respingea traficul sau ceva de genul
drapel cn
Subrețeaua publică nu poate avea NAT GW în ea și, de asemenea, are o rută implicită care indică acel GW, cum ar fi unde vorbește NAT GW? Subrețeaua publică are nevoie de o rută implicită către un Internet GW, iar apoi puteți direcționa separat proxy-urile către NAT GW printr-un anumit tabel.
drapel zw
@Tim după sugestiile dvs., puțin mai puțin un perete de text și o diagramă împrumutată care este suficient de aproape pentru a ilustra ideea.
Tim avatar
drapel gp
Tim
Vă sugerez să obțineți asistență AWS timp de o lună și să discutați cu ei. Cu permisiunea dvs., asistența AWS poate căuta direct în contul dvs. pentru a vă ajuta să rezolvați această problemă oarecum neobișnuită. Bănuiesc că răspunsul va fi în jurnalele CloudTrail, dar poate fi dificil să găsești ceva în CloudTrail.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.