[Felfüggesztve] UBNT (edge router) Mágust keresek.

Hálózatok általános

#Update: úgy tűnik ez a router nem képes arra, amit elvárunk tőle, szóval egyelőre felfüggesztve a téma.

# Köszönöm a hozzászólásokat. Sokat oszlott a "köd". (ha esetleg megoldom mégis valahogy, akkor lehet lesz belőle blogbejegyzés)

Sziasztok!

Felvetődött a környezetemben egy elég egyedi probléma.

Dual WAN egyedi portátirányítással Edge routeren.

Sehogy sem tudom megoldani. Nagyon sok, (fórumban is ismertetett) leírást kipróbáltam, de a sok feltétel közül legalább egy nem teljesül.

Tehát keresnék egy gurut/mágust/mestert erre az eszközre. Egyelőre PM-ben.

 

Kösz srácok.

  • 1005 megtekintés

( STP | 2020. 12. 22., k – 18:46 )

Nem ártana „picit” pontosítani a problémafelvetést.

Másrészt a portforward és a security nem annyira cimbik.

"Másrészt a portforward és a security nem annyira cimbik."

Ezt mire írtad? De talán rátapintottál. VPN átirányítgatásokról lenne szó.

Akkor tömören: 2 WAN -> 2 VPN szerver (nason) (keresztbe is). De a sima netezés viszont így gondban van néha a különböző külső ip-k miatt.

Csak akkor szólok hozzá egy témához, ha értelmét látom.

Tehát valamiért a NAS-on végződtetsz két meg nem nevezett VPN szervert, míg a VPN képes eszköz csak ementálit kell, hogy játsszon?

Lehet a problémát kicsit pontosabban megfogalmazni/körülírni?

GUI-s alapkonfigot kattintgattál össze vagy csináltál zónázott konfigurációt?

Failover vagy LB módban működik a két WAN kapcsolat?

Mit nem tudtál beállítani a NAT szabályban?

MTU-k egyeznek az interfészeken?

Először is mindenképpen köszönöm, hogy foglalkozol a problémával. Engem mint informatikai/mérnöki kérdés foglalkoztat a szituáció, tehát leginkább megérteni akarom, hogy mit baszok el.

Szóval akkor csak röviden és nem sorrendben:

"Tehát valamiért a NAS-on végződtetsz két meg nem nevezett VPN szervert, míg a VPN képes eszköz csak ementálit kell, hogy játsszon?"  >>  Kicsit átfogalmazom: a router VPN funkcióját nem akarjuk használni, csak eressze át magán, és routolja a megfelelő nasokra (IP/port) a VPN forgalmat.

"MTU-k egyeznek az interfészeken?"  >>  Szerintem igen. Egész pontosan, nem állítottam el az alapértelmezett 1500-at. (de szerintem ez nem is releváns most)

"Failover vagy LB módban működik a két WAN kapcsolat?"  >>  LoadBalansz. És itt vannak a gondok a sima netes szolgáltatásokkal. Az autentikációt igénylő oldalak panaszkodnak, hogy megváltozik az ip cím. (az LB logika csak az "egy-ide-egy-oda" módot ismeri (legalábbis én nem találtam mást))

"GUI-s alapkonfigot kattintgattál össze vagy csináltál zónázott konfigurációt?" >>  A varázsló által generált konfigot állítottuk volna tovább. Csak GUI-n.

"Mit nem tudtál beállítani a NAT szabályban?"  >>  Na igen... itt lehet a zavar. Próbáltam sima portforwardot, meg DNAT-ot, SNAT-ot, meg ezek kombinációit. De valami mindig hibádzott.

Azt még érdemes tudni, hogy kábelnetes fix ip-k vannak. És működnek is szépen.

--Elég bonyolult dolgot várunk el az eszköztől úgy tűnik. (lehet túl sokat is) Az én 20-on éves linuxos, meg 10-en valahány éves hálózatos tapasztalatommal sem tudtam rájönni, hogy ennél az eszköznél mit hova, ha egyáltalán tudja.--

Csak akkor szólok hozzá egy témához, ha értelmét látom.

"Amit Te keresel az egy (belső) load balancer"

Félig. A keresztbe routolás már ez a terület lehet. A failover móddal egyébként ment a dolog.

Szóval akkor kösz. Megnyugtattál. Ezek szerint nem én vagyok a béna, hanem az eszköz GUI-án nem lehet megoldani az elvárt működést.

Akkor azt hiszem, lezárom a témát.

Csak akkor szólok hozzá egy témához, ha értelmét látom.

Ezek szerint nem én vagyok a béna, hanem az eszköz GUI-án nem lehet megoldani az elvárt működést.

Így van, hiszen nincs ilyen funkciója az EdgeOS-nek.

Ráadásul egy normális LBer párban jár, Te pedig egy eszközzel kívántad volna ezt megoldani.

Két WAN, két NAS, egy FW. Kérdés; hol van a SPF? ;)

"Failover vagy LB módban működik a két WAN kapcsolat?"  >>  LoadBalansz. És itt vannak a gondok a sima netes szolgáltatásokkal. Az autentikációt igénylő oldalak panaszkodnak, hogy megváltozik az ip cím. (az LB logika csak az "egy-ide-egy-oda" módot ismeri (legalábbis én nem találtam mást))

Ha a routernek két külön publikus címe van és ezekre SNAT-ol kimenő kapcsolatoknál, akkor ez a probléma fenn is fog maradni. Ezzel nem fogsz tudni mit csinálni. Vagy failovert csinálsz, ez esetben az egyik vonal passzív, vagy megoldod, hogy bizonyos címtartományok felé az egyik, más irányba a másik vonalat használja (persze vonalhiba esetén átmehetsz a másikra).

"Tehát valamiért a NAS-on végződtetsz két meg nem nevezett VPN szervert, míg a VPN képes eszköz csak ementálit kell, hogy játsszon?"  >>  Kicsit átfogalmazom: a router VPN funkcióját nem akarjuk használni, csak eressze át magán, és routolja a megfelelő nasokra (IP/port) a VPN forgalmat.

Ez erősen VPN függő, két különböző VPN típussal talán megoldható, illetve openvpn esetén két külön porton üzemeltetve szintén, de más esetekben nem egyszerű, vagy akár lehetetlen is lehet. Illetve mivel két vonalad és két külön címed van, az még esélye lehet, hogy az egyik VPN 'látszólagos' endpointja az egyik cím, a másiké pedig a másik, persze ilyenkor a failovert is elfelejtheted a VPN-ek tekintetében.

Köszi a hozzászólásodat.

"vagy megoldod, hogy bizonyos címtartományok felé az egyik, más irányba a másik vonalat használja (persze vonalhiba esetén átmehetsz a másikra)."

Na... ez se nagyon akart sikerülni. Már ezzel is elégedettek lennénk.

A többszörös VPN szolgáltatással belső oldalon nincs gond. Az megy. Lepróbáltuk. 

"Illetve mivel két vonalad és két külön címed van, az még esélye lehet, hogy az egyik VPN 'látszólagos' endpointja az egyik cím, a másiké pedig a másik, persze ilyenkor a failovert is elfelejtheted a VPN-ek tekintetében."

Itt most kis ellentmondás érzek. Vagy nem értem mit szeretnél mondani. Ha az "1. vonal -> 1.VPN, és 2. vonal -> 2.VPN" akarjuk használni, akkor persze hogy nem lesz failover. Ezzel tisztában vagyunk. (bár nem ez lenne az ideális)

De itt ismét leírom, hogy egyelőre az se sikerült, hogy működjön az 1->1, 2->2 helyzet egyszerre.

Csak akkor szólok hozzá egy témához, ha értelmét látom.

Igen, az 1->1 és 2>2 felállásra gondoltam. De ennek az is szükséges feltétele, hogy a válaszcsomagok ugyanazon az interface-en menjenek vissza, mint ahol bejöttek. De mivel - ahogy írod - még a címtartományok szerinti más route-olás sem jött össze, ehhez még sok dolgot meg kell oldanod.

"De ennek az is szükséges feltétele, hogy a válaszcsomagok ugyanazon az interface-en menjenek vissza, mint ahol bejöttek."

Szerintem ez lesz a legáthidalhatatlanabb gond. Mivel a firm csak az "egy_csomag-ide-egy_csomag-oda" elvet ismeri (a GUIn biztos).

Mindegy. Segítettél. Köszi.

Csak akkor szólok hozzá egy témához, ha értelmét látom.

https://help.ui.com/hc/en-us/articles/204952274-EdgeRouter-Policy-Based…

Errefelé lehetne elindulni. Be tudod tenni az egyik vpn endpointot az egyik groupba, a másikat a másikba, és akkor működhet az 1->1, 2->2 felállás.

A loadbalance problémádra pedig ezzel próbálkozz: https://help.ui.com/hc/en-us/articles/205145990 - ezen belül keresd meg a Sticky részt.

 

Sticky

This option will keep traffic sessions on the same WAN interface until they are timed out. The following options are available:

  • dest-addr Traffic sessions will be on the same WAN interface based on the destination address.
  • dest-port Traffic sessions will be on the same WAN interface based on the destination port.
  • source-addr Traffic sessions will be on the same WAN interface based on the source address.
  • source-port Traffic sessions will be on the same WAN interface based on the source port.
  • proto Traffic sessions will be on the same WAN interface based on the protocol.
set load-balance group G sticky dest-addr enable
set load-balance group G sticky dest-port enable
set load-balance group G sticky source-addr enable
set load-balance group G sticky source-port enable
set load-balance group G sticky proto enable

Köszi. Az LB-s részt olvastam már. De nem igazán vettem alapul, mert nekem GUI-s megoldás kell(ene). (A wizard után nem találtam a sticky-t. Igaz, nem is kerestem. Azt vártam volna, hogy bekapcsolja automatikusan. (ezt még megnézem mégegyszer))

Én ugyan elvagyok cli-n, de aki esetleg helyettem túrna a konfigon, az csak a GUI-t ismeri (windowsosok.... cöh). Ezért a cli kerülendő.

De mindenképpen hasznos. Köszönöm mégegyszer.

Csak akkor szólok hozzá egy témához, ha értelmét látom.

Némi hackeléssel minden cli beállításnak lehet megfelelő config tree beállítást csinálni. Egyetlen hátránya, hogy egy upgrade ezt képes kiirtani.

Ha pedig másnak is hozá kell nyúlnia, akkor megfelelően dokumentálni kell a beállítást, aki meg megfelelő dokumentáció és olvasnitudás hiányában elbarmolná a konfigot, az ne kapjon admin accountot. De ha mégis, backupból visszaállítható a jó konfig.

Én azt vettem észre, hogy a cli, a GUI, és a config tree nem egészen fedik egymást. De ez elég régi tapasztalat, lehet fejlesztettek rajta azóta.

Az pedig, hogy a mai világban csak hozzáértő férhessen hozzá egy-egy eszközhöz, hát erősen utópisztikus. Én is elég sokszor takarítottam már "kolléga" után.

Mindegy. A config backup-olás fontos. Eddig is csináltuk. Szóval csak egyszer kell összerakni. Utána már bódottáá.

Csak akkor szólok hozzá egy témához, ha értelmét látom.