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
- 7952 megtekintés
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Nem feltételezem,hogy nálad van a hiba.:) Igen utána láttam,hogy hosszú út lenne :)
Közben átírtam a hozzászólásom, mert lehet lehet érdemes lenne kideríteni, ha a te géped le van kapcsolva, akkor is erre a MAC címre válaszol-e az ARP ping.
- A hozzászóláshoz be kell jelentkezni
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 :/
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Elsőre azt mondanám, hogy egy "nmap -sn 5.255.255.255/8" eredménye, amivel fel lehet deríteni, hogy milyen IP címek látszanak a hálózaton.
Aztán, hogy ezt az ottani adminok csinálták vagy valaki valami disznóságot próbál elkövetni... ;)
- A hozzászóláshoz be kell jelentkezni
és valószínűleg tényleg az mert egy darab ip sem válaszol közülük
- A hozzászóláshoz be kell jelentkezni
Konnyen lehet, hogy az a gw-uk csak ugyanabban a vlan-ban tobb kulon subnetet is felkonfiguraltak es a te tartomanyod nem fedi le mindet.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
két ip-je van a gépnek, mert ddos miatt a játékszervert külön ip-re raktam, de ez már szeptember óta így van
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
ddos esetén a szolgáltatók nullrouteolják az adott IP címet, így ha a game szerveres IP-jével megteszik ezt, a másik ip-je míg vígan megy.
- A hozzászóláshoz be kell jelentkezni
pontosan
- A hozzászóláshoz be kell jelentkezni
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ő...
- A hozzászóláshoz be kell jelentkezni
sajnos csak rescue modeban tudom bootolni a gépet, szóval nem nagyon hiszem hogy mérvadó lenne a kimenete
- A hozzászóláshoz be kell jelentkezni
Rögtön reboot után nem is látszik, adott üzemidő után jött elő. Ami még lehet, hogy bridge-be van konfigolva a géped. Egyébként management konzolt nem adnak a gépre? Mert ez így igazán nehezen kideríthető.
- A hozzászóláshoz be kell jelentkezni
netKVM de ott nincs net, 48 órás KVM-rt meg nem fizetnék 10k-t hobbi gépnél
- A hozzászóláshoz be kell jelentkezni
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:1lo 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
- A hozzászóláshoz be kell jelentkezni
így minden után most kiváncsian várom hogy javult-e szerintük
- A hozzászóláshoz be kell jelentkezni
VPN-t sem konfigoltatok? Mert latok tun0 interface-t is.
- A hozzászóláshoz be kell jelentkezni
de openvpn volt rajta, már nem fut egy ideje
edit: vagyis már nem fut, chkconfigban véletlen nem lőttem ki
- A hozzászóláshoz be kell jelentkezni
ip addr mit mond?
route tabla hogy nez ki?
Mi van a tunnel interface "tuloldalan"?
- A hozzászóláshoz be kell jelentkezni
[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
- A hozzászóláshoz be kell jelentkezni
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/
- A hozzászóláshoz be kell jelentkezni
és valóban be volt kapcsolva, viszont én biztos nem játszottam ilyesmivel, centos 6.4-n mi ennek a default értéke? köszi a tippet valószínűleg tényleg ez lehetett a gond, amint válaszol support kiderül
- A hozzászóláshoz be kell jelentkezni
Tippre az OpenVPN csinálta..
---------
http://evilrouters.net/2011/10/27/choose-internetworking/
- A hozzászóláshoz be kell jelentkezni
Van válasz? Érdekelne! (:
- A hozzászóláshoz be kell jelentkezni
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.........
- A hozzászóláshoz be kell jelentkezni
Err.. nos, ha nem kell nekik a pénzed hát nem kell..
- A hozzászóláshoz be kell jelentkezni
AFAIK alapból nem csinálja, legalábbis az általam használt verziók nem.
Amikor én konfigoltam openvpn-t - és az IP layout úgy adódott ki, hogy kelljen - mindig magamnak kellett bekapcsolnom.
---
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
+1
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/
- A hozzászóláshoz be kell jelentkezni