Fórumok
Sziasztok, biztosan valami hülye egyszerű probléma, de nem jöttem rá miért nem tudom PINGELNI sem a benti gépeket. Külső címről a router port forwardjával elérhetők.
192.168.0.1 - SagemCom szolgáltatói router, port forward beéllítva
192.168.0.17 - Linux mint 19.3, ssh (22)
192.168.0.18 - Debian Linux 10.3, Kodi 8080-as porton, ssh (22)
192.168.0.47 - Linux Mint 19.3, ssh (22)
Ez utóbbin Win 10 is van virtuális gépen, azzal sem megy az elérés, csak a gazda gépre.
Mindegyiket webcím:port úton elérem. Ufw van telepítve, ha kikapcsolom és restart, akkor sem megy...
Hozzászólások
Nem lehet, hogy a router droppolja a ping csomagokat? Soha nem is működött, vagy egyszercsak előállt ez a helyzet?
> Sol omnibus lucet.
Nem látok összefüggést, a 18-as pl. néhány restart után bentről elérhető, aztán nem, de fut az sshd végig.
Mármint milyen, és hova?
Mármint nem pingelni, ugye?
Mi az a webcím, és honnan éred el?
Hova? És hol kapcsolod ki? És egyébként a kikapcsolás az nem véletlen valami lockdown jellegű státuszt jelent allow-all helyett?
Szóval összességében: megy egyáltalán bármi belső háló -> belső háló irányban? A kliensek egyáltalán hogyan csatlakoznak fizikailag? WLAN? Kábel? Van valami switch vagy egyéb eszköz? Hogyan kapnak címet?
Elsőre azt mondtam volna, hogy nézz rá tcpdumppal a kapcsolat két végére, de végigolvasva nem tiszta, hogy mi is történik a konfigodban...
Sagem kintről
- xxxx portról 22-re TCP, a 192.168.0.18-ashoz. OK, megy.
- xxxx+1 portról 22-re TCP, a 192.168.0.17-eshez. OK, megy.
- YYYY portról 1194-re UDP a VPN-hez. ...0.18, OK, megy.
- ZZZZ portról 1660-ra TCP a torrent webes eléréséhez ...0.18, OK, megy.
Külső webcímről (Zs.....myftp.org) mindig minden beállított dolgot elérek, akkor is, ha éppen bentről nem.
Mindhárom gépen ufw tűzfal konfigurálva. Lehet ez a baj? Jobb volt az iptables? ufw disable, restart, ufw enable, restart volt.
Status: active
To Action From
-- ------ ----
[ 1] Transmission ALLOW IN Anywhere
[ 2] 9091/tcp ALLOW IN Anywhere
[ 3] 1194/udp ALLOW IN Anywhere
[ 4] 9090/tcp ALLOW IN Anywhere
[ 5] 8080/tcp ALLOW IN Anywhere
[ 6] OpenSSH ALLOW IN Anywhere
[ 7] Transmission (v6) ALLOW IN Anywhere (v6)
[ 8] 9091/tcp (v6) ALLOW IN Anywhere (v6)
[ 9] 1194/udp (v6) ALLOW IN Anywhere (v6)
[10] 9090/tcp (v6) ALLOW IN Anywhere (v6)
[11] 8080/tcp (v6) ALLOW IN Anywhere (v6)
[12] OpenSSH (v6) ALLOW IN Anywhere (v6)
hosts (192.168.0.18, Debian 10.3):
127.0.0.1 localhost
127.0.1.1 box.home box
192.168.0.47 Sanati-Asus
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
hosts (192.168.0.47, Mint 19.3):
127.0.0.1 localhost
127.0.1.1 Sanati-Asus
192.168.0.18 box
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Valami varázslat van, mert éppen - miközben kiírogattam és újból újraindítgattam - most minden elérhető bentről is :-O
Hát, a kérdések felét annyira nem sikerült megválaszolni :)
Az attól függ, melyiket tudod használni :) Az ufwt nem ismerem, de a manja alapján kikapcsolt állapotban valami default deny policy van.
Én egyrészt felvenném a logleveljét, másrészt simán ránéznék az elérhetetlen gépen tcpdumppal. hogy megjönnek-e a csomagok amikor valami más próbál kapcsolódni.
Ha igen, akkor a tűzfalat nézném, ha nem, akkor a routert.
(Esetleg extrém hülye esetben ha az output láncon is szűrsz, akkor a kimenő gépről is nézném, hogy egyáltalán ki tud-e menni a csomag)
Szóval összességében: megy egyáltalán bármi belső háló -> belső háló irányban? - Nem.
A kliensek egyáltalán hogyan csatlakoznak fizikailag? WLAN? Kábel? - Vegyesen, kábelen, 2,4GHz-es és 5GHz-es Wifin.
Van valami switch vagy egyéb eszköz? Hogyan kapnak címet? - Van egy 8 portos 1GB-es switch és a szolgáltatói router ad dhcp-t. Az IPTV-s mediabox van a router egyik portján, másik hármon 2 fali végpont és 1 switch. A switchbe megy még 1-2 fali végpont és a többi kliens közvetlenül.
Akkor a log / tcpdump nézést két olyan gép között nézd meg, ami a switchre csatlakozik.
Illetve nézz egy
és a biztonság kedvéért egy
, hogy nehogy valami elkefélt maszk miatt a default gw irányába menjen.
Köszi, a tcpdump-ot érdemes volt megismerni, ebben még gyakorlatot kell szerezzek.
$ sudo tcpdump host sanapi
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:34:13.320088 ARP, Request who-has 192.168.0.18 tell sanapi, length 46
18:34:13.320164 ARP, Reply 192.168.0.18 is-at 1c:1b:0d:21:29:9c (oui Unknown), length 28
18:34:13.320539 IP sanapi > 192.168.0.18: ICMP echo request, id 3292, seq 1, length 64
Pingeltem néhányat...
$ sudo iptables -L -n -v
Chain INPUT (policy DROP 278 packets, 12568 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- enp3s0 * 0.0.0.0/0 0.0.0.0/0
.........
Chain ufw-user-limit-accept (0 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
$ sudo ip r get 192.168.0.22
192.168.0.22 dev enp3s0 src 192.168.0.18 uid 0
cache
És ami előtte történt:
Folyamatosan pingeltem Wifis gépről:
- egy routerre dugott gépet
- és egy switchre dugott gépet
és egyszer csak lehalt a ping! Ezután kihúztam a switch tápját és vissza: MINDKÉT PING VISSZAJÖTT!
Ne wifi-s gépről pingelj! Próbálj meg a switchre dugott két gép között pingelni! Aztán írd le, hogy ha ez mindig működött, ha pedig nem, akkor tcpdumpot a hibás működés beállásáról..
Látom, hogy próbálkozol, de ne rángass egyszerre nyolc dolgot, mert sose jövünk rá, hol van a baj.
Először is, minden olyan gépet, ami wifin lóg, vagy a routerre van dugva felejts el egy pillanatra. A két teszt eszköz legyen a switchen. Így ki lehet zárni, hogy a sagem kever be valami obskúrus hülyeséggel (kivéve, ha még a routeok is el vannak cseszve, de az az ip r alapján talán nincs).
Másodszor is, próbáld meg átadni, hogy mit csináltál, és akkor éppen mi történt, mert így lehetetlen követni. Nem tudjuk, melyik gépen futott a tcp dump, nem tudjuk, az iptableskor ki volt-e kapcsolva a tűzfal, ilyesmi. Az sem segít, hogy szelektálva copypasztázod mondjuk a tűzfal konfig tartalmát.
Alapvetően azt kellene megnézni, hogy mikor nem megy, akkor hol akad el. A folyamat kb a következő, mikor kiadod a ping parancsot
(Kicsit bonyibb, mert nem biztos, hogy van arp, illetve simán lehet egy az icmp request és reply között, ha a szerver nem tudja épp a kliens mac címét)
Mindkét csomag a következő útvonalat járja kb be ("kissé" leegyszerűsítve a dolgot):
Kb a következőt lehet tudni:
Nekem az az érzésem, hogy az ufw disable meg reset nem azt jelenti, amit gondolsz, hanem egy alap, elég restiktív szabályrendszert. A durván lecsupaszított iptables default DROPjából az inputon én erre következtetnék, főleg, hogy ha jól értem, a tcpdump a szerveren készült, ahova a csomag még bejött, ki meg már nem ment, szóval valahol a 6-10 pont között halálozott el, az meg kreténül elbaszott routingot leszámítva a tűzfal. Szóval olvasd el annak az izének a manját.
Köszönöm az eddigi segítséget. Tehát a következőt tettem és most várok:
1. Mint_9.3/IP39 gép beállítása fix IP-re:
sudo ifconfig enp7s0 192.168.0.39 netmask 255.255.255.0 broadcast 192.168.0.255
2. Raspi_10.0/IP22 gép beállítása fix IP-re:
sudo ifconfig eth0 192.168.0.22 netmask 255.255.255.0 broadcast 192.168.0.255
3. Összekötés csak switch-el
4. IP39-en: sudo iptables -L -n -v
[sudo] sxxx jelszava:
Chain INPUT (policy DROP 66 packets, 2376 bytes)
pkts bytes target prot opt in out source destination
27269 7623K ufw-before-logging-input all -- * * 0.0.0.0/0 0.0.0.0/0
27269 7623K ufw-before-input all -- * * 0.0.0.0/0 0.0.0.0/0
127 11580 ufw-after-input all -- * * 0.0.0.0/0 0.0.0.0/0
66 2376 ufw-after-logging-input all -- * * 0.0.0.0/0 0.0.0.0/0
66 2376 ufw-reject-input all -- * * 0.0.0.0/0 0.0.0.0/0
66 2376 ufw-track-input all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ufw-before-logging-forward all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ufw-before-forward all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ufw-after-forward all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ufw-after-logging-forward all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ufw-reject-forward all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ufw-track-forward all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 54 packets, 3832 bytes)
pkts bytes target prot opt in out source destination
33224 3144K ufw-before-logging-output all -- * * 0.0.0.0/0 0.0.0.0/0
33224 3144K ufw-before-output all -- * * 0.0.0.0/0 0.0.0.0/0
6979 554K ufw-after-output all -- * * 0.0.0.0/0 0.0.0.0/0
6979 554K ufw-after-logging-output all -- * * 0.0.0.0/0 0.0.0.0/0
stb, stb, itt kell valaminek látszódnia?
5. IP22-n: sudo iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
6. IP22-n: sudo ip r get 192.168.0.39
192.168.0.39 dev eth0 src 192.168.0.22 uid 0
cache
7. IP39-en: sudo ip r get 192.168.0.22
192.168.0.22 dev enp7s0 src 192.168.0.39 uid 0
cache
8. IP39-en tcpdump indítása naplózással:
sudo tcpdump -n host 192.168.0.22 > dump
9. IP39-ről IP22 pingelése folyamatosan
10. IP39-ről ssh-val belépés IP22-re, majd onnan pingelés vissza IP39 felé folyamatosan
11. Várunk...
Tehát jó értem hogy a belső hálón nem tudod pingelni egyik gépről a másikat?
Kívüről pedig ne is legyen pingelhető semmi, az teljesen jó.
És hogyan van beállitva az ssh port forward 3 eszközre .. kölső random port>belsö eszköz 22 esére mutat?
Belső hálón hogy kapcsolódnak a gépek kábel, wifi?
A gépek vegyesen vezetékesen, wifin csatlakoznak, de a kiosztott IP-k (legalábbis az ipv4-eket néztem) a fentieknek megfelelőek, a routeren fixálva. A wifi is 2,4GHz és 5Ghz vegyesen, de az IP marad.
"Helyi hálozat" wifi-e? szolgáltatói-e a router?
(láttam már olyan szolgáltatói routert ami isolálta a wifi-s klienseket, és csak bridge mód+másik router volt a megoldás)
Fentebb írtam, hogy szolgáltatói router és 10 perce minden elérhető volt belső hálózaton, de újraindítottam a routert és most megint csak kívülről...
ezekben a szolgáltatói szutykokban szokott lenni esetenként "DoS protection" meg "intelligent firewall" meg ilyen egyéb hülyeségek amiknél nagy esélyed van false positive-ot generálni legitim forgalommal is és akkor van ilyen, hogy hol működik valami hol nem.
Két javaslatom van:
Ha tudod konfigurálni a szolgáltatói eszközt és ragaszkodsz hozzá, akkor nézd meg nincs-e ilyen beállítás valahol és kapcsold ki, vagy vedd fel a kivételek közé a fenti IP-ket.
Ha nem ragaszkodsz a szolgáltatói eszközhöz akkor konfiguráld át bridge módba (ha nem férsz hozzá akkor kérd a szolgáltatót) és tegyél be valami épkézláb routert mögé.
A helyedben kiszűrném a hiba forrását. Először is szedd le a masinákat a routerről és tedd őket switchre.
DHCP client esetén ifconfig segítségével adj a gépeknek statikus IP címet, majd ezután próbálkozz a pingeléssel. Ha látják egymást, akkor a router a ludas.
Amúgy egyszerű és végleges megoldás, ha fogsz egy 5 portos gigabites switchet, arra rákötöd a gépeket (1-4 port), majd a switchet (5. port) rákötöd a routerre.
Egyébként nagyon nem komálom a szolgáltatók által adott routereket. Azokat mindig bridge módba rakom, és bekötök egy openWRT-vel vagy pfSense/OPNsense -vel ellátott eszközt.
Rendben, megpróbálom kiiktatni a routert egy teszt erejéig, beteszek egy sajátot, net nélkül. Erre kicsit várni kell a család hómofiszozása miatt. Meglátjuk mi lesz, addig is lehúztam a hálózatról az iptv eszközt, újraindítottam a gépeket és láss csudát, most megint megy a belső elérés...
Ja igen, hátha az IPTV rész zavar be valahogy, de meglátjuk.
nem feltétlenül kell net nélkül maradnod, elég ha a szoltáltató routerére rátolod a te routered wan portját, arrol meg megy tovább minden belső eszközöd. Dupla nat, nem szép, de tesztelni ok.
Nem kell semmilyen másik router, van egy switch a leírása szerint, azon lógó két gép között pingeljen! Mivel egy subnetben vannak, ezért így a routert el sem éri a csomag.
Egyre inkább úgy tűnik, hogy a szolgáltatói router vacakol! Nemrég cserélték, új, az 1 Gbites szolgáltatás bővítéssel kaptam.
Az előző Sagemcom eszközzel nem volt ilyen problémám. Persze az nem volt alkalmas az 1 gbites sávszélességre.
Az eszközön próbára csak 1 WiFi sávot hagyj bekapcsolva egyszerre: először csak a 2.4 GHz-et, utána csak az 5 GHz-et. Így nézz pingeket!
Arra tippelek, hogy band steering van és olyankor pusztul meg a pinged.
Wireless Client Isolation - nezd meg hogy. a routereden nincs-e bekapcsolva. Ez gyakorlatilag egyenkent szetvalasztja a WIFI klienseket es senki nem tud a masikkal kommikalni. Wifi kavezoba jo kis feature - neked nem annyira.
+1
Meg amit érdemes még megnézni, hogy nincs-e olyan gép ami kábelről meg wifiről is fel van csatlakozva, mert ilyenkor az STP miatt fura dolgok történhetnek (pl. kábeles interfészt használná a gép, de a switch másik oldalt azt letiltotta és wifi felé működne csak).
Bár ez ilyen lépcsőházi bölcsességnek hangzik, de szerintem általános ökölszabály, hogy a lokális hálózatok (akár LAN, akár wifivel vegyesen) kiépítéséhez az ember ne a szolgáltatói eszközökre támaszkodjon, hanem vegyen a céljainak megfelelő olyan routert, amelyik felett teljes kontrollja van.
Igen, így van. Teljesen egyetértek. Ez az 1. probléma és máris azon vagyok, hogy megoldjam saját eszközökkel, pl. már próbáltam beüzemelni a t-plink 1750 ac-s routeremet, de
HIÁBA VAN BRIDGE KAPCSOLÓ A SZOLGÁLTATÓI ROUTEREN webes felületén - bekapcsolom, újraindul és úgy jön vissza, hogy ki van kapcsolva :-O
Egyelőre jobb híján felülvizsgálom a végpontokat, kábeleket, krimpeket, stb. A szolgáltatóval kell konzultáljak a bridge bekapcsolásáról...
Update.
A T szerint nem lehet bridge módba kapcsolni, mert tv csatlakozik hozzá, tehát
Ez így mehet? Milyen módban legyen a TP-linkem?
Ó, a faja kis ipétévé... Akkor marad a dulpla nat, a szop@tói, akarom mondani szolgáltatói dobozra dugd rá a saját routered, wan oldalon szimpla dhcp-vel, lan oldalon a címütközés miatt mondjuk 10.1.1.0/24-et beállítva (lan ip, dhcp tartomány, stb.), a saját eszközöket rakd dhcp-re egyelőre, a wifi-s eszközökből takarítsd ki a trés doboz wifijét, és a sajátot tanítsd meg neki, aztán ennyi. Azaz a saját hálózatban az átcímzést nem úszod meg :-/ (Röviden: a fostalicska iptv miatt szívsz, mint a szibériai fehér farkú torkos borz...)
Tedd AP módba TP-Linket! Ha nincs rajta ilyen, akkor IP címet adj neki a másik router subnetjéből, de DHCP poolján kívül és kapcsold le a DHCP szerver funkciót benne. Aztán dugd össze két router LAN portját. Ennyi. Így el tudod érni felületét később is és nincs dupla NAT.
Viszont tűzfala sincs.
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
De van, ott a szolgáltató routere.
Én arra inkább nem bíznám a dolgaimat, ha lehet, és gondolom a poszt-toló sem :-)
Én nem éreztem ilyen jellegű félelmet a hozzászólásaiból, de egyébként gépeken is van tűzfal, pont azt kapcsolgatta ki/be :)
Az nem az ő tűzfala, és tűzfalak se merném nevezni.
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
A háztartások kb 80%-nak ilyen tűzfala van (mert a szolgáltató eszközét használják). De ha tudsz bármilyen sebezhetőséget a Sagemcom eszközében, ami távolról kihasználható, akkor ne habozz megosztani!
Mellékes, hogy tudunk-e, vagy sem. Lan-t nem hagyunk nyitva a net felé, a szolgáltató végpontja önmagában nem tekinthető biztonságosnak, nem ez a feladata.
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
De pontosan ez a feladata. Konkrétan ha mögé raksz bármilyen eszközt routert/switchet, akkor a szolgáltató nem garantál semmit. Első lépés lesz, hogy kihúzatják veled, ha hibát jelentesz be (mérést se fogadnak el rajta keresztül). IPTV-nél ráadásul elég gyakori, hogy felhasználó például mögé rak egy buta switchet, nincsen ugye tovább QoS, ezért szakadozik a kép. Ki se jönnek, ha elmondod telefonban, hogy mögé tettél csak egy switchet akár. Vagy ha erősködsz vagy nem mondod el, akkor kiszámlázzák utána neked (a kiszállást + munkadíjat). Ha megkérdezed a szolgáltatót, hogy kell-e az eszközük mögé egy routert raknod, akkor inkább lebeszélnek róla és megnyugtatnak hogy biztonságos az eszköz + ajánlanak gépedre vírusirtó+tűzfal megoldást. Ettől csak akkor térnek el, ha hiányuk van ilyen ONT-kből. Például Digi mikor FTTH-n terjeszkedett, akkor nagyon örült ha volt routered, mert volt egy rakás ONT-je router/ap funkció nélkül, míg all-in-one eszköze kevés volt. Mára már más a helyzet. Bridge módot például szolgáltatók utálják, sokszor távoli frissítéssel visszaállítják az ONT-t router módba vagy olyan is előfordult, hogy kilőttek a bridge módot kompletten a szoftverből. Sajnos rengeteg végponton szívok/szívtam ezzel. CGNAT-ról nem is beszélve, meg port szűrésekről.. Inkább túl van biztosítva minden manapság.
Aztak.rva..ez azert nagyon meredek.
Sajnos ez ilyen. És akkor ebben a sz*rfészekben építs ki stabil VPN hálózatokat. Ennek pedig a mobil még ad egy pofont! Minden fel van szerelve, működik már 1 éve, erre a szolgáltató állít valamit és az adott területen megszűnik az LTE, helyette lesz HSUPA. Ami nagyon jót tesz mondjuk a napelempark ~30 kamerájának. Vagy V*d*fone ügy dönt, hogy túl sokat forgalmazol a korlátlan csomagodban, ezért szűrést állít be. Betelefonálsz, hogy menjenek melegebb éghajlatra, erre leveszik a szűrést. Következő hónapban pedig újra aktiválják. Pffff.. Ezért használunk már csak kizárólag T*l*nort (vagy olyan flottát, ami azon van). MR200-ról ne is beszéljünk! Ha belső eszköz csinálja a dinamikus DNS-t, akkor kívülről először fel kell oldanom, majd IP címet:portot beírni a távoli eléréséhez a routernek, mert domain-re hülyeséget válaszol (ha persze előre tudod a címet és beállítod a megfelelő felületén vagy ő frissíti, akkor megy).
A legjobb mikor dupla NAT van, belül BGP-t használok, de ugye külső interfészt nem hirdethetem, mert az szinte mindenütt ugyanaz (192.168.0.0/24 vagy 192.168.1.0/24). Ezért ha konfigurálnom kell a VPN hálózaton valamelyik ilyen szolgáltatói csodát, akkor vagy engedélyezem a hirdetést vagy statikus route-ot állítok be arra az időre. Persze NAT-ról nem megfeledkezve. Továbbá külső eszközök NAT ALG-jai is csodákra képesek, amelyek a lehető leghülyébb hibákat tudják előidézni.
Mint egy rossz vicc, de inkabb sirni tudnek, koszi, hogy megosztottad a tapasztalataidat!
Oké...
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Sziasztok, köszi a sok segítséget!
Internet IP: 192.168.0.99 STATIC választása (mert az A router 11-100-ig osztja a címet)
LAN IP: 10.0.0.1
DHCP igen
Módosítottam a port forwardokat,
pl. transmission 1660-on jön kívülről A routerre, onnan 1660-on megy tovább 192.168.0.99-re és 9091-en megy tovább 10.0.0.184-re
Asszem ennyi. Minden muxik!