Sziasztok!
Picit hosszú leszek, de minden szükséges infót szeretnék megadni ahhoz, hogy tudjatok segíteni.
Adott egy bérelt szerver a Hetznernél. Az ethernet kártyára az lspci az alábbit köpi:
23:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
Nos A gép webszerverként működik. Ubuntu 24.04-et raktam rá.
Gépet megvettem, felraktam rá, amit akartam, nem nagy truváj. Majd jött az ötlet, hogy miért ne válthatnám ki egy géppel 2 gép funkcióját úgy, hogy 2 IP címet használok. Fel is húztam egy postfixet dockerben, ami látszólag működik is. Azonban hiába állítottam be az új IP-t, arra az Istennek se akar hallgatni. Sem a pingre, se másra nem válaszol.
A 95.217.36.183 IP-vel vettem a gépet, a 95.217.36.178-at pedig utólag kértem hozzá (ezzel van bajom).
cat /etc/netplan/01-netcfg.yaml
### Hetzner Online GmbH installimage
network:
version: 2
renderer: networkd
ethernets:
enp35s0:
addresses:
- 95.217.36.183/32
- 95.217.36.178/32
- 2a01:4f9:2b:2ee9::2/64
routes:
- on-link: true
to: 0.0.0.0/0
via: 95.217.36.129
- to: default
via: fe80::1
nameservers:
addresses:
- 8.8.8.8
- 2a01:4ff:ff00::add:1
- 8.8.4.4
- 2a01:4ff:ff00::add:2
Nézzünk egy ilyet is:
ip route show
default via 95.217.36.129 dev enp35s0 proto static onlink
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
Oké, akkor mit mond az ifconfig:
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
inet6 fe80::42:71ff:fe0b:7ae6 prefixlen 64 scopeid 0x20<link>
ether 02:42:71:0b:7a:e6 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4 bytes 440 (440.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp35s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 95.217.36.183 netmask 255.255.255.255 broadcast 0.0.0.0
inet6 2a01:4f9:2b:2ee9::2 prefixlen 64 scopeid 0x0<global>
inet6 fe80::aaa1:59ff:fe3e:bb9d prefixlen 64 scopeid 0x20<link>
ether a8:a1:59:3e:bb:9d txqueuelen 1000 (Ethernet)
RX packets 219528 bytes 39465168 (39.4 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 294920 bytes 245145398 (245.1 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0xfc200000-fc27ffff
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 559491 bytes 158599643 (158.5 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 559491 bytes 158599643 (158.5 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
vethdcbc1b1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::5c59:98ff:fe0e:5cf4 prefixlen 64 scopeid 0x20<link>
ether 5e:59:98:0e:5c:f4 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8 bytes 800 (800.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
és az ip addr show:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp35s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether a8:a1:59:3e:bb:9d brd ff:ff:ff:ff:ff:ff
inet 95.217.36.183/32 scope global enp35s0
valid_lft forever preferred_lft forever
inet 95.217.36.178/32 scope global enp35s0
valid_lft forever preferred_lft forever
inet6 2a01:4f9:2b:2ee9::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::aaa1:59ff:fe3e:bb9d/64 scope link
valid_lft forever preferred_lft forever
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:71:0b:7a:e6 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
inet6 fe80::42:71ff:fe0b:7ae6/64 scope link
valid_lft forever preferred_lft forever
5: vethdcbc1b1@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
link/ether 5e:59:98:0e:5c:f4 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::5c59:98ff:fe0e:5cf4/64 scope link
valid_lft forever preferred_lft foreverNa meg az ufw (iptables -L -n -v kimenet ide kattintva olvasható)
ufw status verbose Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), allow (routed) New profiles: skip To Action From -- ------ ---- 80/tcp ALLOW IN Anywhere 443/tcp ALLOW IN Anywhere 2226 ALLOW IN Anywhere 2226/tcp ALLOW IN Anywhere 110/tcp ALLOW IN Anywhere 995/tcp ALLOW IN Anywhere 143/tcp ALLOW IN Anywhere 993/tcp ALLOW IN Anywhere 25/tcp ALLOW IN Anywhere 465/tcp ALLOW IN Anywhere 587/tcp ALLOW IN Anywhere 18105/tcp ALLOW IN Anywhere 6379/tcp ALLOW IN Anywhere 95.217.36.178 on enp35s0 ALLOW IN Anywhere 2525 ALLOW IN Anywhere 80/tcp (v6) ALLOW IN Anywhere (v6) 443/tcp (v6) ALLOW IN Anywhere (v6) 2226 (v6) ALLOW IN Anywhere (v6) 2226/tcp (v6) ALLOW IN Anywhere (v6) 110/tcp (v6) ALLOW IN Anywhere (v6) 995/tcp (v6) ALLOW IN Anywhere (v6) 143/tcp (v6) ALLOW IN Anywhere (v6) 993/tcp (v6) ALLOW IN Anywhere (v6) 25/tcp (v6) ALLOW IN Anywhere (v6) 465/tcp (v6) ALLOW IN Anywhere (v6) 587/tcp (v6) ALLOW IN Anywhere (v6) 18105/tcp (v6) ALLOW IN Anywhere (v6) 6379/tcp (v6) ALLOW IN Anywhere (v6) 2525 (v6) ALLOW IN Anywhere (v6) Anywhere ALLOW OUT 95.217.36.178 on enp35s0
És végül ping:
ping 95.217.36.178 PING 95.217.36.178 (95.217.36.178): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1
Bárkinek bármi használható ötlete van esetleg? Ha még infó kell, szóljatok és írom. Köszönöm.
- 736 megtekintés
Hozzászólások
https://www.calculator.net/ip-subnet-calculator.html?cclass=any&csubnet…
Nagyon keveset tudok a hálózatokról, de ez a kevés alapján:
A /32 az annyit jelent, hogy a hálózatban 1 db gép van, saját maga. Ettől még láthatnák egymást, ha a route meg lenne oldva. Ennél egyszerűbb, ha nem /32-tőt használsz. Lásd subnet calculator
ps.: persze egy gépnek a saját ip címét látnia kell
"Majd jött az ötlet, hogy miért ne válthatnám ki egy géppel 2 gép funkcióját úgy, hogy 2 IP címet használok. Fel is húztam egy postfixet dockerben, ami látszólag működik is. Azonban hiába állítottam be az új IP-t, arra az Istennek se akar hallgatni. Sem a pingre, se másra nem válaszol."
Ez alapján nem 2 db ip kell neked, hanem haproxy.
- A hozzászóláshoz be kell jelentkezni
Cloud szolgáltatók szeretnek pont-pont kapcsolatot adni a virtuális gépeknek és a túloldalon routeolják a csomagokat a megfelelő tunnelekbe/interface-ekbe esetleg proxyARPognak ha kell. Az előnye hogy egy elkonfigurált VM nem tudja lelőni egy másik VM hálózatát és nem látod más broadcast vagy multicast forgalmait. Mint egy veth a hoston belül. A containerben ethernetet látsz, de az valójában nem az. Nem tudom hogy a Hetzner ezt konkrétan hogyan oldja meg, de az AWS IPv6-on valahogy így működik, a prefix length az /128 a DHCPv6 által kiosztott címeken. Szóval szerintem ez a /32 csak a cloud környezet adottsága, nem lényeges az issue szempontjából.
Azzal viszont egyetértek hogy a második IP felesleges, egy IP-n el tudná vinni az összes szolgáltatást ha nincs port ütközés. Én erre indultam volna el. Még haproxy sem kell ha nincs mögötte több gép vagy egy container, elég csak a Docker container portját kilógatni, vagy akár host networkon is futtatni a containert (nem annyira javallott ebben az esetben, de néha nincs más megoldás).
- A hozzászóláshoz be kell jelentkezni
haproxy itt arra lenne jó, hogy:
domain1 -> postfix1
domain2 -> postfix2
Vagyis domain alapon lehet irányítani különböző konténerizált mail szerverekhez a forgalmat.
- A hozzászóláshoz be kell jelentkezni
Mi alapján mondanád meg hogy melyik domainről van szó? Az RCPT TO alapján? Beszél egyáltalán a haproxy SMTP-t és nem csak TCP-t? Én úgy emlékszem csak load-balancingot csináltunk haproxy-val, nem protokoll szinten definiált szétválogatást. De nem tegnap volt.
Én erre pont inkább csak egy containert használnék ami mindkét domaint viszi és LMTP-vel rakhatja le a leveleket mondjuk két külön IMAP containerbe ha ez egyáltalán szükséges (egy Dovecot elég lehet ide ami kezeli az összes domaint). Ha meg nem lehet összevonni valami miatt akkor meg raknék elé egy mini SMTP router containert ami tolja befelé a leveleket.
- A hozzászóláshoz be kell jelentkezni
a kollega szerintem nem RCPTO TO domainre gondol, hanem hostname domainre: mail.egyik.ru, mail.masik.ru
- A hozzászóláshoz be kell jelentkezni
Rosszul emlékeznék?
EHLO enszerverem.endomain.tld
MAIL FROM: valaki@endomain.tld
RCPT TO: valakimas@tedomained.tld
STARTTLSItt hol lenne hostname domain, illetve mire gondolsz azalatt?
- A hozzászóláshoz be kell jelentkezni
az MX rekordra
- A hozzászóláshoz be kell jelentkezni
Fogalmam sincs. A doksiban olvastam, hogy lehet vele.
- A hozzászóláshoz be kell jelentkezni
A /32 több, mint ganyús (a .183 működik?).
- A hozzászóláshoz be kell jelentkezni
A .183 működik, de azt írtam is.
- A hozzászóláshoz be kell jelentkezni
Működik (én is tudtam pingelni) és a /32 sem gond, így kapod a Hetznertől (az én szerveremen is azonosan van, szintén Hetzner).
Én inkább a routingot nézném, mert a táblában nem jelent meg.
- A hozzászóláshoz be kell jelentkezni
VPN esetén ez teljesen normális, de a régi betárcsázós net esetén is ez volt a helyzet, így biztosított, hogy a szolgáltatói vonalra csak egy eszköz kapcsolódhasson közvetlenül (pp kapcsolat).
- A hozzászóláshoz be kell jelentkezni
Közben rájöttem, köszi, ott az on-link.
- A hozzászóláshoz be kell jelentkezni
Esetleg egy
ip route add 95.217.36.178/32 95.217.36.183
Fedora 42, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
Pontosabban: ip route add 95.217.36.178/32 via 95.217.36.183 dev enp35s0
De ez sem oldotta meg.
- A hozzászóláshoz be kell jelentkezni
A te átjáród valójában ez: 95.217.36.129
- A hozzászóláshoz be kell jelentkezni
Majd jött az ötlet, hogy miért ne válthatnám ki egy géppel 2 gép funkcióját úgy, hogy 2 IP címet használok
Nekem feleslegesnek tűnik két IP-cím. A különböző szolgáltatásokat különböző portokra kell definiálni, ahhoz meg elég egyetlen IP-cím.
Ha mégis több IP-címre van szükséged, akkor másképpen kell megrendelned a szolgáltatást.
- A hozzászóláshoz be kell jelentkezni
Oké, most nem ez a lényeg, hogy mi a felesleges, hanem, hogy miért nem működik?
- A hozzászóláshoz be kell jelentkezni
Mit rendeltél valójában? Két VPN-t kértél?
VPN esetén /32 az alhálózati maszk, így abban az "alhálózatban" csak egyetlen gép lehet, csak egyetlen IP-cím szerepelhet.
- A hozzászóláshoz be kell jelentkezni
Nem VPN-t vettem/kértem.
- A hozzászóláshoz be kell jelentkezni
tcpdump-ot az enp35s0-nak! Szűrd a kétes IP címre - 95.217.36.183! Ha megy a tcpdump, kezdd el pingelni.
A tcpdump kimenetben ami kérdéses:
- bejön-e egyáltalán a te gépedhez a kérdéses ICMP csomag?
- ha nem, akkor előtt jön-e ARP Request, hogy mi is a mac address ehhez az IP-hez?
- ha jön, akkor a masinád válaszol-e, hogy igen, itt vagyok?
- esetleg válaszol más is? Bár azt így nem fogod tudni: a válasz már nem broadcast. A következőt viszont ki tudod próbálni:
- lehúzod az interface-ről ezt az IP-t,
- gonosz módon mégis megpingeled. Válasz ugyan nem fog jönni - de az ICMP tiltás előtt azért az ARP-request, ARP response le fog futni, így az ARP táblába bele kerül a másik gép IP-je - már ha van ilyen. (Nem szabadna lenni, de biztos ami tuti: zárjuk ki a lehetőségét.)
Tovább lépni a válaszok ismeretében lehet majd. További problémára számíthatsz: meg kell majd oldani, hogy amikor a postfix konténer nyitna kapcsolatot kifele, akkor ne a default IP-n menjen ki a forgalom, hanem az erre dedikált IP címen. De előbb menjen a második IP, utána szöszöljünk azzal, hogy a kimenő kapcsolat használja is.
- A hozzászóláshoz be kell jelentkezni
Miért a .183-at akarjam piszkálni?
tcpdump -i enp35s0 host 95.217.36.178
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp35s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
22:40:04.343663 IP 128.199.148.131.40076 > smtp.tegyjot.com.457: Flags [S], seq 2798857730, win 1024, length 0
22:40:14.081893 IP 103.26.116.109.49263 > smtp.tegyjot.com.microsoft-ds: Flags [S], seq 120875257, win 8192, options [mss 1460,nop,nop,sackOK], length 0
22:40:26.321556 IP hosting-by.4cloud.mobi.50040 > smtp.tegyjot.com.8577: Flags [S], seq 2004926120, win 1024, length 0
22:40:34.438324 IP static.109.51.216.95.clients.your-server.de.52199 > smtp.tegyjot.com.https: Flags [SEW], seq 1999652922, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
22:40:37.442779 IP static.109.51.216.95.clients.your-server.de.52199 > smtp.tegyjot.com.https: Flags [SEW], seq 1999652922, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
Egyelőre eddig jutottam.
- A hozzászóláshoz be kell jelentkezni
Jogos, elírtam, a problémás IP cím nem a .183 hanem a .178.
A tcpdump alapján a forgalom kintről beesik, válasz semmire sem megy. A dolog annyiban jó hír, hogy a probléma a "dobozon belül" van azaz nálad.
Hogy változik a helyzet, ha kézből beszúrsz két tűzfalszabályt, amely a pingelést végző gép IP címéről minden forgalmat beenged és oda minden forgalmat ki is enged?
- A hozzászóláshoz be kell jelentkezni
Lehet, hogy nagy hülyeség, de ha a Docker benne van a buliban, azt is el tudom képzelni, hogy a válaszcsomag kimegy, csak nem a .178 forráscímmel, hanem a .183-mal.
- A hozzászóláshoz be kell jelentkezni
Esetleg egy teszt erejéig egy ilyet megnéznék:
ip address add 95.217.36.178/32 dev enp35s0- A hozzászóláshoz be kell jelentkezni
az ufw alapján nem látom, hogy az icmp engedélyezett lenne bejövő forgalomra. A tcpdumpban (egy -n flag nem lett volna rossz, hogy tényleg az IP legyen benne) meg a ping nem is látszik, az meg, hogy az itt lévő portokon az adott címen figyel-e bármi, nem derül ki.
- A hozzászóláshoz be kell jelentkezni
PING 95.217.36.183 (95.217.36.183) 56(84) bytes of data.
64 bytes from 95.217.36.183: icmp_seq=1 ttl=49 time=61.2 ms
64 bytes from 95.217.36.183: icmp_seq=2 ttl=49 time=61.6 ms
64 bytes from 95.217.36.183: icmp_seq=3 ttl=49 time=61.5 ms
64 bytes from 95.217.36.183: icmp_seq=4 ttl=49 time=61.5 ms
64 bytes from 95.217.36.183: icmp_seq=5 ttl=49 time=61.5 ms
64 bytes from 95.217.36.183: icmp_seq=6 ttl=49 time=61.5 ms
^C
--- 95.217.36.183 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 4998ms
rtt min/avg/max/mdev = 61.205/61.505/61.612/0.197 ms
- A hozzászóláshoz be kell jelentkezni
És? a probléma a .178 címmel van.
- A hozzászóláshoz be kell jelentkezni
És? A .183-ra vonatkozóan láttál itt olyat, amit keresel? :)
Amit látni szeretnél, annak ebben kellene lennie: /etc/ufw/before.rules
- A hozzászóláshoz be kell jelentkezni
Ez igaz. UFW-t nem ismerem, én azt a listát néztem, ami itt volt.
- A hozzászóláshoz be kell jelentkezni
Ifconfig helyett "ip a" parancsot hasznald, az ifconfig elavult es rosszul mutat sok mindent.
- A hozzászóláshoz be kell jelentkezni
Használta azt is. :)
ip address show
- A hozzászóláshoz be kell jelentkezni
Egy `ip r sh` kimenet talán még segíthetne.
Amikor távolról pingeted a gépet akkor egy `tcpdump -ni any icmp` mit mond? Van bejövő kérés? Megy válasz? Milyen forrás címmel?
- A hozzászóláshoz be kell jelentkezni
Egy `ip r sh` kimenet talán még segíthetne.
Azt is betette az eredeti hozzászólásába. :)
ip route show
- A hozzászóláshoz be kell jelentkezni
Igazad van, átsiklottam felette, túl rövid volt a szememnek, hosszabbat kerestem. :-)
A tcpdump még hasznos lenne így, nem IP-re szűrve.
- A hozzászóláshoz be kell jelentkezni
hetzner robot-on ellenőrizd, hogy az új ip címhez a megfelelő mac address tartozik vagy sem. Ha jól emlékszem, alapból generáltat kapsz a megrendelés után (és masszív mac alapú szűrés van náluk)
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
Hetzner-nél az Ipv4 -nél úgy működik, minden további ip címet (ip1, ip2, .. ) a "fő ip címedre" routolnak.
Forgalom
internet --> gw --> főipcím --> ip1, ip2, ...
internet <-- gw <-- főipcím <-- ip1, ip2, ...
Tehát, fel kell venned két FORWARD szabályt, minden további ip címhez(ip1, ip2,... ), hogy átengedd a forgalmat ( ezáltal tudod használni ):
-t filter -A FORWARD -s <ip1> -j ACCEPT
-t filter -A FORWARD -d <ip1> -j ACCEPT
#
-t filter -A FORWARD -s <ip2> -j ACCEPT
-t filter -A FORWARD -d <ip2> -j ACCEPT
....- A hozzászóláshoz be kell jelentkezni