Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: Ondřej Severa 14. 08. 2023, 23:16:52
-
Hezký den všem, obracím se na toho odborné fórum, protože věřím, že mě někdo z vás dokáže nasměrovat.
Mám následující zadaní:
V naší chatové oblasti máme ostrovní solární systémy. Soused má k dispozici internet od O2 a domluvili jsme se, že jej mohu také užívat. Tudíž mám přístup na jeho Wifi, ale AP nemám šanci konfigurovat. Jelikož chci mít možnost vzdáleného monitorování po celou dobu nezávisle na chodu sousedovo AP pořídil jsem si MikroTik RouterBOARD RBwAPR-2nD with R11e-LTE, wAP LTE Kit, ROS L4 včetně SIM s omezeným množstvím dat. (RouterOS 7.10.2 Stable)
Potřeboval bych poradit či nasměrovat jak:
- Připojit svůj Mikrotik jako clienta k sousedovu AP (DHCP client)
- Jak zajistit, že v případě výpadku sousedovi wifi pojedu přes LTE
- Jak z Mikrotiku začít svítit svoji Wifi s vlastním SSID a NATem (vlastní DHCP server, NAT, bridge s etehernetovým portem)
- Kam do toho všeho umístit Wireguard clienta, pomocí kterého se dostanu do svojí sítě. (Mám veřejnou IP a nakonfigurovaný wireguard s PC a mobilem)
Koukal jsem na několik návodu ohledně wireless station, station pseudobridge, ale nedaří se mi zařízení uspokojivě nastavit. Bohužel jsem síťař začátečník, tak zkouším hledat pomoc na internetu. Konfiguraci routeru sdílet nechci, protože si nejsem jistý v žádném z uvedených bodů.
Díky moc
-
Jestli správně chápu, Váš Mikrotik v tuhle chvíli bridguje Vaši LAN k sousedově LAN. Tzn. soused Vám dává DHCP.
Pokud chcete mít failover k sousedovi vs. do LTE, potřebujete si DHCP servírovat sám, nezávisle na upstream konektivitě (jak jste zjevně správně odvodil). Tzn. potřebujete svého Mikrotika překonfigurovat, aby nebridgoval z uplinku od souseda, ale aby si jenom vzal na upstream rozhraní IP adresu přes DHCP, a do Vaší LAN provoz forwardoval na 3.vrstvě skrz svůj vlastní NAT. Tzn. řekl bych skoro základní konfigurace :-) tzn. router kde WAN = WiFi client.
No a pak můžete pogooglit nějaký skript, který bude hlídat primární konektivitu (pingem?), a pokud tato padne, nahodí záložní uplink = LTE.
Na tomtéž routeru může sedět taky wireguard client.
Pokud chcete být jedním směrem WiFi klient a druhým směrem (jiný subnet) WiFi AP, potřebujete podle mého dvě nezávislá rádia. Pokud má Váš mikrotik simultánní dual-band s oddělenými anténami pro obě pásma, tak to vlastně jsou dvě rádia = šlo by svítit každým směrem v jiném pásmu. Nebo řešíte v rovině mechanické skladebnosti, jak nacpat do routerboardu přídavné rádio a zároveň LTE.
Omlouvám se za povrchní odpověď, ohledně mikrotiku jsem lama.
-
Podle mých informací Mikrotik umí na jednom rádiu provozovat jak clienta, tak AP viz https://wiki.mikrotik.com/wiki/Manual:Wireless_Station_Modes
To se mi dokonce s pomocí tutoriálu (https://www.youtube.com/watch?v=Ifsb3viu-OM) povedlo rozchodit.
Nicméně nevím jak se odříznout od "souseda-poskytovatele" a jak správně nastavit routování a bridge abych měl "svoji" síť za NATem s DHCP serverem a tunelem pomocí Wireguardu.
Bohužel jsem začátečník jak v sítích tak konfiguraci Mtiků.
-
Tak to zkuste trochu poštudovat. Není to zase tak složité. Hm. Nějak marně googlím hezký výstižný obrázek... něco jsem Vám v rychlosti načmáral, viz příloha.
Druhá vrstva jede podle MAC adres, aktivním prvkům v této vrstvě se říká switch nebo bridge. V dnešní době se s pojmem bridge často setkáte ve smyslu "softwarový bridge" v nějaké chytré krabičce. Jinak ale chytré krabičky mívají taky konfigurovatelný HW Eth switch, kde si můžete shlukovat porty do "virtuálních LAN". Různé VLANy na sebe na L2 navzájem nevidí, přestože jedou skrz tentýž fyzický switch.
Bohužel Wifi je jiný čip na motherboardu a má interně rozhraní PCI-e, takže přestože pracuje s ethernetovými rámci, musí se na metalický ethernet bridgovat softwarově (nebo samozřejmě routovat na L3).
Třetí vrstva jede podle IP adres, aktivním prvkům se říká router. Na třetí vrstvě řešíte subnety, které Vám vespod nejspíš budou pasovat na vykolíkované L2 sítě. (Nebudu Vás trápit virtualizací = VRF, network namespaces, VM.)
Pokud máte uvnitř Mikrotiku definováno více L2 VLAN nebo soft-bridgů, můžete a nemusíte do každé(ho) z nich vidět L3 rozhraním. L3 rozhraní do VLANy či bridge je potřeba k forwardování provozu na L3, a taky na něm lze povolit přístup na management RouterOS. Obvykle se management povoluje z LAN nebo z dedicated managementové sítě/portu. Něco k VLANám (http://support.fccps.cz/download/adv/frr/VLAN/vlan.html)...
Jak to uklikat v Mikrotiku?
Zazálohujte si konfiguraci, která Vám momentálně funguje.
Pak bude možná nejjednodušší, smazat konfiguraci a začít z čisté vody. Z "quick-set šablon" bych jako výchozí bod volil buď AP nebo CPE - ale nejspíš to v té šabloně nedáte celé. Určitě režim router, a dál jde o to, přiřadit mu správně rozhraní do zón WAN (https://forum.mikrotik.com/viewtopic.php?t=171313#p837831) a LAN. Na straně LAN bych vytvořil "bridge", do kterého bych naházel kýžené metalické porty a WIFI ESSID, ve kterém box bude v roli "mastera" (AP). Do zóny WAN je potřeba přiřadit WIFI ESSID, ve kterém se má box chovat jako client.
Do soft-bridge v Mikrotiku a OpenWRT se dají přiřazovat rozhraní, která jsou typu Ethernet a příbuzná - vedle fyzických Eth portů také VLANy, pojmenované instance Wifi sítí (ESSID), OpenVPN TAP apod.
-
Díky za tipy. Dneska se k tomu nedostanu, ale zítra vyzkouším. Jsem na to sám zvědavý.
-
@František Ryšánek Děkuji moc za nasměrování!
Postupoval jsem následovně:
1. Reset MTiku do defaultního nastavení
2. Quick Setup na CPE - tím jsem se připojil na Wifi
3. Změna wifi interfacu na "station"
4. Vytvoření virtuálního interface na wlan - svítím svoje AP
5. Nastavení LTE routeru - nicméně trafic mi jede přes wlan (zatím nemám nastavený ten backup)
6. Nastavení wireguardu pomocí https://www.youtube.com/watch?v=P6f8Qc4EItc
Všechno vypadá, že jede. Ještě tedy přepínání těch defaultních rout, ale to si nechám na jindy.
-
:-) není zač, "chytrému napověz".
Přeji co nejméně "následných překvapení".
-
S dovolením se vmáčknu s pár komentáři.
- Použití jednoho rádia pro kombinované účely (Station a AP) má své úskalí - Pokud se primární hardwarové rádio v režimu Station nepřipojí k síti (AP), pak ani nevysílá virtuální "rádio" jako AP. Tj. nedokáže-li se připojit k sousedově WiFi nebude ani vysílat svou vlastní WiFi
- Řešení dvou WAN je celkem komplexní záležitost, ale u Vás to naštěstí zjednodušuje fakt, že potřebujete řešit pouze odchozí směr.
Méně sofistikovaně se to dá řešit dvěma výchozími routami, primární bude mít menší distanci než sekundární a na primární routě povolíte Check Gateway. Když se nedopingne na gateway, routa se zneplatní a bude platit sekundární s větší distancí. Toto řešení ale nepostihne výpadek internetu u souseda, zareaguje pouze na výpadek wifi.
Sofistikovanější řešení je použití funkce Netwatch, kde si zvolíte vůči které (veřejné) adrese budete "živost" konektivity ověřovat, způsob (simple - pouhý ping -> dojde/nedojde, icmp - sofistikovanější s procentuální ztrátovostí atd..) a do Up a Down skriptu narvete jednoduché zakázání / povolené záložní routy, případně změnu její distance. Nesmíte zapomenout svázat testovanou IP s primární konektivitou separátní routou.
-
Jak tak koukám, co má OP za rádio, tak přidat druhé wifi rádio dovnitř nejspíš nepůjde a externí USB port to nemá. Takže leda externí AP. Třeba mAP nebo cokoli většího. Asi cesta nejmenších nákladů a odporu.
Poskládat 2x wifi a ještě R11e do jedné desky... možná by to šlo s použitím RB912, strčit druhé WiFi rádio do MiniPCI-e a R11e přes redukci do vnějšího USB portu, pokud se to spolu bude kamarádit. Koukám že Mikrotik asi nic většího nemá, s více MiniPCI-e sloty. Pak už leda něco na bázi x86.
-
Škoda, že pisatel nesáhl po vybavenější wAP AC LTE, protože ta je dual-band / radio a má 2x RJ45 a navíc je výkonnější a s arm cpu, který je (a bude) podporovanější ze strany Mikrotiku.
-
S dovolením se vmáčknu s pár komentáři.
- Řešení dvou WAN je celkem komplexní záležitost, ale u Vás to naštěstí zjednodušuje fakt, že potřebujete řešit pouze odchozí směr.
Méně sofistikovaně se to dá řešit dvěma výchozími routami, primární bude mít menší distanci než sekundární a na primární routě povolíte Check Gateway. Když se nedopingne na gateway, routa se zneplatní a bude platit sekundární s větší distancí. Toto řešení ale nepostihne výpadek internetu u souseda, zareaguje pouze na výpadek wifi.
Sofistikovanější řešení je použití funkce Netwatch, kde si zvolíte vůči které (veřejné) adrese budete "živost" konektivity ověřovat, způsob (simple - pouhý ping -> dojde/nedojde, icmp - sofistikovanější s procentuální ztrátovostí atd..) a do Up a Down skriptu narvete jednoduché zakázání / povolené záložní routy, případně změnu její distance. Nesmíte zapomenout svázat testovanou IP s primární konektivitou separátní routou.
Jde to i bez netwatch přes rekurzivní routu
-
- Použití jednoho rádia pro kombinované účely (Station a AP) má své úskalí - Pokud se primární hardwarové rádio v režimu Station nepřipojí k síti (AP), pak ani nevysílá virtuální "rádio" jako AP. Tj. nedokáže-li se připojit k sousedově WiFi nebude ani vysílat svou vlastní WiFi
Ani když se napevno nastaví kanál na ten co používa to sousedovo AP? To mi přijde jako zvláštní omezení. Jestli by pak nestálo za to tam flashnout OpenWRT.
-
- Použití jednoho rádia pro kombinované účely (Station a AP) má své úskalí - Pokud se primární hardwarové rádio v režimu Station nepřipojí k síti (AP), pak ani nevysílá virtuální "rádio" jako AP. Tj. nedokáže-li se připojit k sousedově WiFi nebude ani vysílat svou vlastní WiFi
Neznám a tak jen spekuluji, ale nedá se to obejít pomocí disable-running-check=yes na wireless master interface? (parametr dostupný pouze z CLI)
-
- Použití jednoho rádia pro kombinované účely (Station a AP) má své úskalí - Pokud se primární hardwarové rádio v režimu Station nepřipojí k síti (AP), pak ani nevysílá virtuální "rádio" jako AP. Tj. nedokáže-li se připojit k sousedově WiFi nebude ani vysílat svou vlastní WiFi
Ani když se napevno nastaví kanál na ten co používa to sousedovo AP? To mi přijde jako zvláštní omezení. Jestli by pak nestálo za to tam flashnout OpenWRT.
Bohužel v režimu Station ignoruje nastavenou frekvenci (dle dokumentace) a vždy hledá zadané SSID.
-
- Použití jednoho rádia pro kombinované účely (Station a AP) má své úskalí - Pokud se primární hardwarové rádio v režimu Station nepřipojí k síti (AP), pak ani nevysílá virtuální "rádio" jako AP. Tj. nedokáže-li se připojit k sousedově WiFi nebude ani vysílat svou vlastní WiFi
Neznám a tak jen spekuluji, ale nedá se to obejít pomocí disable-running-check=yes na wireless master interface? (parametr dostupný pouze z CLI)
Toto jsem nezkoušel, pokud je to vlastnost ROS, pak by to mohlo pomoci. Ale obávám se, že to je prostě vlastnost rádia. Umí pracovat jen na jedné frekvenci - tu, na které se připojí k sousedovu AP. Podle mne se neumí připojit na jedné frekvenci a vysílat vlastní SSID na druhé. Myslím, že parametr disable-running-check slouží spíše pro jiné účely (aby nevypadly routy, DHCP aj. funkce citlivé na aktivní síťové rozhraní).
-
S dovolením se vmáčknu s pár komentáři.
- Řešení dvou WAN je celkem komplexní záležitost, ale u Vás to naštěstí zjednodušuje fakt, že potřebujete řešit pouze odchozí směr.
Méně sofistikovaně se to dá řešit dvěma výchozími routami, primární bude mít menší distanci než sekundární a na primární routě povolíte Check Gateway. Když se nedopingne na gateway, routa se zneplatní a bude platit sekundární s větší distancí. Toto řešení ale nepostihne výpadek internetu u souseda, zareaguje pouze na výpadek wifi.
Sofistikovanější řešení je použití funkce Netwatch, kde si zvolíte vůči které (veřejné) adrese budete "živost" konektivity ověřovat, způsob (simple - pouhý ping -> dojde/nedojde, icmp - sofistikovanější s procentuální ztrátovostí atd..) a do Up a Down skriptu narvete jednoduché zakázání / povolené záložní routy, případně změnu její distance. Nesmíte zapomenout svázat testovanou IP s primární konektivitou separátní routou.
Jde to i bez netwatch přes rekurzivní routu
Zajímavý tip. Vyzkouším. Zajímá mne, jak se to bude chovat s dynamickými IP na WANu.
-
Pokud v tom máš ROS7, tak korektně funguje stav, že fyzický wlan1 dáš jako to APčko (ap bridge) pro svoje věci a nad něj dáš virtual v režimu station a ten napojíš na toho souseda. Tohle šlape OK. Při opačné kombinaci je třeba použít to disable-running-check=no.
Samozřejmě na jednom rádiu AP i klient není úplně ideální stav, ale co už. :-(
Rekurzivní routa je možnost, jak to řešit. Projdi si toto: https://help.mikrotik.com/docs/pages/viewpage.action?pageId=26476608 a pak i toto https://help.mikrotik.com/docs/display/ROS/Firewall+Marking v části Failover With Firewall Marking. Aby jsi to mohl použít, tak toho DHCP klienta si nastav, že na tom wlan nemá nastavovat default routu, tu si nastavíš ručně dle toho výše.
Nicmémě, není to ideální řešení a rozhodně pro spolehlivý chod je potřeba varianta se skriptováním. Jednak ta rekurzivní routa s ping chckem vypadne při prvním ztracením pingu, což nechceš (jde řešit do určité míry použitím víc těch mezihostů). Horší je, že v reálu ti do toho bude kecat NAT a connection tracking. Potřebuješ, aby v okamžiku přepnutí na zálohu, tak aby se vymazala connection/NAT cache. Bez toho ti budou blbnout dlouhodobé UDP spojení, protože to bude držet pořád starý stav a pokud to UDP neustále bude do toho posílat čas od času paket, tak je problém. TCP spojení ti vychcípe a naváže se nové, tohle urychlí to udělání dle Failover With Firewall Marking s tím rejectem při změně odchozí linky. Ale neřeší to UDP. Na to pak asi ten netwatch, kde přepneš routu ručně a zároveň u toho dělaš něco jako: /ip/firewall/connection/remove numbers=[find connection-mark="cm_ISP1" and protocol!="tcp"]
-
Pokud v tom máš ROS7, tak korektně funguje stav, že fyzický wlan1 dáš jako to APčko (ap bridge) pro svoje věci a nad něj dáš virtual v režimu station a ten napojíš na toho souseda. Tohle šlape OK.
A připojí se to i po změně kanálu sousedova AP? Myslím, že tohle jsem zkoušel (ještě v ROS6) a po prvním přeladění se Mikrotik už nepřipojil, protože čekal na původním kanále.
-
Nepřipojí. To musíš řešit skriptem v každém případě. Pokud není wlan klient up, tak si najít navou frekvenci pomocí něčeho jako:
foreach i in=([/interface wireless scan wlan1 duration=5 as-value]) do={if (($i->"ssid")="SSIDsouseda") do={:put [:pick ($i->"channel") 0 [:find ($i->"channel") "/"]]}}
a pokud je soused živý a frekvence jiná, tak ji změnit. A tohle pouštět přes scheduler a hlídat si, ať to skenování nedělám moc často.
Jde nastavit, aby se ti to samo přeladilo. Klienta dáš na fyzický wlan1, frequency=auto, tohle ti bude vzorně přelaďvat za sousedem do okamžiku, než to soused úplně vypne, pak to začne kontinuálně ladit a to virtuální AP nad wlan1 klientem má smůlu, během ladění se na něj nedá připojit. Proto, pokud potřebuješ tento stav ošetřit, tak je třeba přelaďovat skriptem občas, aby ti to fungovalo zároveň jako APčko a pak je asi lepší mít AP na fyzickém a klienta na virtuálu.
Inu, jednorádiový setup má nějaké limity. :-(