#archlinux #linux #nas
Może mamy tu jakiegoś specjalistę bo przeszukałem już pol internetu i coś mnie chyba trafi jak nie rozwiaze tego. Dziś po aktualizacji Archa zrestartowałem sobie domowego NASa ( zaadaptowany 1litrowy lenovo) i wszystkie usługi przestały być dostępne z poziomu sieci LAN czyli z PC, laptopa, telefonow podłączonych do domowego routera do którego również wpięty jest ten sam NAS - wszystko w tej samej adresacji.
Nie mogę się podłączyć do usług działających bezposrednio w systemie: SSH, NFS, Cockpit, jak i tych działających na dockerze : dhcp, photoprism, pihole itp.
Co dziwne - wszystko działa z zewnatrz. Tak więc jeśli rozłączę się z sieci domowej i polacze przez telefon, to mogę bezposrednio wpiąć się przez ssh, jak również dzialaja wszystkie serwisy wystawione na zewnątrz. Co już zrobilem:
1. Restartowałem nasa wielokrotnie
2. Wyłączałem iptables, dodawałem reguły które dawały pełen dostęp z konkretnego pc. Innego firewall nie mam
3. Sprawdzałem czy jakaś usługa się nie wykracza, wszystko wydaje się ok.
4. Odpalałem sshd w trybie ręcznym na NASie (-ddd -p 42) I przy próbie podłączenia z lokalnego PC nic się nie wywala, po prostu wisi na kroku ssh2_msg_kexinit sent, mam wrażenie że wszystkie usługi właśnie w taki sposób dzialaja. Nic się nie wywala tylko połączenie wisi. Przez co nic za bardzo nie widać w logach tylko connection timeout.
5. Ping pomiędzy maszynami w LAN działa normalnie, to samo MTU 1500

Czy ktoś ma jakiś pomysł co mógłbym jeszcze sprawdzic?
wykopany

Ale przestały na archu czy na nasie? Co wystawiasz na świat?

bendyz

@wykopany NAS działa na Archu, Czyli NAS jest po prostu kombinowanym PC. Wszystkie usługi na nim stoją. Na świat wystawiam ssh, i kilka stron typu photoprism,nextcloud. Do tego wireguard vpn.

wykopany

@bendyz sprawdzilbym na nas tcpdump w momencie jak próbujesz się połączyć z lan (trzeba dwa pc, jeden przez wan i SSH, drugi z lan).


Druga rzecz: tablica arp na nas.


Trzecia: czy z lan sprawdzisz po ip czy po host? Jaki arp widzą klienci w lan?

bendyz

@wykopany lan sprawdzam po IP, chociaz po hostname tez powinno działać gdy wszystko jest ok (na pihole mam wpisane rekordy lokalne do dns-a i kieruje do NAS-a)

tablica arp - wygląda w porządku.

tcpdump. tu jest w sumie ciekawie - przy połączeniu z lan na serwerze przechwytywany jest kilkukrotnie ten sam pakiet ack 1, length 21, więc wygląda to tak jakby nie odpowiadał/prosił o ponowienie. Przy połączeniu z zewnątrz ten pakiet dostaje raz i pozniej idą kolejne. Dzięki za tę podpowiedź. Musze sprawdzić w takim razie co jest wysyłane.

wykopany

@bendyz w tcpdump w którą stronę idą te pakiety? Może to pakiety syn od klientów? Może być też kwestia martian packets - to się wiąże z tablicą routingu. Ew coś było ustawione na nasie i wyleciało po restarcie?

bendyz

@wykopany tcpdump odpalalem na nasie wiec zbieral dane przesyłane z PC do NAS.

Jeśli chodzi o ustawienia przed restartem to jedyne co to blokowałem kilka IP iptables i nie zapisalem, ale to były proste reguły na blokady zewnętrznych adresów IP.


Poczytam jutro o martian packets, dzieki.

wykopany

@bendyz w tcpdump powinny być wszystkie pakiety, wysyłane i odbierane. W TCP najpierw jest three way handshake, jeżeli widać powtarzane acki to odpowiedzi nie dochodzą. Ew nie wychodzą (łańcuch output). Warto też sprawdzić reszte tabel w iptables, nat, mangle I raw.

ZohanTSW

A to prawdziwy Arch czy wyrób archopodobny typu Manjaro? bo z doświadczenia nie tylko mojego te wszystkie nibyarche potrafią się posypać po aktualizacji i właśnie z podobnego powodu zrezygnowałem w styczniu z endeavor os xd

bendyz

@ZohanTSW zwykly arch na tym NASie. Na pc mam manjaro testing, na laptopie manjaro stable. Ogólnie chwale sobie manjaro i pochodne archa bo już na PC od jakiś 3 lat to stoi i nic się za bardzo nie dzieje.

Zrobilem dziś restart na tym NASie ze względu na aktualizacje xz, stwierdziłem że może warto to zrobić bo prób logowań trochę mam.

mike-litoris

@bendyz cześć.

zacząłbym od rzeczy najprostszej - czy po reboocie jesteś w stanie się podłączyć do rzeczonego NAS'a lokalnie? Typu UART, lokalna konsola (klawiatura + ekran)?

bendyz

@mike-litoris Tak, podlaczyłem monitor, klawiatura, wszystko działa. Działa sieć, jest internet, udostępnia usługi na external

mike-litoris

@bendyz szpetnie wonio tablicą routingu. sprawdź


ip r


czy przypadkiem metryka 'świata' nie ma wyższego priotytetu niż metyka Twojego lanu.

W jaki sposób realizujesz przekierowanie do internetu? Rotuer i dest nat na adres nasa czy coś bardziej poczarowanego?

bendyz

@mike-litoris Metryki wydają się ok, wszedzie 100 - poniżej wklejam co wypluło ip r.

Nas ma adres .240

Na świat standardowe przekierowanie portów + ngix proxy dla http.


-> ip r default via 192.168.0.1 dev eth0 proto static metric 100

172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1

172.18.0.0/16 dev br-abc8c0002f09 proto kernel scope link src 172.18.0.1 linkdown

172.19.0.0/16 dev br-9feb81cba85f proto kernel scope link src 172.19.0.1

172.20.0.0/16 dev br-a39f0d4c0f24 proto kernel scope link src 172.20.0.1 linkdown

172.21.0.0/16 dev br-1a65bea89db6 proto kernel scope link src 172.21.0.1

172.22.0.0/16 dev br-b63f25139592 proto kernel scope link src 172.22.0.1 linkdown

172.23.0.0/16 dev br-9ae9c74b006c proto kernel scope link src 172.23.0.1 linkdown

172.25.0.0/16 dev br-e3a5482f64d5 proto kernel scope link src 172.25.0.1 linkdown

172.26.0.0/16 dev br-141520cf48c5 proto kernel scope link src 172.26.0.1

172.30.0.0/16 dev br-a2075c745267 proto kernel scope link src 172.30.0.1

192.168.0.0/24 via 192.168.0.1 dev eth0 proto static metric 100

192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.240 metric 100

mike-litoris

@bendyz no to pozostaje pytanie co widać w

tcpdump -veni eth0 port 22


kiedy próbujesz się łączyć po ssh z lanu.

Jeśli nic się nie odbija to znaczy że problem masz na wcześniejszym hopie (router lub urządzenie z którego się łączysz).

bendyz

@mike-litoris @mike-litoris wrzucam log. 1. dziwne dla mnie ze o ile z PC do NAS są poprawne MAC adresy to w drugą stronę wysyłany jest na jakiś adres z tyłka. 2 sprawa, przy każdym pakiecie z NAS do PC mamy checksum incorect.

Co do routera. Wszystkie pozostałe urządzenia ze sobą normalnie gadają. Wymieniałem też kabel.


1348.236949 d632xx:xx > 6c90xx:xx, ethertype IPv4 (0x0800), length 74: (tos 0x48, ttl 64, id 28937, offset 0, flags [DF], proto TCP (6), length 60)

   192.168.0.220.56544 > 192.168.0.240.42: Flags [S], cksum 0xa227 (correct), seq 2496198775, win 32120, options [mss 1460,sackOK,TS val 3148775241 ecr 0,nop,wscale 7], length 0

1348.237006 6c90xx:xx > e4e2xx:xx, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)

   192.168.0.240.42 > 192.168.0.220.56544: Flags [S.], cksum 0x834b (incorrect -> 0x46dd), seq 1864965544, ack 2496198776, win 31856, options [mss 1460,sackOK,TS val 2205436923 ecr 3148775241,nop,wscale 7], length 0

1348.238084 d632xx:xx > 6c90xx:xx, ethertype IPv4 (0x0800), length 66: (tos 0x48, ttl 64, id 28938, offset 0, flags [DF], proto TCP (6), length 52)

   192.168.0.220.56544 > 192.168.0.240.42: Flags [.], cksum 0xf11d (correct), ack 1, win 251, options [nop,nop,TS val 3148775242 ecr 2205436923], length 0

1348.238085 d632xx:xx > 6c90xx:xx, ethertype IPv4 (0x0800), length 87: (tos 0x48, ttl 64, id 28939, offset 0, flags [DF], proto TCP (6), length 73)

   192.168.0.220.56544 > 192.168.0.240.42: Flags [P.], cksum 0x2858 (correct), seq 1:22, ack 1, win 251, options [nop,nop,TS val 3148775242 ecr 2205436923], length 21

1348.238150 6c90xx:xx > e4e2xx:xx, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 9793, offset 0, flags [DF], proto TCP (6), length 52)

   192.168.0.240.42 > 192.168.0.220.56544: Flags [.], cksum 0x8343 (incorrect -> 0xf109), ack 22, win 249, options [nop,nop,TS val 2205436924 ecr 3148775242], length 0

1348.249637 6c90xx:xx > e4e2xx:xx, ethertype IPv4 (0x0800), length 87: (tos 0x0, ttl 64, id 9794, offset 0, flags [DF], proto TCP (6), length 73)

   192.168.0.240.42 > 192.168.0.220.56544: Flags [P.], cksum 0x8358 (incorrect -> 0x2839), seq 1:22, ack 22, win 249, options [nop,nop,TS val 2205436935 ecr 3148775242], length 21

1348.444864 d632xx:xx > 6c90xx:xx, ethertype IPv4 (0x0800), length 87: (tos 0x48, ttl 64, id 28940, offset 0, flags [DF], proto TCP (6), length 73)

   192.168.0.220.56544 > 192.168.0.240.42: Flags [P.], cksum 0x2789 (correct), seq 1:22, ack 1, win 251, options [nop,nop,TS val 3148775449 ecr 2205436923], length 21

1348.444900 6c90xx:xx > e4e2xx:xx, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 9795, offset 0, flags [DF], proto TCP (6), length 64)

   192.168.0.240.42 > 192.168.0.220.56544: Flags [.], cksum 0x834f (incorrect -> 0x9ea7), ack 22, win 249, options [nop,nop,TS val 2205437131 ecr 3148775449,nop,nop,sack 1 {1:22}], length 0

1348.453845 6c90xx:xx > e4e2xx:xx, ethertype IPv4 (0x0800), length 1186: (tos 0x0, ttl 64, id 9796, offset 0, flags [DF], proto TCP (6), length 1172)

bendyz

no dobra ten 3 adres MAC to jest mój router

mike-litoris

@bendyz jeśli o sumy kontrolne idzie to jest to normalne w przypadku kiedy ich wyliczanie jest przerzucane na sprzęt.

Druga sprawa - czy Ty masz ssh nasłuchujące na porcie 42?

Jak mniemam, .240 to nasz pacjent, a .220 to inne urządzenie klienckie w Twojej sieci z którego próbujesz się łączyć?

Catharsis

@bendyz Taka rada. Jak korzystasz z czegoś rolling-release to rób sobie co jakiś czas backup plików systemowych i wszystkich configów np za pomocą timeshifta. Wtedy w takiej sytuacji możesz się łatwo cofnąć do poprzedniego działającego stanu i dowiedzieć się czy to wina aktualizacji czy coś innego się wywaliło.

bendyz

@mike-litoris @wykopany dzięki za pomoc. Nie mialem za bardzo czasu i chęci żeby to ogarnąć, dziś siadłem z dodatkową kartą ethernet na usb zeby sprawdzić czy inny interfejs pomoże. Obyło się jednak bez tego. w tablicy routingu zauważyłem ze jeden wpis jest podejrzanie zbędny, porównałem z innymi maszynami i tam go nie było. Tak więc po prostu wywaliłem i wszystko działa. Nie mam pojęcia skąd on się tam wziął, ale do czasu restartu po aktualizacji systemu wszystko działało więc jest to troszeczkę niepokojące. Jeszcze raz dzięki za poświęcony czas.

93e5e690-5136-4a4c-8891-8b6df7bf099b

Zaloguj się aby komentować