[Megoldva]Hibás hálózat, csak bejövő kapcsolatok (Arch)

Fórumok

Sziasztok!

Már tépem a hajam. Van egy arch linuxos gépem, ami fél évig állt, és most hogy be kellett kapcsolnom, előtte átállítottam fix IP-ről dhcp-re.
Szépen megy is, kap IP-t, DGW-t, nameservereket, ezeket ellenőriztem is.

Azonban van egy olyan probléma, hogy csak a bejövő kapcsolatokra válaszol, azaz be tudok rá ssh-zni, megy rá a ping, minden.
De a másik irányba semmi, azaz a gép nem tud kapcsolatot kezdeményezni, nem tud még pingelni vagy DNS lekérdezést sem végezni. (így frissíteni se tudom)

A firewall biztos okés, eddig is ez volt, de az OUTPUT láncot acceptre állítva se volt változás.

Bármi tipp, hogy mi okozhatja ezt a számomra sci-fi jellegű hibát?
Köszi!

Hozzászólások

ha befele megy a dolog akkor csak valami firewall a hibas szoval elso korben iptables-t nullazzad szerintem.

Csak az "internetet" fele vagy a helyi halon se tudsz kimeno kapcsolatot letesiteni?

mint ahogy írtam is, nem iptables. nullázva is ugyan az mint beállítva, és ugyan ezzel a szabályrendszerrel szépen üzemelt eddig.

se internet se helyi háló irányába semmi, azaz még a DGW-t sem tudom elérni, semmit, ha azt a gépről indítom.


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
2: eth0: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether 00:50:8d:fg:fg:fg brd ff:ff:ff:ff:ff:ff
inet xxx.zzz.yyy.uuu/21 brd hhh.jjj.ggg.255 scope global eth0

ami feltűnt az itt az UNKNOWN state, de nem találtam rá semmi értelmeset
ifconfig nem ír semmi gyanúsat

"ami feltűnt az itt az UNKNOWN state"
Mivel a < és > között álló flageket kihagytad a kimenetből, így csak feltételezni tudom, hogy az ABIT kártyáról nem lehet lekérdezni a linkállapotot, és ezért ismeretlen, vagy pedig ez egy kernel (/sys/class/net/eth0/operstate) bug - esetleg minimális eséllyel iproute. Mivel a kártya működik, szerintem egyelőre ne foglalkozz vele.

"helyi háló irányába semmi, azaz még a DGW-t sem tudom elérni, semmit, ha azt a gépről indítom."
A DHCP kérések viszont kimentek erről a gépről, és a válaszok is visszajöttek mivel kapott IP-t.

"A firewall biztos okés, eddig is ez volt, de az OUTPUT láncot acceptre állítva se volt változás."
Egy kétirányú kommunikációba nem csak az OUTPUT lánc szól bele. A probléma kizárásához állíts minden érintett láncot ACCEPT-re.

"nem tud még pingelni vagy DNS lekérdezést sem végezni"
Meddig jut el? A tcpdump mit mondott? ARP van? Az ICMP Echo Request kimegy az eth0-n? A pingelt gépre elér? A pingelt gép válaszol? Az ICMP Echo Reply visszaérkezik az eth0-ra?

"Mivel a < és > között álló flageket kihagytad a kimenetből"
szerintem kiszedte a portál motor:
eth0: BROADCAST,MULTICAST,UP,LOWER_UP

"A DHCP kérések viszont kimentek erről a gépről, és a válaszok is visszajöttek mivel kapott IP-t."
Ez igaz.

"Egy kétirányú kommunikációba nem csak az OUTPUT lánc szól bele. A probléma kizárásához állíts minden érintett láncot ACCEPT-re."
Megtettem, változást nem okozott.

"Meddig jut el? A tcpdump mit mondott? ARP van? Az ICMP Echo Request kimegy az eth0-n? A pingelt gépre elér? A pingelt gép válaszol? Az ICMP Echo Reply visszaérkezik az eth0-ra?"
Ahogy látom az ARP kérés kimegy, be is kerül ARP táblába. Semmi más forgalmat nem látok kimenni (amit a gépről indítanék), azaz se ICMP se semmi.

Rendben. Akkor most új (és újbóli) megerősítő kérdések jönnek.

route -n

    # vagy ip route show

ip route get 8.8.8.8
arp -n

Otthoni hálózaton szokatlanul nagy az általad használt /21. Biztos rendben van ez a maszk?

iptables -nvL ; iptables -t nat -nvL ; iptables -t mangle -nvL ; iptables -t raw -nvL

    # tényleg minden lánc üres, és a default policy mindenhol ACCEPT?
Nem használsz valami MAC-et (pl. SELinux)?
A logokban nincs semmi érdekes?

Az első négy kérdésre elvileg megfelelő eredményt kell kapnunk, mivel kintről kezdeményezett forgalom működik. Főként az utolsó három lehet irányadó.

1)ahogy fentebb is írtam rendben
2) DGW-t adja
3) DGW, DNS, és pár helyi hálózatos gép szerepel benne, mait próbáltam pingelni
4)rendben, egyetemi háló
5) igen, üres, és ACCEPT mind
6) tudtommal arch default telepítésével nem jött ilyen, én nem állítottam be
7) logokban sem találtam semmit eddig


ifconfig
eth0: flags=4163 UP,BROADCAST,RUNNING,MULTICAST mtu 1500 metric 1
inet xx.yy.zz.hh netmask 255.255.248.0 broadcast xx.zz.gg.255
ether 00:50:8d:ff:tt:ll txqueuelen 1000 (Ethernet)
RX packets 7575330 bytes 582356954 (555.3 MiB)
RX errors 0 dropped 61166 overruns 0 frame 0
TX packets 14499 bytes 2951204 (2.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 18 base 0x8000

a nat es a mangle lancokat is megnezted? Ha te tudsz kommunikalni a geppel local halorol akkor a routing + switching mukodik. Tapasztalataim szerint ilyenkor valamilyen szuro a problema. Esetleg duplicate ip. Erdemes megnezni, hogy amikor kivulrol kommunikalsz a geppel a mac-cimek megegyeznek-e.

minden lánc teljes iptables takarítás után ACCEPT és semmi.
duplicate IP esetén is látnom kellene tcpdump-pal ahogy elhagyják a csomagok az interfacet, nem? meg ilyen esetben hol elérném a gépet, hol nem, attól függően, hogy a GW mit tesz az arp táblájába adott IP-hez

ilyen: TP-LINK TL-SG1005D
ez van rákötve az ottani "nagy" (cisco gbit, pontos típust nem tudok) switchre. este kipróbáljuk, hogy a TP-LINK kihagyásával megy e, de nem tudom elképzelni, hogy hogyan okozhatná ez a switch azt hogy nem mennek a kimenő kapcsolatok, de mivel eddig nincs ésszerű magyarázat, mindent ki kell próbálni.

meglett a bűnös :)

szóval a hiba, hogy nem elég az iptables takarításhoz:
iptables -F
iptables -X
iptables -t mangle -F
iptables -t mangle -X

hanem kell még:
iptables -t nat -F
iptables -t nat -X

Mivel volt egy natolás a régi IP-mre és bent maradt a POSTROUTING szabály. Azonban ezt nem vettem észre míg egy tipp miatt ezt ki nem kapcsoltam:
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter

Ezután láttam, hogy régi IP-mel megy ki csomag, és ekkor etc-ben rákeresve megleltem a bűnös iptables szabályt, amit nem tudtam, hogy a fenti parancsok nem ürítenek ki. De valószínűleg ezt a nat szabályt kicsit másképp kellett volna megírnom.

Köszönöm a segítséget! A megérzésetek helyes volt.

"volt egy natolás a régi IP-mre és bent maradt a POSTROUTING szabály"

Az ezt firtató kérdésemre, ahol a nat tábla listázásra is írtam kész parancssort, azt válaszoltad, hogy "igen, üres, és ACCEPT mind". Kalebris ugyanezt ismételten megkérdezte.

A lényeg, hogy megoldódott.