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!
- 3074 megtekintés
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?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
"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?
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
Routing táblában mi van? Valami VPN SW-t nem raktál fel a gépre?
- A hozzászóláshoz be kell jelentkezni
csak DGW és helyi hálóra vonatkozó, így összesen 2db bejegyzés
a DGW ténylegesen a helyi hálón van és működik is, hiszen most is kívülről ssh-ztam be a gépre.
- A hozzászóláshoz be kell jelentkezni
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ó.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Tudsz valamit a switchrol amibe be van dugva a gep? Ha nem akkor: Fix ip, 2 gep, crosskabel, direktbe egymasra dugva es megnezni, hogy ugy megy-e.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
azt nezted mar, hogy megy-e ha csak a tp-linkre dugsz ra egy masik gepet? gep-gep kozotti kommunikacio megy-e?
- A hozzászóláshoz be kell jelentkezni
nem, tegnap nem volt rá idő, majd este megkérek valakit, hogy dugdossa és próbálgatom majd.
de a tp-linken lóg másik gép, azt sem tudom elérni amúgy, de nem csoda, ha egyszer semmi nem hagyja el az interfacet...
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
mint írtam is, nem tudtam, hogy az is kell. ritkán használok iptables-t, még ritkábban natolok vele, és eddig az iptables -nvL mindig elég volt. én hülyeségem, tudom.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
az esetek eleg nagy szazalekaban ha a->b forgalom mukodik de b->a irany nem akkor tuzfallal van a hiba meg akkor is ha nagyon nem ugy tunik.
- A hozzászóláshoz be kell jelentkezni