Hálózatok általános

Van egy Mikrotik routerem, ami egy bridge módban üzemelő Huawei optikai "modem" mögött van.
Szükségem lenne arra, hogy internet felől elérjek egy belső hálózaton üzemelő webszervert.
Eddig sikertelen a próbálkozásom, a segítségeteket szeretném kérni.

Bár már jelenleg nincsen semmilyen tiltó szabály a Mikrotik tűzfalában, létrehoztam egy "accept"-et a 8443-as portra (ezen fogadnám a külső kapcsolódást és irányítanám majd át a belső hálózaton levő gép 80-as portjára).

Így hoztam létre:
/ip firewall filter
add action=accept chain=input comment="test web" dst-port=8443 in-interface=pppoe-digi protocol=tcp src-port=""

Készítettem hozzá NAT-ot:
/ip firewall nat
add action=dst-nat chain=dstnat comment="test web" dst-port=8443 in-interface=pppoe-digi protocol=tcp src-port="" to-addresses=192.168.1.10 to-ports=80

Bekapcsoltam a cloud-ot:
/ip cloud
set ddns-enabled=yes ddns-update-interval=5m

Az ether1 interfész fogadja az internetet:
/interface pppoe-client
add add-default-route=yes disabled=no interface=ether1 name=pppoe-digi user=digiusernev

A cloud így néz ki:
/ip cloud print
          ddns-enabled: yes
  ddns-update-interval: 5m
           update-time: yes
        public-address: 188.143.xx.xyz
              dns-name: sokszám.sn.mynetname.net
                status: updated
               warning: Router is behind a NAT. Remote connection might not work.

Az Interface -> pppoe-digi "Status" alatt ezt látom:
Local address: 100.67.xyz.xyz
Remote Address: 10.0.0.1
Actice links: 1
Active AC Name: DIGI
stb...

Szóval nem teljesen világos, miért látok más "Public address"-t a Cloud alatt, mint a pppoe-digi interfész státusza alatt?
A cloud azt is jelzi, hogy a router NAT mögött van, ez mennyire lehet biztos?
Annak idején kértem a szolgáltatótól, hogy publikus IP címet adjanak, mert szükségem lehet külső elérésre (akkor az előtt valamilyen privát IP címet adtak, meg is változott publikusra).

A tűzfal acceptjénél és NAT-jánál az "in-interface"-t próbáltam "pppoe-digi"-vel és "ether1"-el is, egyikkel sem ment.

Én csinálok valamit rosszul? Mit? :)
Vagy mi lehet az oka, hogy sem a pppoe-digi interfész "Local address" alatt látszó IP címen, sem a Cloud alatt látszó "Public Address"-en nem érem el a LAN-ban levő webszerverem?

Minden segítséget szívesen veszek és előre is köszönök! :)

Első körben kijelentem, hogy tökéletes tudatlanságban szenvedek vpn téren, sosem kellett, nem is érdekelt igazán, mert nem volt alkalmazás ami megkövetelte volna, most viszont lett :) Azt hiszem ez egy jó kis projekt lesz.

Az alapfelállás: lakhely Németország, végpont Magyarország. A cél a jövő hónapban megjelenő HBO-Max (nem kívánságműsor, nem az én kívánalmam) elérése és esetleg egyéb forgalom (ha már van, miért ne) ami jó lenne ha magyar ip-n látszana.

A jövendőbeli vpn szolgáltató talán a cyberghostvpn lesz (hacsak nincs innen egy jobb ajánalat). A felállás itt: Fritzbox router kissé megnyírbálva. A dhcp és dns (meg még egyebek is) egy másik i686-os linuxos gépről megy, a router csak a portforwardingot és a nat-ot adja. Ide kellene belőnöm egy vpn-t, úgy hogy a helyi kliensek ezen keresztül érhessék el a vpn túloldali végpontját. Az sem lenne baj, ha egyidőben lehetnének gépek amik nem ezen keresztül látnák a külvilágot (vagy akár mindegyiken választható lenne... nem tudom lehet-e ilyet). A kliensek: linux, win, android, okostv (ezek boxok android-tv-vel és/vagy kodival). Szeretném ha a vpn-t a meglévő i686 gép kezelné, de esetleg van erősebb gép is ha ez gyenge lenne.

Merre induljak? Leginkább cli-s magyarázat lenne jó, a gépeim többségén nincs monitor vagy webszerver (bár ez utóbbit ha muszáj, tudok telepíteni). Kissé szájbarágósan lenne jó és jó lenne ha itt tudnék további segítséget kapni ha nem tiszta valami.

Köszönöm!

Sziasztok,

Van valakinek bármi infója hálózati kimaradásról? A vonalak hallgatnak, a szolgáltatások állnak. Mint egy jó western.

Sziasztok!

Létrehoztam egy vpn-t (Windows RRAS), amin keresztül ssh-n rájelentkezek linuxos szerverekre. Működik is a dolog, némi szépséghibával. Az első meglepetés akkor ér, amikor mc-t akarok indítani: üres képernyő fogad, jobb felső sarokban a panel sarka látszik, és ebbe az állapotba bele is fagy.

Az ip a parancs szintén fagy. Ez kiírja a loopback if adatait, a következő if-ből már semmit, megfagy. Az összes Linuxos szerverünk ezt csinálja következetesen. Amikor a régi vpnnel csatlakozok, akkor ezek a hibák nem jelentkeznek. Mi okozhat ilyen hibákat? Logban nem látok hibajelzést.

hello,

ezeregy éve nem foglalkoztam ilyennel és megcsüngtem. 

adott egy ubuntu és egy samba szerver aminek a configja a következő:

GNU nano 5.6.1                                                                                 /etc/samba/smb.conf

[global]

   workgroup = public
   guest account = nobody
   log file = /usr/local/samba/var/log.%m
   max log size = 50
   security = user
   map to guest = bad user
   encrypt passwords = yes

[kozos]
writable = yes
path = /home/username/share
public = yes
guest ok = yes
guest only = yes
guest account = nobody
browsable = yes
create mask = 777

[guest]
        directory mode = 777
        guest only = yes
        path = /home/username
        comment = Server
        public = yes
        create mode = 777
        writeable = yes

na ezzel csak az a gond, hogy a windows amikor csatlakozik a meghajtóra logint kér. mit rontottam el?
 

Van egy tárhelyem a tarhely.eu -n, a foo.hu

Most jönne egy munka bal kézről, ahol kéne egy php-s akármit csinálni, de a megrendelő oldalán, a bar.hu címen.

Probléma, hogy a bar.hu cím tárhelyén csak alkalmazás (wordpress) elérés van, ftp/ssh nincs.

Megoldás: fel kell venni a bar.hu -t kiszolgáló DNS -ben, hogy a progi.bar.hu az a foo.hu IP címén van, a tarhely.eu -nál pedig be kell állítanom, hogy a progi.bar.hu aldomain az melyik könyvtárban leledzik.

Jól gondolom? Ilyet még nem csináltam, ezért nem tudom, hogy a fejemben lévő elmélet hol csúszik el a valóság banánhéján.

Sziasztok,

Lehet nagyon "amatőr" lesz a kérdés, de megpukkadok tőle :)

Adott egy AWS EC2-ben felállított OpenVPN szerver, publikus IPv4 címmel. Szeretném, hogy erről a publikus IPv4 címről beengedje a forgalmat egy Cloudfrontra kötött WebACL. Ez irodában tök jól működött, VPN-re felkapcsolódva átengedett a WebACL, lekapcsolódva 403-at kaptam.

De aztán hazaértem. Itthon felkapcsolódva a VPN szerverre, továbbra is 403-at dobál a WebACL. Mi lehet a gond, hogyan érdemes ezt a problémád megközelíteni?

Itthonról dolgozunk. A munkaidőnk egy számottevő részében MS Teams és Google Meet videohívásokban beszélünk emberekkel, képernyőt osztunk meg, az ő megosztott képernyőjüket figyeljük, stb.

Időnként a hívás megszakad, vagy minden videó befagy, hang megszakad, esetleg csak bekockásodik és közben a program kiírja, hogy gyenge a hálózati kapcsolatom.

Igazából nem tudom, hogy mi okozza. Nem valószínű, hogy a WiFi jelerősség, mert a WiFi routertől nem vagyok messze. De korábban rendszeresen problémák voltak a szolgáltatóm upstream kapcsolatával, ami miatt a routerem rendszeresen leszakadt az internetről és rebootolt magától. Ezt a rebootot nem szokta csinálni már hónapok óta, de ettől még nem bízom meg se a routerben se az upstream kapcsolatban teljesen. Persze lehet, hogy az én szolgáltatómnál és az itthoni rendszerben minden jó, és valahol máshol van a gond, de arra  úgysincs ráhatásom (és ebben az esetben a tervezett fejlesztés az égvilágon semmi haszonnal nem jár).

Arra gondoltam, hogy egy másik szolgáltatótól ha lenne egy állandó kapcsolatom (pl. egy 4G vagy 5G mobilnetes USB-s eszközön át), akkor a normál szolgáltatóm esetleges hibázása esetén átvehetné a mobilnet a forgalmat.

Nagyon régen, kb. 15 éve foglalkoztam ilyesmivel (routing, failover, QoS) utoljára. Biztos most is össze tudnék rakni egy rendszert, de el kellene vele töltenem jelentős időt (kutatás, olvasás, próbálkozás) és az elképzelt megoldáshoz extra hardvereket is be kellene szereznem.

Ez mind nem gond, ha a végén működik a megoldás. De nem tudom, hogy működik-e. 15 éve nem videotelefonáltunk. Az akkor összerakott megoldásnak ezt nem kellett tudnia.

Szóval azt szeretném megtudni, hogy van-e ilyennel tapasztalata az egybegyűlteknek! Ha fut egy MS Teams vagy Google Meet videohívás és két különböző csatornán kapcsolódik a hálózatom az internethez, mennyire okoz akadást az, ha az egyik vagy a másik csatorna kiesik?

Azt szeretném, hogy ne okozzon semmi akadást. Beszélünk, kihúzom az egyik drótot, reccenés nélkül megy tovább. Visszadugom, kihúzom a másodikat, reccenés nélkül megy tovább.

Ha kihúzom az egyiket, és erre megakad a videotelefonálás, kiírja, hogy valami gond van, majd pár másodperc után (a másik útvonalon) folytatódik a hívás, az nekem nem jó. Ha ennél nem lehet jobbra megcsinálni, akkor bele se kezdek. Se az időmet, se a pénzemet nem akarom egy olyan megoldásra pazarolni, ami nem javít jelentősen a mostani helyzeten.

Lehet, hogy sokan tudjátok, én ma jöttem rá véletlenül, hogy van remote tab autocompletion, tehát a távoli oldalon lévő fájlokat-könyvtárakat kiegészíti a parancssorban... :D

Adott egy több gépes Kubernetes cluster, amin engednem kellene egymás között a korlátlan beszélgetést, amit a Calico kezelne ugye:

6: vxlan.calico: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default
   link/ether 66:27:cf:7e:04:57 brd ff:ff:ff:ff:ff:ff
   inet 192.168.192.192/32 scope global vxlan.calico
      valid_lft forever preferred_lft forever
   inet6 fe80::6427:cfff:fe7e:457/64 scope link
      valid_lft forever preferred_lft forever
7: caliadcbd3f4089@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default
   link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 0
   inet6 fe80::ecee:eeff:feee:eeee/64 scope link
      valid_lft forever preferred_lft forever
15: calie01777fb239@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default
   link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 1
   inet6 fe80::ecee:eeff:feee:eeee/64 scope link
      valid_lft forever preferred_lft forever

Elvileg hozzáadtam a tűzfalhoz a 192.168.0.0/16 tartomány engedését, külön zónába, amihez hozzáadtam a vxlan.calico interfészt:

work (active)
   target: default
   icmp-block-inversion: no
   interfaces: vxlan.calico
   sources:
   services: cockpit dhcpv6-client ssh
   ports:
   protocols:
   forward: no
   masquerade: no
   forward-ports:
   source-ports:
   icmp-blocks:
   rich rules:
      rule family="ipv4" source address="192.168.0.0/16" accept

Valamit elbaszok, mert eldobja a `cali*` interfész forgalmát:

[Mon Jan 3 19:40:59 2022] FINAL_REJECT: IN=vxlan.calico OUT=cali36ee08b4230 SRC=192.168.84.64 DST=192.168.186.2 ...
[Mon Jan 3 19:40:59 2022] FINAL_REJECT: IN=vxlan.calico OUT=calie69163f08b8 SRC=192.168.192.192 DST=192.168.186.1 ...
[Mon Jan 3 19:41:00 2022] FINAL_REJECT: IN=vxlan.calico OUT=calie69163f08b8 SRC=192.168.84.64 DST=192.168.186.1 ...

Mi az, ami felett átsiklottam?