IP átirányítás

Van olyan ICMP/IP csomag amivel azt lehet üzenni egy hostnak, hogy a célját egy másik IP-n keresse?
Nem DNAT, amivel átírom és továbbküldöm; nem ICMP redirect, amivel a közbenső útvonalat (routing) befolyásolhatom, hanem olyan ami azt üzeni, hogy a cél elköltözött.
Gugliztam egy ideig, meg olvasgattam a protokollok leírását, de nem találtam ennek megfelelőt. Talán csak az "ICMP Type 6: Alternate Host Address" lehet ilyesmi, amiről viszont nem találtam leírást illetve olyat is írtak, hogy nem implementált sehol.
Nézelődtem ICMPv6/IPv6 fronton is, hátha a mobil ip-k révén valamiként visszajutok egy IPv4-es analógiára, de semmi.
Valaki tud hasonlóról? Vakvágányról, amely egykor erre irányult?

Hozzászólások

Internet Control Message Protocol (ICMP) Parameters, én ilyet nem látok. Az ICMP Type 6 pedig RFC-be sem került be.

Azon a kérdésen kívül, hogy létezik-e ilyen ICMP type vagy IP option, mi a megoldandó feladat, amire sem a DNS, sem routing, sem a natolás, sem a kliens átállítása, sem proxy, sem egyéb L7 megoldások, sem semmi egyéb nem segít?

Van egy LVS masquerade-es tűzfalunk/load balancerünk (publikus IP -> privát IP), ami mögött van számos frontend (privát IP). Ha a benti frontendek valamelyike egy másik frontend-et a publikus IP-jén akar megszólítani (pl. API hívás, feed betöltése), akkor SYN_SENT-ben ragadnak a kapcsolatok, felgyűlnek a szálak és bedől a frontend. Persze általában nem IP-vel, hanem domainnel szólítják meg a másikat.
Most belső DNS-el és tűzfalas logolással szűrjük az ilyen problémákat, de nem tudunk minden domainre és subdomainre odafigyelni, amit a fejlesztők felvesznek, egyik-másik site-nál. A multi-tenant (pl. Freeweb) környezetkben gondolom ennek a kezelése megoldott valamiként.

a) a frontendeken pl. host route-okkel meg kell oldani, hogy az egyik frontendről a másik frontendre menő forgalmak az LVS tűzfal/load balanceren keresztül menjenek - ha direktben is el kéne érjék egymást valahogy a frontendek belül, arra külön IP címek legyenek a gépeken, igazából a legjobb megoldás teljesen másik IP subnet alkalmazása a két célra (egymás elérésére és a kintről jövő load balance-olt kérésekre)

b) a frontendeken a kimenő forgalomra rakott tűzfalon szűrni kell a publikus címekre indított forgalmat

c) a frontendeken a kimenő forgalomra rakott tűzfalon DNAT-olni kell a publikus címekre indított forgalmat - load balance-olni ugye nem fogod tudni, tehát fixen valamelyik gépre kell irányítani

d) az LVS masq tűzfalon/load balanceren a bejövő forgalomból ki kell szűrni, ami a frontendek privát címe felől jön és tűzfal által kezelt publikus címre megy.

e) az LVS masq tűzfalon/load balanceren - ha tud egyáltalán ilyet - kiszűrés helyett lehet SNAT-olni ezeket a forgalmakat, olyan címekre, amikről a frontendek azt hiszik, hogy kintiek (azaz az LVS masq tűzfal/load balancernek küldik vissza a válaszokat, az melyik majd helyreállítja az eredeti címet) - lehet SNAT helyett MASQ-ot is használni, de akkor elveszik az információ, hogy honnan jöttek a kérések, azaz a frontendeken az fog látszani, hogy az LVS-től jött a kérés, ez megnehezíti sokszor a debugolást, logok bogarászását, és security szempontból is lehet gázos

nincs ilyen és nem is fogsz találni, mivel még ha meg is oldod valahogy a saját oldaladon, a fogadó oldal úgy se támogatja

IP szinten ilyen nem létezik.

HTTP szinten van (301/302).