szerver olyan ip-n válaszol, ami nincs is neki...?

hali, letiltották a bérelt gépemet a szerverteremben, mert elvileg egy másik ügyfél ip-jét is használom. Ifconfig-ot nem tudok megnézni, révén hogy gép letiltva... rescue cd-vel ifcfg-k a következők:

DEVICE="eth0"
BOOTPROTO="static"
GATEWAY="62.141.42.1"
HOSTNAME="b039.blue.fastwebserver.de"
HWADDR="90:2B:34:95:87:DD"
IPADDR="62.141.42.39"
IPV6INIT="yes"
MTU="1500"
NETMASK="255.255.255.0"
NM_CONTROLLED="no"
ONBOOT="yes"
TYPE="Ethernet"
IPV6_AUTOCONF=no
IPV6INIT=yes
IPV6ADDR=2001:4ba0:fff1:00af:0000:0000:0000:0002/64
IPV6_DEFAULTGW=2001:4ba0:fff1:1:beef::1
DNS1=8.8.8.8
DNS2=8.8.4.4

DEVICE="eth0:1"
BOOTPROTO="static"
GATEWAY="62.141.42.1"
HOSTNAME="b039.blue.fastwebserver.de"
HWADDR="90:2B:34:95:87:DD"
IPADDR="5.199.130.150"
IPV6INIT="yes"
MTU="1500"
NETMASK="255.255.255.0"
NM_CONTROLLED="yes"
ONBOOT="yes"
TYPE="Ethernet"
DNS1=8.8.8.8
DNS2=8.8.4.4

Szerverterem ezt küldte:

ARPING 46.20.33.178 from 192.168.253.221 vlan21
Unicast reply from 46.20.33.178 [90:2B:34:95:87:DD] 452.260ms
Unicast reply from 46.20.33.178 [90:2B:34:95:87:DD] 0.652ms
Unicast reply from 46.20.33.178 [90:2B:34:95:87:DD] 0.610ms
Unicast reply from 46.20.33.178 [90:2B:34:95:87:DD] 0.635ms
Sent 4 probes (1 broadcast(s))
Received 4 response(s)

grep -r "46.20.33.178" . az egész lemezen nem talált semmit...

Az ifcfg-k nem változtak durván 6 hónapja, fogalmam sincs mi lehet az oka... Előre is köszönöm a segítség ha valakinek van ötlete

Hozzászólások

ARP cache törlés után is ezt mondja?
Nem lehet,hogy a MAC címek egyeznek meg egy másik géppel és nem az IP? Elég hihetetlennek hangzik, de egy próbát megér.

düsseldorfban van a szerverterem (myLoc) és bérelt gép, az ip-t amiről beszélnek soha nem láttam még. ráadásul hobbi gépről van szó, fut rajta egy játékszerver meg egy git, apache és mysql, játékszerveren kívül max a programjaimat tesztelem rajta élesben, szóval igazi indok sincs hogy a hálózattal bármit bűvészkedjünk ami ezt okozhatta.

szerk.: a géphez ráadásul csak rescue mode hozzáférésem van... szóval még csak tesztelni se tudom hogy bármi változtatás milyen módon befolyásolja a dolgot

this was the result of arping when your servers switch port was closed:

ARPING 46.20.33.178 from 192.168.253.221 vlan21
Sent 4 probes (4 broadcast(s))
Received 0 response(s)

And this when I enabled the switch port again:

ARPING 46.20.33.178 from 192.168.253.221 vlan21
Unicast reply from 46.20.33.178 [90:2B:34:95:87:DD] 452.260ms
Unicast reply from 46.20.33.178 [90:2B:34:95:87:DD] 0.652ms
Unicast reply from 46.20.33.178 [90:2B:34:95:87:DD] 0.610ms
Unicast reply from 46.20.33.178 [90:2B:34:95:87:DD] 0.635ms
Sent 4 probes (1 broadcast(s))
Received 4 response(s)

úgyhogy nem hinném hogy mac ütközés lenne :/

Akkor bootolj be rescue módba és próbáld meg tcpdump-al vagy tshark-kal megnézni a hálózati forgalmat, hátha így is produkálja a hibát. Ők meg nyomják közben az ARP pinget.

Meg jó lenne tudni,hogy ki van még abban a vlan21-ben. Mert ha egy VLAN-ban vagytok, akkor meg a másik gép miért nem válaszol?

most nézem tcpdumpot és várok rájuk hogy tolják arpinget, de az már most feltűnt hogy:

17:04:02.020325 ARP, Request who-has 5.199.136.101 tell b142.blue.fastwebserver.de, length 46
17:04:07.900058 ARP, Request who-has 5.104.108.248 tell b142.blue.fastwebserver.de, length 46
17:04:07.917050 ARP, Request who-has 5.104.108.247 tell b142.blue.fastwebserver.de, length 46
17:04:07.948107 ARP, Request who-has 5.104.108.200 tell b142.blue.fastwebserver.de, length 46
17:04:13.478856 ARP, Request who-has 5.199.136.149 tell b142.blue.fastwebserver.de, length 46
17:04:13.507845 ARP, Request who-has 5.199.136.148 tell b142.blue.fastwebserver.de, length 46
17:04:13.770893 ARP, Request who-has 5.104.108.246 tell b142.blue.fastwebserver.de, length 46
17:04:13.848793 ARP, Request who-has 5.104.107.74 tell b142.blue.fastwebserver.de, length 46
17:04:13.991884 ARP, Request who-has 5.104.107.75 tell b142.blue.fastwebserver.de, length 46
17:04:13.998879 ARP, Request who-has 5.104.108.200 tell b142.blue.fastwebserver.de, length 46
17:04:14.033850 ARP, Request who-has 5.104.108.247 tell b142.blue.fastwebserver.de, length 46
17:04:14.153882 ARP, Request who-has 5.104.108.245 tell b142.blue.fastwebserver.de, length 46
17:04:14.182843 ARP, Request who-has 5.199.136.74 tell b142.blue.fastwebserver.de, length 46
17:04:14.484813 ARP, Request who-has 5.199.136.149 tell b142.blue.fastwebserver.de, length 46
17:04:14.998842 ARP, Request who-has 5.104.108.200 tell b142.blue.fastwebserver.de, length 46
17:04:15.182853 ARP, Request who-has 5.199.136.74 tell b142.blue.fastwebserver.de, length 46
17:04:15.252788 ARP, Request who-has 5.104.108.245 tell b142.blue.fastwebserver.de, length 46
17:04:15.261781 ARP, Request who-has 5.199.136.75 tell b142.blue.fastwebserver.de, length 46
17:04:15.296778 ARP, Request who-has 5.199.136.101 tell b142.blue.fastwebserver.de, length 46
17:04:15.372784 ARP, Request who-has 5.104.107.75 tell b142.blue.fastwebserver.de, length 46
17:04:16.020724 ARP, Request who-has 5.104.108.200 tell b142.blue.fastwebserver.de, length 46
17:04:16.033802 ARP, Request who-has 5.104.108.247 tell b142.blue.fastwebserver.de, length 46

ez a gép vajon mi a szart csinálhat a hálózaton... mert tcpdump ezzel van tele

Miért van eth0 es eth0:1 interfaced? Neme lehet hogy trunk portot kaptal es egy aékalmazas abban a VLAN-ban kezedett el komunikalni?

Milyen esetben van ertelme ennek?
Ddos eseten megtoltik a linket, a halokartyat vagy a gepet leterhelik, hol fog ez ebben az esetben segiteni rajtad ha ugyanazok a linken, halokartyan, oprendszeren van mindossze egy masik ip-d?
Vagy gondolod ha letiltjak network oldalrol mert dos-oljak akkor acl-bol tiltjak az ip-t es nem kompletten az interface-t kapcsoljak le/kulonitik el?

Nézz egy arp -an -t. Nekem volt olyan, hogy helyi hálón ügyesen valahogy azt hitte magáról gép, hogy övé egy tökidegen publikus IP. Kernel frissítés óta nem jött elő...

sikerült rávenni őket hogy adjanak kis időt hogy ránézzek standardba (ide érzem hogy azaz ip amit írtak nincs is használva senki által csak valami hálózati monitoruk érzékelt valamit aztán röhögnek ahogy rescue modeban kb nulla lehetőséggel szopok...), itt az arp -an:

[root@b039 ~]# arp -an
? (185.15.247.161) at 00:50:56:a1:6b:25 [ether] on eth0
? (5.104.108.31) at 00:0c:29:9b:56:e9 [ether] on eth0
? (62.141.42.205) at 40:61:86:98:17:61 [ether] on eth0
? (5.199.130.166) at on eth0
? (5.104.107.49) at 40:61:86:98:17:8d [ether] on eth0
? (93.186.196.70) at 00:24:21:2c:6e:91 [ether] on eth0
? (37.157.249.113) at 00:d0:03:b6:fc:00 [ether] on eth0
? (93.186.197.1) at 00:d0:03:b6:fc:00 [ether] on eth0
? (62.141.43.193) at 00:d0:03:b6:fc:00 [ether] on eth0
? (93.186.196.1) at 00:d0:03:b6:fc:00 [ether] on eth0
? (5.104.108.25) at 00:9c:02:a2:47:e2 [ether] on eth0
? (62.141.42.142) at 40:61:86:98:17:06 [ether] on eth0
? (78.31.71.150) at 00:16:3e:5d:eb:14 [ether] on eth0
? (62.141.42.1) at 00:d0:03:b6:fc:00 [ether] on eth0

illetve ifconfig:

[root@b039]# ifconfig
eth0 Link encap:Ethernet HWaddr 90:2B:34:95:87:DD
inet addr:62.141.42.39 Bcast:62.141.42.255 Mask:255.255.255.0
inet6 addr: 2001:4ba0:fff1:af::2/64 Scope:Global
inet6 addr: fe80::922b:34ff:fe95:87dd/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:35207 errors:0 dropped:0 overruns:0 frame:0
TX packets:34703 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2639791 (2.5 MiB) TX bytes:4364221 (4.1 MiB)

eth0:1 Link encap:Ethernet HWaddr 90:2B:34:95:87:DD
inet addr:5.199.130.150 Bcast:5.199.130.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:253 errors:0 dropped:0 overruns:0 frame:0
TX packets:253 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:21396 (20.8 KiB) TX bytes:21396 (20.8 KiB)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

arp cachet is töröltem, bár a fenti ip-t ott sem láttam, most megy kernel update épp

[root@b039 ~]# ip addr
1: lo: mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 90:2b:34:95:87:dd brd ff:ff:ff:ff:ff:ff
inet 62.141.42.39/24 brd 62.141.42.255 scope global eth0
inet 5.199.130.150/24 brd 5.199.130.255 scope global eth0:1
inet6 2001:4ba0:fff1:af::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::922b:34ff:fe95:87dd/64 scope link
valid_lft forever preferred_lft forever

[root@b039 ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
5.199.130.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
62.141.42.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0
0.0.0.0 62.141.42.1 0.0.0.0 UG 0 0 0 eth0

választ azóta se kaptam tőlük, viszont a gépet nem lőtték le a switchről azóta sem

Tipp: proxy-arp? Véletlenül.. A visekledés stimmel..
úgy válaszol ARP kérésre, hogy nem tulajdona az IP..

sysctl-el nincs ilyen beállítva?
net.ipv4.conf.eth0.proxy_arp
- vagy -
net.ipv4.conf.all.proxy_arp

Ellenőrizni lehet így:
cat /proc/sys/net/ipv4/conf/*/proxy_arp

---------
http://evilrouters.net/2011/10/27/choose-internetworking/

hát még mostis sír a szájuk... nem a proxy arp volt és már azt mondják max akkor kapcsolják vissza gépet ha full reinstallt tolok, LOL? főleg hogy egyik supportos azt mondta az összes fix után hogy nem válaszol egy gép se azon az ip-n, most pedig megint azt állítják hogy igen...

annyi lett a vége hogy lemondtam az egészet p*csába, nevetséges az egész. nekem kell azért is írni hogy miért nem megy a gép, egy emailt nem küldenének róla hogy letiltottak, support telibe se b*szott kb, meg ilyeneket írogat, egy értelmes ötlete nincs:

Since it seems that you do not understand what we say, I cannot reactivate your server cause I have to assume that you are unable to fix the issue permanently.

proxy arp nincs bekapcsolva, meglett erősítve másik supportos által is hogy a gép nem válaszol arpingre, ifcfg nem létezik ehhez az ip-hez és supportos még inzultál is amikor megkérdezi az ember hogy ezek után amiket már megcsináltam, mire nézzek még rá... egyáltalán magyarázza már meg légyszi valaki, hogy ha az adott gép elvileg online a hálózaton, akkor hogy kaphatom én meg a packetjeit? egyáltalán milyen hálózat az ahol random gép olyan ip-t húz be amit csak akar.........