Helyi hálózaton linuxos gépek nem látják egymást [MEGOLDVA]

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.

SagemCom szolgáltatói router, port forward beéllítva

Mármint milyen, és hova?

Külső címről a router port forwardjával elérhetők

Mármint nem pingelni, ugye? 

Mindegyiket webcím:port úton elérem

Mi az a webcím, és honnan éred el?

 Ufw van telepítve,  ha kikapcsolom és restart, akkor sem megy...

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 :)

Mindhárom gépen ufw tűzfal konfigurálva. Lehet ez a baj? Jobb volt az iptables? ufw disable, restart, ufw enable, restart volt.

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)

Na jó, megpróbálom a másik felét is:

"SagemCom szolgáltatói router, port forward beállítva" Mármint milyen, és hova? - Sagemcomnál F@st 3890V3, van egy noip-s URL, és szolgáltatásonként/gépenként egy-egy önkényes külső port és egy-egy szabványos belső port. Ez teljesen rendben.

"Külső címről a router port forwardjával elérhetők" - Mármint nem pingelni, ugye? - Persze, kívülről nem pingelhető.

"Mindegyiket webcím:port úton elérem" - Mi az a webcím, és honnan éred el? - Egy NO-IP-s URL, persze az IP-m is eléggé fix. Kintről/bentről azon a webcímen, vagy fix IP-n elérem, amit portforwarddal beállítottam.

 "Ufw van telepítve,  ha kikapcsolom és restart, akkor sem megy... - "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? - Minden gépen aktív az ufw. Elég kényelmesen használható és kikapcsolható:

~$ sudo ufw disable
[sudo] sxxxx jelszava:
Firewall stopped and disabled on system startup

Lehet, hogy nem kikapcsolt, de inaktív. Főleg hogy most reseteltem is:

 ~$ sudo ufw reset
Resetting all rules to installed defaults. This may disrupt existing ssh
connections. Proceed with operation (y|n)? y
Backing up 'user.rules' to '/etc/ufw/user.rules.20200420_141507'
Backing up 'before.rules' to '/etc/ufw/before.rules.20200420_141507'
Backing up 'after.rules' to '/etc/ufw/after.rules.20200420_141507'
Backing up 'user6.rules' to '/etc/ufw/user6.rules.20200420_141507'
Backing up 'before6.rules' to '/etc/ufw/before6.rules.20200420_141507'
Backing up 'after6.rules' to '/etc/ufw/after6.rules.20200420_141507'

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.

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!

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

  1.  Először is végig megy egy arp kérés-válasz a két gép között:
    • ki tudja <kliens-ip> mac címét?
    • <kliens-ip> mac címe <valami>
  2. Aztán megy egy
    • icmp-echo-request és
    • rá válaszul egy icmp-echo-reply

(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):

  1. kliens (ping forrás) routing tábla
  2. kliens tűzfal (tűzfal logolással lehet ellenőrizni, esetleg interface és tűzfalszabály számlálók bámulásával)
  3. kliens kimenő interface (tcpdumppal lehet ellenőrzni)
  4. fizikai réteg (switch)
  5. szerver (ping cél) bejövő interface (tcpdump)
  6. szerver routing
  7. szerver tűzfal (tűzfal log)
  8. szerver program válasz csomagot csinál (ez ping esetében a kernel, de az most kb mindegy), majd a csomag szépen elindul visszafele
  9. szerver routing
  10. szerver tűzfal
  11. szerver interface
  12. fizikai réteg
  13. kliens interface
  14. kliens routing
  15. kliens tűzfal
  16. a ping, amit örül a pongnak

Kb a következőt lehet tudni:

  • Ha már a 3. ponton sem látszik a kimenő csomag, akkor vagy a routing van nagyon elbaszva, vagy a tűzfal output láncon megfogja a csomagot. Valószínűtlen
  • Ha 3. még van, de 5 már nincs, akkor van valami nagy szar a switchel. Vagy beteg, vagy valami MTU baszás esetleg. Ez utóbbi szinte kizárható, error számlálókat érdemes nézni.
  • Ha 7-ig nem jutunk el, akkor valami a szerver routingjában szar, valószínűtlen
  • Normál esetben lehetne nézni, hogy van-e log az appban, de ez itt kernel, szóval sajna nem nagyon fog menni
  • Szóval legközelebb az látszik, hogy a válaszüzenet átment-e a tűzfalon, akár az input láncon el tud akadni a bejövő csomag (7.), akár az outputon a válasz (10.)
  • Ha a 11en még látszik a reply, akkor ezeken túl vagy
  • Ha ezek után a 13. nem látja, akkor megintcsak switch para
  • Ha igen, akkor jó eséllyel az utolsó dolog valami bejövő tűzfal elbaszás

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?

"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é.

Szerkesztve: 2020. 04. 20., h - 11:57

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.

Szerkesztve: 2020. 04. 20., h - 11:45

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.

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.

  1. Megcsináltam a fenti javaslat szerinti tesztet 2 CSAK a SWITCHRE csatlakozó géppel és minden rendben volt. Azok a gépek rendben látták egymást órákon keresztül.
  2. Ha visszadugom a switchet a ROUTERRE, akkor a switchre dugott gépek esetén továbbra is minden rendben.
  3. Ha WIFIN próbálom elérni a vezetékesen csatlakoztatott gépeket, akkor vagy van kapcsolat, vagy nem, pedig mindkét wifi sáv és a vezetékes eszközök is DHCP-n kapnak címet, mind a 192.168.0.0/24 tartományban.

Az előző Sagemcom eszközzel nem volt ilyen problémám. Persze az nem volt alkalmas az 1 gbites sávszélességre.

+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

  1. akkor lekapcsolom a wifijét, azt majd a saját router adja,
  2. DHCP-je oszt majd címet a routeremnek,
  3. és a routeremre csatlakoztatott egyébb gépeknek,
  4. egyedül az IPTV vevők mennek a szolgáltatói routerre

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.

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.

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.

Sziasztok, köszi a sok segítséget!

  1. Átnéztem a végpontokat, kábeleket. (Patchpanelt raktam be a router felőli oldalon, ahol eddig krimpelt fali kábelvég volt.)
  2. Beüzemeltem egy TP-LINK (B) routert a szolgáltatói SAGEMCOM (A) után.
  3. Beállítottam a B routert
    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
  4. Lekapcsoltam A router WIFI-jét, ugyanazokat beállítottam B-n és
    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
  5. Egy gyanús kábelt cseréltem az egyik gép és a router között
  6. Minden eszközömet és a switchet a B routerre dugtam, az IPTV vevőt pedig az A routerre

Asszem ennyi. Minden muxik!