Új hozzászólás Aktív témák

• #357 J97 tag

  Új Válasz 2015-01-19 16:06:33 #357

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  J97

  tag

  Üdv.!

  Egy kis szakmai segítséget szeretnék kérni. Adott egy Mikrotik AH1100X2 router, két wan kapcsolat. A következőt szeretném megvalósítani. Van egy levelezőszerverünk a belső hálózaton egy hozzá rendelt domainnel és fix ip címmel rendelkező internet kapcsolattal. Kezdetben csak ez az egy wan kapcsolatunk volt, így a levelezés gond nélkül működött. Most beköttettünk egy másik szolgáltató által üzemeltetett gyorsabb WAN kapcsolatot. Azt szeretném elérni, hogy a levelezés maradjon a régin, ha kapunk egy levelet akkor azon az interfészen pottyanjon be a levelező szerverre, mivel erre szól a domainünk is, minden más pedig a gyorsabb kapcsolatot használja. A levelező szerver ip cím alapján legyen elérhető mindkét irányból tehát mindkét külső címről meg tudjam szólítani. Jelenleg ha mindkét WAN kapcsolatot elérhetővé teszem egy időben a gyorsabb wan kapcsolatot veszi figyelembe a forgalomirányító, a levelező szerver kívülről nem elérhető egyik irányból sem. A nat szabály a pppoe kapcsolatra szól tehát a régire, ebből kifolyólag a régin ugyanúgy elérhetőnek kellene lennie. Még nem volt sok dolgom mikrotikkel minden segítséget szívesen veszek.

  ether1-gateway pppoe kapcsolat
  ether13 kábel modem dhcp-client mód

  Minden nap egy alma és a doktor al ma. | Kirby a parancsnok!

• #360 J97 tag bacus #359

  Új Válasz 2015-01-20 09:35:21 #360

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  J97

  tag

  válasz bacus #359 üzenetére

  Igazából befele irányon kell, hogy elérhető legyen mindkét irányból. A lényeg az, hogy tárhelyszolgáltatót és domaint is váltunk. Az átállás ideje alatt a régi domain címen az ISP1 vonalon pottyanjanak be az emailek (IMAP), az új még tesztelés alatt álló domain címünkre küldött levelek pedig az ISP2 -es vonalon. Így a régi még működő levelezés az ISP1 vonalon bonyolódik továbbra is. Az átállás folyamatos lesz, ha átálltunk az ISP1 vonalat megszüntetjük. A levelezésen kívül minden más forgalom a gyorsabb ISP2 vonalon bonyolódna.

  Ha kihúzom az új ISP2 vonalat helyreáll a levelezés, küld is, fogad is, ebből következtettem én is valamilyen szabály hiányára. Ha csatlakoztatom az ISP1 mellé az ISP2 vonalat akkor az ISP1 nem bonyolít tovább semmilyen forgalmat, az ISP2 lesz a main, gondolom a jobb metrika miatt alapból ezt részesíti előnyben a forgalomirányító. A NAT szabályaink a pppoe ISP1 kapcsolatra szólnak ami a levelezőszerverrel és egyéb szolgáltatással kapcsolatosak. A tűzfalszabályoknál nincs interfész megadva, minden befele jövő forgalmat néz és szűr. A két ip cím tartomány sajnos nem megoldható az okok hosszúak tehát marad a mangle szabály. Igazából ez az a rész amivel még nem boldogultam.

  Ezekkel próbálkoztam:

  chain=forward action=accept protocol=tcp dst-address=192.168.100.254 in-interface=pppoe-out1 dst-port=143 log=no log-prefix=""

  chain=forward action=accept protocol=tcp src-address=192.168.100.254 out-interface=pppoe-out1 log=no log-prefix=""

  Minden nap egy alma és a doktor al ma. | Kirby a parancsnok!

• #362 J97 tag bacus #361

  Új Válasz 2015-01-21 06:10:47 #362

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  J97

  tag

  válasz bacus #361 üzenetére

  Igaz, lényeges, hogy kívülről lev. klienssel és webes felületről is elérhető legyen a levelezőszerver.

  Tehát jelenleg a forgalomirányító táblában három útvonal van bejegyezve. 2 ISP és egy LAN. Kívülről elvileg mindkét oldalt meg tudom szólítani és tovább tudja dobni a csomagot az ő egy szem connected belső hálózatába a megfelelő portokon. Amin bejött a kérés arra megy a válasz is vissza ez tiszta sor. Kifele az ISP1 útvonal fele küldené a csomagokat (alap esetben, e mellé jön majd a második domain kezelése is az ISP2 vonalon) erre kellene a routing szabály de jelenleg ha bekapcsolom mindkét ISP kapcsolatot egyik irányból sem elérhető a szerver. NAT szabályok mindkét irányban fel vannak véve.

  Láttam példákat 2 ISP -s failover és load balancing megoldásokra azokkal, amiket írtál de nekem nem pont azokra van szükségem bár időráfordítással biztosan ki tudnám bogarászni belőle, ami nekem kell. Ezek a szabályok egy már meglévő VPN mangle szabályból lettek átalakítva az lehet, hogy befejezetlen, ehhez kellett volna egy kis segítség.

  Minden nap egy alma és a doktor al ma. | Kirby a parancsnok!

• #367 J97 tag

  Új Válasz 2015-01-21 13:31:52 #367

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  J97

  tag

  Köszi a segítséget mindenkinek! Találtam ezzel kapcsolatosan egy [ígéretes] leírást. Ahogy látom ez nagyon hasonlít ahhoz, ami nekem kell. Sajnos el vagyok vonva a projekttől mert más projektekkel meg nyakig úszunk a melóban. Így csak kutyafuttában tudok vele foglalkozni egyelőre. Jelenleg a régi ISP -n megy továbbra is. Elvileg a nat szabály nem rossz, ugyanazt a nat szabályt vettem fel a másik ISP fele is természetesen ott az arra vonatkozó interfészen. Egyik in. interfésze pppoe az új kapcsolaté eth13. Amint lesz időm neki vetem magam a leírásnak és beszámolok a fejleményekről.

  Minden nap egy alma és a doktor al ma. | Kirby a parancsnok!

• #378 J97 tag bacus #368

  Új Válasz 2015-01-23 10:04:52 #378

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  J97

  tag

  válasz bacus #368 üzenetére

  Mangle szabályok felvéve és élesítésre várnak. Routing szabályokat próbáltam felvenni de szerintem a már meglévő dinamikus szabályok miatt nem tudtam őket felvenni. Azokat először el kellett volna távolítani. Mivel nálunk nem állhat le a rendszer egy percre sem, így nem tudtam még kipróbálni. Valamelyik nap egy percre elment az internetkapcsolat és már jöttek számon kérni mi a f...t csinálok már megint. Tegnap volt egy hamvába hót próbálkozásom, munkaidő után kértem kollégát ha elküldte az emialt szóljon mert megszakadhat a netkapcsolat, 5 -kor zár az iroda, kulcsom nincs, 16:55 -kor szólt, hogy már nem kell neki a net be tudom állítani két perc alatt és utána zárás! Szóval nem olyan egyszerű ez.

  Két routerünk van. Az új RB1100AHx2 és egy RB750GL. A routereket már kicserélniem az 1100 as van üzemben a 750 es konfigjával. A 750 est befogtam kicsit szórakozni. Rálőttem a 750 -re az új ISP2 es vonalunkat és az 1100 -ról érkező natolt hálót, így szimulálva a két ISP -t. Fogtam egy notit azt meg, mint szerver emulátort kötöttem rá a 750 es ether2 portjára. A notin futott a freeSSHd nevű programocska egy telnet szolgáltatással a 25 -ös porton, amivel próbáltam emulálni az SMTP -t. A 750 -re felvettem két src nat szabályt.

  Így néznek ki:

  ;;; SMTP
  chain=dstnat action=dst-nat to-addresses=192.168.200.4 to-ports=25
  protocol=tcp in-interface=ISP1 dst-port=25 log=no log-prefix=""

  ;;; SMTP
  chain=dstnat action=dst-nat to-addresses=192.168.200.4 to-ports=25
  protocol=tcp in-interface=UPC dst-port=25 log=no log-prefix=""

  Ezzel a beállítással mindkét irányból kívülről elértem a freeSSHd telnet által emulált szolgáltatást a 25 -ös porton. Még annyi, hogy közben rájöttem, hogy a UPC nél ki kellett velük még külön kapcsoltatni a szolgáltatói tűzfalat, mert az szűrte a 25 -öst befele.

  Azt viszont nem értem, hogy mindez, így miért nem akar működni élesben a másik routeren. Két irányból be, nat szabályokkal. Mindenesetre várom, hogy mikor tudom kipróbálni a leírásban levő példát. Ott még felmerült bennem egy két kérdés, ami nem volt teljesen világos.

  add chain=dstnat action=dst-nat in-interface=ISP1 dst-address=80.80.80.80 dst-port=25 to-address=192.168.200.4

  add chain=dstnat action=dst-nat in-interface=UPC dst-address=70.70.70.70 dst-port=25 to-address=192.168.200.4

  Itt mit ért dst-address alatt?

  Felhívtam a mikrotik magyarországi forgalmazót technikai supportért. Tőlük azt a választ kaptam, hogy ne is próbálkozzak a szerver egy azon interfészét két irányba elérhetővé tenni, helyette legyen a szervernek két interfésze pl. 1.2 és 2.2 és így NAT -oljam ki.

  A mostani megoldás végül ez lett, mivel a főnököm is a hivatalos support általi megoldást preferálta. Az én fantáziám azért piszkálja a másik megoldás, mert ezt nem találom túl elegánsnak.

  Minden nap egy alma és a doktor al ma. | Kirby a parancsnok!

• #380 J97 tag bacus #379

  Új Válasz 2015-01-26 08:53:38 #380

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  J97

  tag

  válasz bacus #379 üzenetére

  A zárás része nem vicc. A VPN megvan már jó ideje és üzemel, van hozzá mangle szabály is de csak egy forward change MSS van felvéve. Igazad van, ez már csak az én túlzott óvatosságom. Ha elrontok valamit és kizárom magam, reggel nem tudják használni a kapcsolatot és nem sok idő lesz a helyreállításra ebből kifolyólag nem mertem távolról állítgatni a routingot.

  Akkor jó a két dst-address= részt üresen hagytam. ISP1 ppoe -s ISP2 DHCP -s és in interfésszel van megadva. Attól tartok nem lesz alkalmam tesztelni a mangle szabályokat. A két ISP csak az átállás ideje alatt lesz meg és egy két hónap együtt futás után a régi ISP -t lemondjuk. Jelenleg a két alhálózatos megoldás működik. Le is lettem szedve a projektről kaptam mást, pedig nagyon érdekel a téma!

  A forgalmazót megírom priviben.

  Minden nap egy alma és a doktor al ma. | Kirby a parancsnok!

Új hozzászólás Aktív témák