Használd inkább a wireguardot! Az bármelyik UDP porton lehet, és akkor knock sem feltétlenül kell. Eleve nem tudják melyik porton van, és azt sem, hogy azon a porton éppen wireguard van. A kulcsok jó hosszúak, és csak nyilvános kulcsot kell cserélni hozzá. Ha a hackernek van egy szuperszámítógép-hálózata, meg sok éve próbálkozni - hát sok sikert hozzá. Ha nincs hátsó ajtó a wireguard kódjában, (nyílt forráskódú, és a kód is rövid - tehát nagy eséllyel kiszúrnák a fejlesztők) akkor nem igazán van realitása a feltörésének.

[ Szerkesztve ]

Jó-jó, de l2tp kb. bármiben van, Wireguard meg még Mikrotikre is "alig"...

Hat, de mi minden lehet az amiben nem fordul elo wireguard? Mobiltelo, linux, windows tudja, max egy progi/app kell, mi kellhet meg?

[ Szerkesztve ]

Wireguard is van kb. mindenre. Mikrotikre, Androidra, Mac-re, Linuxra, Windowsra... Azért is tettem be a képet, mert egy viszonylag régi mikrotikre (RB951) is felraktam a 7-es routerOs-t, és probléma nélkül működik. Némelyik szolgáltató előszeretettel blokkol olyan portokat amin PPTP vagy éppen L2TP működik (persze letagadják) de olyan VPN-t nehéz blokkolni amelyik bármelyik porton működhet.
Ha pedig saccolnom kellene, előfordulhat, hogy az újabb oprendszerekben alapból lesz wireguard is.
Ráadásul a wireguard még ezen az RB951-esen is gyorsabb mint az L2TP vagy mint a PPTP...

[ Szerkesztve ]

Meg RB450G-n is elmegy nekem a ROs 7, pedig az aztan olyan osi, mint madonna csocse.

[ Szerkesztve ]

Számomra a "benne van" azt jelenti, hogy nem kell külön telepíteni. Ebből a szempontból a Wireguard még le van amradva.

Nyilván nem kötelező használni, csak azért írtam mert igen jó alternatíva. A telepítő sem nagy, és a feltelepített program sem.

Azon kívül én már jártam úgy, hogy az otthoni VPN-t szerettem volna távolról elérni egy PC-ről, (kellett volna egy file a NAS-ról) de valami miatt (talán a helyi tűzfal, vagy nemtudommi miatt) sem a PPTP, sem pedig az L2TP nem működött. A wireguard viszont igen...

Sebesség: nem mérvadó, nagyon saját teszt, de nálam a wireguard 2-2.5-szer gyorsabb volt mint az l2tp/ipsec kapcsolat. Azért ez már számít.

Igen, mert ez attól is függ milyen eszközön fut. De kb mindenhol gyorsabb, csak abban van különbség, hogy mennyivel...

De az eredeti kérdéssel kapcsolatban: mehet akár párhuzamosan is a többféle VPN megoldás. L2TP+ipsec kopogtatással, és mellette wireguard is ,egy véletlenszerűen kiválasztott porton.

Nem a wg van lemaradva, hanem a windows Ha olyan protokollt szeretnel, ami mindenben benne van, az csak annyit jelent, hogy csak regieket tudsz hasznalni, amik mar elavulofelben vannak.

"Eleve nem tudják melyik porton van, és azt sem, hogy azon a porton éppen wireguard van."

Szerintem ezt nem lehet gond kideríteni, ha valaki akarja. Egyébként pedig ne alapozzunk a security through obscurity-ra.

A wireguard sebességben nagyon jó, nekem a fő gondom vele, hogy a kliensek nem nyújtanak jelszó vagy más védelmet a kulcsokra. Tehát ha elveszted/ellopják a mobilod amin beállított kliens van az elég kellemetlen lehet.
Ha erre valaki tud ajánlást, azt megköszönném.

Jelszo a telefonra es flash titkositas. Amugy meg sose bizz meg a telefonodban.

[ Szerkesztve ]

Azt azért tudni érdemes, hogy általában a kliens eszközöd a gyenge láncszem. Hiába van 10 dBi nyereséged, és még "hallod", amit a kliens oszt, de vissza már nem tudsz kommunikálni, mert azon egészen biztosan nem irányított az antenna, az adóteljesítmény meg az antennával együtt maximalizált. Ergo nincs kapcsolat valójában a kettő között.
Arról nem is beszélve, hogy neked a kliens felé küldött adat (letöltés!) általában nagyobb teher.

Ezek az eszközök nem véletlenül PtP kapcsolatokra vannak kihegyezve, amikor kettő ilyen áll egymással szemben. Illetve LTE kapcsolat, ahol a nyereséged a letöltésnél manifesztálódik, mert ez az eszköz a kliens.

[ Szerkesztve ]

Tegnap még működött...

>Szerintem ezt nem lehet gond kideríteni,...
Rendben, az itthoni IP címem 84.236.99.186 és jelenleg 6 különböző porton is működik wireguard. Melyek ezek a portok?

>....ha elveszted/ellopják a mobilod amin beállított kliens van az elég kellemetlen lehet. Ha erre valaki tud ajánlást, azt megköszönném....
Persze, a szerver oldalon egyszerűen letiltod/törlöd azt a klienst, illetve a hozzá tartozó publikus kulcsot... Vagy éppenséggel nem törlöd, csak a hozzáférési jogokat változtatod meg, és pont ezen át deríted fel, hogy hol van a telefonod....

[ Szerkesztve ]

Hat, az biztos, hogy az 53-as portod nyitva es kiszolgalja a DNS lookup kerest, szoval fel lehet dos-ra hasznalni.

[ Szerkesztve ]

Nincs nyitva az 53-as portom. Ezen kívül az 53-as portja jövő csomagok forráscíme automatikusan megy a feketelistára, onnantól pedig az adott forráscím számára semmilyen port nincs nyitva. Egyetlen kivétel lehet: ha fent vagy a fehérlistámon, de azon csak 3db cím van - tehát ahhoz ismernünk kellene egymást...
Tehát pl. a 80-as és a 443-as port nyitva van. De ha megnézed, hogy az 53-as, vagy éppen a 21-es port nyitva van-e, onnantól pl. már a 80-as is zárva lesz.

[ Szerkesztve ]

Jah varjal, sajat csapdamba estem Az en routerem elfog mindent, ami 53-as udp portot celoz meg a neten es atiranyitja sajat magara, igy nem engedi a custom dns szerver hasznalatot a halon.

[ Szerkesztve ]

Ez jó ötlet, egy sima NAT szabállyal oldottad meg?

Aha, sima DSTNAT.

chain=dstnat action=dst-nat to-addresses=10.0.0.254 to-ports=53 protocol=udp dst-address=!10.0.0.254 src-address-list=!router_addresses dst-port=53 log=no log-prefix=

Illetve van egy ugyanilyen tcp-re is.

[ Szerkesztve ]

Köszi, ezzel nagyjából tisztában vagyok, csak nem tudom, hogy a gyakorlatban mégis mit jelentene pl. a fenti két AP esetében, mert tapasztalatom nincs ilyen irányított eszközzel.

Szerintem marad a Mikrotik wAP RBwAP2nD első körben, aztán majd meglátjuk. 14k-ért nem egy nagy beruházás, meg olyan nagyon sokat se várok tőle, csak, hogy mobilon legyen valamilyen net az teraszon/udvaron.

"Mindent azért kell tudni mert kérdezik, nem azért mert hasznos."

A "redirect" nem erre való?
Persze így is működhet 😁

"Ezen kívül az 53-as portja jövő csomagok forráscíme automatikusan megy a feketelistára, onnantól pedig az adott forráscím számára semmilyen port nincs nyitva"
Erre (is) mondták nekem pár éve, vagy olvastam, passz, hogy publikus IP-n port szkennelést 1024 felett kell(ene) kezdeni 😁
Persze nem tudom mennyire műxik a dolog.

[ Szerkesztve ]

Az lehet, de nekem gyakorlati tapasztalat alapján jött ez. Azokat a portokat , amelyeket szeretnek hackelni, felvettem tűzfal szabályba, ami küldi feketelistása a forráscímet. Ez eddig elég hatékony megoldásnak bizonyult. Természetesen port szkennelésre is van felvéve szabály, de ennek nagyon ritkán van dolga. Az 1024 alatti portoknak általában adott funkciója van, ezért ezek esetleg "kívánatosabbak" egy hacker számára.
Gondolj bele, mondjuk nyitva van a 38417-es portom - na és mire mész vele? Ha én tudom , hogy FTP van mögötte, vagy éppen webszerver, akkor tudom használni, de más csak próbálgatni tudja, hogy mi lehet az... viszont 3 próbálkozás után megy feketelistára az IP ...

[ Szerkesztve ]

De, de minek toltson prociidot, hogy kivalassza az uj dst ip cimet, ha en is meg tudom adni. Ez inkabb akkor erdekes, ha tobb tartomanyt akarsz lefedni egy szaballyal.
No nem mintha nem lenne eleg tartalek a routeremben.

rOS7-ben az NTP szerver csak a lokális hálózatot szolgálja ki, vagy bárkit, ha ezt nem tiltom le külön a tűzfalban?

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

A mikrotik / routerOs honnan tudná, hogy mi a lokális hálózat, és mi nem az? Neked kell meghatározni, hogy honnan legyen / ne legyen elérhető. Ugyanaz vonatkozik rá, mint az összes többi szolgáltatásra amit futtat a router.

[ Szerkesztve ]

BÚÉK!

- firewall filter-ben kell-e az untracked ebben a rule-ban?
chain=input action=accept connection-state=established,related,untracked

- firewall filter-ben fekete listába kerülésnél mi lesz a csomaggal? Megy tovább a rule-k közt vagy mivel egyező volt így fekete listázza és ennyi? Ha feketelistázza, akkor vmelyik drop érvényre jut, vagy oda már nem megy, mert action feketelistázás volt?
chain=input action=add-src-to-address-list protocol=tcp psd=21,3s,3,1 address-list=not_in_internet address-list-timeout=1d10m
chain=input action=add-src-to-address-list protocol=tcp src-address=!192.168.0.0/16 address-list=not_in_internet address-list-timeout=6h dst-port=20-1023,8000,8080,8291
chain=input action=add-src-to-address-list protocol=udp src-address=!192.168.0.0/16 address-list=not_in_internet address-list-timeout=6h dst-port=20-122,124-499,501-1023,8000,8080,8291
chain=input action=drop src-address-list=not_in_internet
chain=forward action=drop src-address-list=not_in_internet
chain=input action=drop
chain=forward action=drop

logikus, igazad van. köszi

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

összeraktam az első WireGuard kapcsolatomat, ami egy L2TP/IPSec-et váltott. egyszerűbb, mint gondoltam, tök szuperul működik is.

elsősorban a sebesség érdekelt, de csak a routerekbe beépített BTest-re tudtam támaszkodni (minden máshoz a túloldal segítsége is kellett volna az ottani sajátosságok miatt), ez viszont nálam azt eredményezte, hogy

egyelőre nem kísérleteztem tovább, de nem tudom hová tenni ezt...
hap ac3 az alany, 7.1.1-es rOS-el, a túloldalt hap ac2, szintén rOS7.1.1

[ Szerkesztve ]

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

rc4-el csinalta nekem is, de akkor meg hibas volt a tipusa(ethernet device) es bridge-be is be lehetett rakni. Konkretan kifagyott tole a kernel. Supout-ot gyartsal, abban benne van a kernel log, ugy meg tudod nezni mitol panikol a kernel.

BUEK!

Nem kell, untracked csak ugy lesz egy connection, ha a raw tablaban untrackednek markolod.

Az add-src/dst-to-address-list nem vegez a csomaggal, a kovetkezo szaballyal megy tovabb a tablaban.

[ Szerkesztve ]

Köszi.
Akkor csak a drop/accept action végez a csomaggal?

reject/drop/accept vegez vele, return csak akkor, ha fotablaban van, ekkor a default szabaly szerint, illetve a tarpit is vegez. A tobbi tovabbhalad.

[ Szerkesztve ]

Köszi.
Így már wiki-ben is megtaláltam a tarpit szavad alapján.

BUÉK mindenkinek!

Nem sokkal azután, hogy 7.1-ről 7.1.1-re frissítettem az RB5009-en, nekem is volt egy kernel falióra, nem tudom mi okozta, viszont azóta többször nem jött elő ilyen hiba. Most 10nap uptime-nál tart.
Amúgy minden használatban levő mikrotik eszközömet frissítettem 7.1.1-re: (hAPac, hAPac^2, RB951G, cAPac, RB5009) komolyabb gond egyikkel sem volt. A heti mentést végző scriptet kicsit át kellett írnom, az Os változásai miatt, illetve volt olyan script ami valami jogosultsági marhaság miatt nem akart futni, ezt lemásoltam, és új scriptként felvettem, így már működött (a jogosultság látszólag ugyanaz volt, úgyhogy gyakorlatilag nem tudom mi volt a baja, de végülis most jó).

Összefoglalva nekem zömében jók a tapasztalataim a 7.1.1 Os-el. Az előforduló hibák sem tűntek súlyosnak, a kernelhiba volt a legdurvább, de a gyakorlatban csak annyit jelentett, hogy egyszer újraindult miatta a router. Nyilván ha rendszeresen csinálná, akkor zavarna, de nem fordult elő többször.

[ Szerkesztve ]

7.1-ről 7.1.1-re váltás nálam falióra és mindegy egyéb error nélkül zajlott le. Rb5009, rb4009, wap ac megy kb 9 napja az új softtal probléma nélkül.
...kopp...kop ...kopp😃
Nemtom ki hogy van vele, de én (mint mindig) a fw-t is hozzáfrissítettem az os-hoz.
B.UÉ.K! azaz Bugmentes esztendőt minden routerosolónak és egyéb más rendszert használónak.

Sziasztok!
Van egy mikrotik sxt eszközöm a tetőn egy ***** nagy pózna tetején. Érthető okokból nem férek hozzá könnyen
Tegnap óta feláll a 10/100 link a routeremmel, de a router nem kap tőle IP címet, a routeren a LED-ek csak fixen világítanak. Értelemszerűen az eszközt sem érem el 192.168.88.1 címen. Van még bármi amit megpróbálhatok mielőtt fel kell másznom oda?

Miért vegyem meg, ha 3x annyiért, 3x annyi idő alatt megépíthetem? ´¯`·.¸¸.·´¯`·.¸><(((º>

Mac telnet?

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

BúÉK Mindenkinek!

Szeretném ismét a segítségetek kérni. Valamiért nem hagy nyugodni a dolog. Adott lenne 3 hAP ac2. Az egyik még 256 rammal, ez az úgynevezett fő router. Erre csatlakozik a másik kettő L2TP-n. Szépen működik szinte minden, csak egy valami nem. A fő router felől elérem mind a két külső routert és a mögötte lévő eszközöket. Viszont visszafelé csak a fő routert érem el, és nincs átjárás a két külső router között. Ez kivitelezhető valahogy?

Köszönöm

Honor Magic 6 Pro | Lenovo Thinkpad X280 | Lenovo Thinkcentre M800

a két külső router ip/routes részében fel kell venni a másik külső routernél található hálózatot és beállítani a l2tp interface-t a gatewaynek.

1. külső router:
ip route add dst-address=<a 2. külső router hálózata. pl. 192.168.12.0/24> gateway=<lt2p interface neve a főrouter felé>
2. külső router
ip route add dst-address=<az 1. külső router hálózata. pl. 192.168.33.0/24> gateway=<lt2p interface neve a főrouter felé>

[ Szerkesztve ]

a stabillá nyilvánítás óta használom itthon a 7-est, egy másik helyen pedig valami korai rc óta (nem akart menni a mobilnetes stick 6-ossal, jobb ötletem nem lévén frissítettem a 7-es épp akkor aktuális előzetesére, azzal meg jó volt), és más problémát nem tapasztaltam vele ezen az egy kernel failure-ön, meg a múltkori automata frissítésbe belefagyáson kívül.

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

Ha jól értelmezem akkor így kellene:

1. külső router (13.0.3.1):
ip route add dst-address=<13.0.4.0/24> gateway=<l2tp-out1>

2. külső router (13.0.4.1):
ip route add dst-address=<13.0.3.0/24> gateway=<l2tp-out1>

Honor Magic 6 Pro | Lenovo Thinkpad X280 | Lenovo Thinkcentre M800

Ezt hol is láthatom?

Honor Magic 6 Pro | Lenovo Thinkpad X280 | Lenovo Thinkcentre M800

igen, ilyesmire gondoltam. (a < és > jelekre nincs szükség, vagy winbox-ban az ip/routes résznél is csinálhatod)

sehol, ezt az IPv4 szabvány definiálja.

a 10.0.0.0/8, 192.168.0.0/16 és 172.16.0.0/12 tartományok lehetnek lokális IP címek, amik nem fordulhatnak elő a külső interneten.
a 13.x.x.x nem része ennek, emiatt nem ajánlott helyi hálózaton használni

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

Igen ilyesmi kellene. Gyakorlatilag 4db különböző IP tartománynak kell lennie:
- Fő router
- 1. külső router
- 2. külső router
- VPN címtartománya
(ha wireguard-al oldanád meg akkor 5db IP tartomány kellene, mert a wireguard interfészek tapasztalatom szerint nem működnek jól, ha közös IP tartományban vannak)
- Mindhárom routeren két static routing-ot kell felvenni, (a másik két eszköz felé).
- A VPN címtartományára elvileg létrejön dinamikus routing szabály (de ha nem, vagy ha nem megfelelően akkor az is kell)

- A 13.0.0.0/24 IP tartományok szerintem sem célszerűek belső IP céljára.

[ Szerkesztve ]

Tisztában vagyok vele, hogy nem ajánott az IP tartomány amit használok, viszont 2 éve nincs gondom vele. Amint hiba lesz, változtatok. Csatolok képet a jelenlegi IP/Routes részről:

Fő router (13.0.1.1):

1. külső router (13.0.3.1):

2. külső router (13.0.4.1):

Egyenlőre csak az utolsónál aktív a bejegyzés, de így nem működik.

Honor Magic 6 Pro | Lenovo Thinkpad X280 | Lenovo Thinkcentre M800