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?
- 4122 megtekintés
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?
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
Switch port ACL nem megoldás?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Ebből a d) megvalósított. Az SNAT-olással (e) is megpróbálkoztunk, de mivel felesleges overhead-et jelent, inkább az ilyen kapcsolatok REJECT-elését latolgatom. Mivel sok frontend van, a központi (direktoros) megoldás karbantarthatóbb (a), b), c)).
Mindenesetre köszi a tippeket.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
IP szinten ilyen nem létezik.
HTTP szinten van (301/302).
- A hozzászóláshoz be kell jelentkezni