Mikrotik WifiWave2 - Station-bridging nem támogatott többé

Wireless

Van egy  hAP ax² és egy hAP ac lite, ami között szerettem volna egy wifi bridge-t létrehozni, de most vettem észre, hogy a wave2-ben nincs többé station-bridge mód. Ha kikapcsolom a wave2-t a hAP ax²-n akkor wifi sincs, mert csak azt támogatja a wifi interface.

Az ac lite hiába tudja station-bridge módot nem csatlakozik rá az ax2-re és station-pseudobridge módban sem. A station mód elég szívás, mert lenne mögötte több hálózati nyomtató.

Van valakinek ötlete mit lehetne csinálni? A wave2-vel a wifi bridge megszűnt?

Egyenlőre úgy tűnik, hogy így jártam.
 

( bennyh | 2023. 03. 15., sze – 06:28 )

Szerkesztve: 2023. 03. 15., sze – 06:29

Bridging helyett még mindig ott a routing (meg a sima ap-station kapcsolat), más alhálón lévő nyomtató is tud működni, ha be van állítva az átjáró, vagy pl natolsz. Esetleg EoIP.

( ggallo | 2023. 03. 15., sze – 10:27 )

Mi az eredeti probléma, amit két különböző tudású-korú SOHO szappantartóval szeretnél megoldani a gyakorlatban?

Rengeteg MT eszközt használunk, de sohasem merült fel semelyikünkben (a cégnél), hogy ennyire különböző technológiájú eszközöket keverjünk egy link esetében.

PtP kapcsolatokra mindig irányítottabb eszközt használunk (pl. SXT vagy LHG pár, "sima" vagy AC az igényektől függően).

Az én olvasatomban az AX leginkább client access irányában tett lépéseket az AC-hez képest, nem PtP linkhez való dolog. Amikor már olyan sebesség kellene PtP kapcsolatnál, amit AC-s eszközzel nem tudunk kiszolgálni (...azt AX-szem sem tudnánk valszeg, mert úgy is túlságosan telített minden 5G sáv már), akkor vagy 60G-s (pl. Cube) eszköz kerül elő, vagy nagyobb távra (több mint 6-700 méter) pl. Ubiquiti AirFiber vagy Racom RAy3 rádió, a távhoz megfelelő méretű tányérral.

Nemrég lett lecserélve egy ezer éves ap ax2-re, a másik meg volt a szekrényben. Most meg átrendezték az irodát és van egy "sarok" ahol nincs kábel ezért a legegyszerűbb egy wifi bridge lenne. Nem vészes 2 gép és 3 nyomtató lóg rajta, csak route-olva át kell konfigurálnom a nyomtatókat, és minden gépen az elérésüket. Ha nem megy jó a sima station is, csak a lustaság :D

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

No, hát ha 5 eszköz nem ér meg egy kis kábelezést, akkor az is lehet megoldás, hogy a wifi túlvégén lévő eszközök új IP tartományba kerülnek, és a régi tartományban lévő wifi eszköz 1:1 NAT-ot csinál a nyomtatók régi IP címéről az új IP címére. Így nem kell semmit átkonfigurálnod a klienseken (csak az új szegmensbe kerülő 2 gépen).

Vagy ha már úgy is konfigurálnál, akkor dobod az IP címezést az osztott erőforrások elérésénél, és (akár a MT-en statikus bejegyzésekkel) DNS használatára térsz át a hálózati eszközök elérése terén. Akkor tök mindegy mi a címe, csak a DNS bejegyzést kell módosítani...

1. nem ismerem a WW2-es csomag képességeit, mi van ha nincs?

2.

A fia meglátogatja a székelyt, hoz az apjának egy dobozos sört, az meg elkezdené kibontani bicskával:

- Na de ídesapám, had mutassam meg, itt van rajta ez a fül, ezzel ki lehet bontani.

- No igen, akinek nincs bicskája...

Semmilyen bridge nem maradt.

https://help.mikrotik.com/docs/display/ROS/WifiWave2

Lost features

The following notable features of the bundled wireless package do not yet have equivalents in the wifiwave2 package

  • Station-bridging or other 4-address modes
  • Nstreme and Nv2 wireless protocols

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

Nem a masq a leglényegesebb, hanem hogy van végre DNAT és tartomány mapping.
Sok esetben kényszer lesz, mert tuti belefutsz abba, hogy valamiért a felettes routing nem mutat rád (nem tudsz a társcéggel értelmesen egyeztetni) és mégis mögöttes hálózatba kell bedobnod a forgalmat. És ezzel eljutottunk oda, hogy bizony lesz IPv6 esetén is tákolás és sajnos erre a képességre szükség lesz.

Ami viszont gázos, hogy egy nem feltétlen baráti gépeket tartalmazó szolgáltatói hálózatban azért nem jó a Mikrotik switch funkcióra, mert az RA Guard funkciót nem hajlandó a gyártó implementálni benne. Ezt egyébként a HP, Cisco, Juniper és több más gyártó switcheiben már 10 éve megtalálod.

Kipróbáltam, megadtam src-NAT-ba "to-address"-nek a szolgáltatótól épp kapott tartományt és látszólag véletlenszerű (a gép temporary address host azonosítójával sem egyező) címeket látnak a tesztoldalak, sőt böngészőnként és azon belül tesztoldalanként is mintha más lenne. A ping megy, a kame.net-en is táncol a teki. Ez így nem tudom most mivel jobb, mint a sima masquerade, majd még tesztelem.

Na látszik, hogy ilyen tartomány átírásra sosem volt szükségem, mert src-nat helyett az IPv4-es tűzfal leírásában található "netmap action"-nel már úgy néz ki, működik. Egy az egyben a host azonosítókat látom vissza a tesztekben. Még tesztelgetem, de érdekes. Azt akaraom még megoldani, hogy a fő LAN-on legyen csak prefix translation a többiből meg masquerade (amúgy is csak /64-es tartományt kapok a szolgáltatótól). A DHCP kliensbe raktam egy szkriptet, ami frissíti a tartományt a NAT szabályban, azzal, elvileg, nem lesz már gond.

"Ami viszont gázos, hogy egy nem feltétlen baráti gépeket tartalmazó szolgáltatói hálózatban azért nem jó a Mikrotik switch funkcióra, mert az RA Guard funkciót nem hajlandó a gyártó implementálni benne. Ezt egyébként a HP, Cisco, Juniper és több más gyártó switcheiben már 10 éve megtalálod."

Ez elméletileg kiváltható ACL/tűzfalszabállyal. A kliens portok felől kell szűrni az ICMP type 134-et. Nem tudom, hogy a mikrotikban megoldható-e ez.

( tibyke | 2023. 03. 16., cs – 07:05 )

Egyenlőre a baltás gyilkos vág, amire te gondolsz, az egyelőre!

( wpeople v | 2023. 03. 16., cs – 08:51 )

@gyuri23: az nem merült fel benned, hogy felcseréld a két eszközt egymással? :-)

( debtamas88 | 2023. 03. 19., v – 12:03 )

Hát akkor marad a "kábelbehúzás + 1db switch" megoldás :)