request bejon, de "connection refused"

Linux-haladó

tcpdump mutatja, hogy a 25-os portra bejon a request (telnet x.x.x.x 25), de nincs valasz a futo Postfix-tol....(a log-ban nincs semmi)

Erdekes modon a "netcat -l 25" eseteben is ugyanez van.

tuzfal nincs. SElinux kikapcsolva. 

otlet?

(ugyanez ket gep kozott az ssh megy szepen, szoval a route jo)

  • 320 megtekintés

( blackluck v | 2021. 03. 21., v – 22:29 )

tcpdump-al fogod latni bejovo forgalmat akkor is ha valojaban local tuzfal megfogja, esetleg natolodik mashova vagy routing miatt dobja el (pl tobb interface van es routing szerint az a forras ip masik interface-hez van rendelve es rp_filter csak azon engedi be), de lehet vannak egyeb esetek is, nekem hirtelen ez ugrott be.

( zeller | 2021. 03. 21., v – 23:47 )

Nulladik lépés: netstat  -tlpn, hogy valóban minden lábon ott figyel-e a 25-ös porton a postfix, illetve én a selinux-ot bekapcsolnám permissive módban, és megnézném, "fogott-e" valamit (audit2why/audit2allow).

( wyx v | 2021. 03. 22., h – 08:06 )

Szerkesztve: 2021. 03. 22., h – 08:07

ELnezest, rosszul mondtam:

"no route to host.." a hiba.

 

 

[root@xxx-vfa-zbs-01 ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 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
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eno16780032: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:50:56:ae:64:ed brd ff:ff:ff:ff:ff:ff
    inet 10.17.0.110/24 brd 10.17.0.255 scope global eno16780032
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:feae:64ed/64 scope link
       valid_lft forever preferred_lft forever
3: eno33559296: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:50:56:ae:f2:9f brd ff:ff:ff:ff:ff:ff
 

[root@xxx-vfa-zbs-01 ~]# telnet 10.0.10.111 25
Trying 10.0.10.111...
telnet: connect to address 10.0.10.111: No route to host

 

[root@xxx-vfa-zbs-01 ~]# ping  10.0.10.111
PING 10.0.10.111 (10.0.10.111) 56(84) bytes of data.
64 bytes from 10.0.10.111: icmp_seq=1 ttl=63 time=0.318 ms
^C
--- 10.0.10.111 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.318/0.318/0.318/0.000 ms

 

[root@xxx-vfa-zbs-01 ~]# telnet 10.0.10.111 22
Trying 10.0.10.111...
Connected to 10.0.10.111.
Escape character is '^]'.
SSH-2.0-OpenSSH_8.0
^]
telnet> q
Connection closed.
 

Szia! Okulásképpen leírnád, hogy pontosan mit kellett máshogy csinálni,  hogy működjön? Amikor az eBPF és vele az nftables bejött a képbe akkor az volt az ígéret, hogy később is meghagyják az iptables kompatibiltást, csak a háttérben az iptables parancs is nftables szabályokat fog gyártani. Akkor ez most nem így van RHEL-nél?

Az "iptables -L" es tarsait fejeltsd el,  "nft list ruleset" es "systemctl status firewalld" parancsok a barataid.

Legalabbis a stock RH verzioknal. Nalunk azert nem volt ez feltuno, mert lecsereltek az nftables-t iptables-re (meg az uj 8-as disztrokban is), ugyanis

korabbi policy-k epultek erre. Aztan most deploy-oltam magamnak egy 8-ast, de ott ugy nem volt lecserelve, ez zavart meg! 

"lecsereltek az nftables-t iptables-re (meg az uj 8-as disztrokban is), ugyanis korabbi policy-k epultek erre" - Gányolásból jeles - meg egymás szivatásából is...

Már a RHEL7-ben is firewalld volt, úgyhogy bőven lett volna idő a régi szabályokat átültetni firewalld-s környezetre - bár tudom, listaság, fél egészség, de most sem késő nekilátni szerintem... Anno RHEL6-RHEL7 váltásnál az első gépeim (ezek  ",,tegnapra'' kell egy éles gép x, y, z szolgáltatásokkal" jellegű kérések miatt készültek) még iptables-sel mentek nekem is, de csak addig, amíg az egyébként elég összetett csomagszűrő szabályokat át nem ültettem/ültettük firewalld-s "service"-ekre, illetve néhány esetben direct rule-okra.

úgyhogy bőven lett volna idő

Csak kell valaki, aki magara vallalja, hogy atveri ezt a managementen, mert ugye az ido penz, es a cegek nagy resze spur. Aztan amikor dobjak a regi supportjat, akkor meg ott all letolt gatyaval a ceg :)
En ezert szoktam kiharcolni, hogy legalabb backlogban legyen ra ticket, mert akkor tudok mire mutogani, amikor jon a management, hogy ez miert nem lett megcsinalva (vagy meg jobb, "miert nem tudtunk rola").

( gabrielakos v | 2021. 03. 22., h – 09:21 )

Ó de szeretjük ezeket a generációváltásokat.

Tud valaki írni olyan életszerű példát amikor értelme volt iptables-nél újabb bármit használni? Szerveren?

zászló, zászló, szív