Üdv!
Adott egy Mikrotik RB532-es routerboard, mögötte egy IIS alapú webszerver, mely több virtualhost-ot szolgál ki. A 80-as port dstnat-tal látszik a publikus IP-ken. A problémánk az, hogy a szolgáltató december 31-ig lecseréli a jelenlegi IP címeket. Mivel az adott website-ok DNS zónája sajnos nem a mi kezelésünkben van, ezért az IP átállás alatt a régi és az új IP-ken is elérhető kellene legyen, az átmeneti időben, amíg a DNS adminok hajlandóak átírni a rekordokat.
Ehhez azonban nem elég felvenni az új IP-t és az ahhoz tartozó új átjárót, mert két default gateway-jel nem fog működni, az új IP-csomagok nem tudják merre menjenek, illetve találjanak vissza. :(
Szóbeli tippet kaptam az ún. "policy routing" alkalmazására, azonban a talált példákat nem sikerült átültetni, főképp a több ISP-s wan "load balancing" alapúakat nem, ui. itt fordítva kellene működnie a dolognak.
Nagyjából erről volna szó:
Webszerver LAN-IP:80 <- DSTNAT:80 <- ISP-RÉGI-IP és ÚJ-IP:80
És ugyebár adottak az átjárók:
RÉGI IP: DEF-GW:
1.2.3.4/24 1.2.3.254
ÚJ IP: DEF-GW:
9.8.7.6/24 9.8.7.254
Nem tudom, mennyire volt érthető a probléma, ha a DNS zóna is nálunk lenne, úgy nem lenne gond, mert mi tudnánk ütemezni az átállást, de így sajnos kelepce az egész. Esetünkben azért volna hasznos egy speciális routing szabály alkalmazása, mert a mögöttes webszerveren sajnos két virtualhost is ugyanazon a publikus IP-n látszik, ellenben az egyiknek már sikerült a DNS zónáját átíratni, míg a másiknak nem, bürokratikus okok miatt. :(
Így most sajnos egyik sem elérhető...
Plz HELP!
Előre is Hálásan Köszönjük a Segítséget!
- 2317 megtekintés
Hozzászólások
Ip/Routes/Rules-ben felveszel két szabályt:
1. Src.Address: 1.2.3.4/24, Routing Mark: regi
2. Src.Address: 9.8.7.6/24, Routing Mark: uj
Csinálsz két új default route-ot, és a defeult route-khoz Ruting Mark-nak értelemszerűen felveszed a "regi"-t és az "uj"-at.
- A hozzászóláshoz be kell jelentkezni
Üdv!
Köszönjük a segítséget, majdnem ki is próbálta a kollégám! :)
Sajnos az új GW valamiért nem elérhető ott (ISP oldali hiba lehet), ezért nem tudtuk igazán tesztelni, de ha megoldják, akkor be tudok számolni róla.
---
The Network is NOT Oracle... The PC is NOT Microsoft...
- A hozzászóláshoz be kell jelentkezni
Hali!
Sajnos ez így nem akar működni, valószínűleg hiányzik még valami. :(
Ha az új IP/Default Gateway be van állítva, akkor csak az új IP-k érhetőek el, ű
a régin nem látszik már a router. Vica versa, ha csak a régi def gw él, akkor pedig csak a régi IP-vel látszik.
A lényeg az lenne, hogy a régi és új IP-ken _egyszerre_ látszódjon a router és a mögöttes szerver, ezért feltételezzük, hogy a megadott megoldás hiányos (lehet). Az ISP részéről minden rendben van, mindkét IP-tartomány él már a dróton.
Ettől függetlenül Köszönjük az ötletet és Kérünk Szépen még további segítséget, Advanced Mikrotik Geek-ektől plz!
---
The Network is NOT Oracle... The PC is NOT Microsoft...
- A hozzászóláshoz be kell jelentkezni
ip rule parancsokkal kell varázsolni.
a 'normál' main routing táblából ki kell venni a default router(eke)t, kell csinálni plusz két routing táblát, az egyikbe csak az egyik default routert felvenni, a másikba csak a másikat, és a ha kimenő forgalom default routingját a fenti kettőtől eltérően akarod megcsinálni (mondjuk alapból az egyikre menjen, de fallbackeljen a másikra), akkor erre kell egy harmadik routing tábla.
ip rule add to "lokális network címek" priority 100 table main
ip rule add from "link 1 ip cím" priority 200 table "link 1 default routerét tartalmazó routing tábla"
ip rule add from "link 2 ip cím" priority 200 table "link 2 default routerét tartalmazó routing tábla"
ip rule add from "link 1 ip cím" priority 300 unreachable
ip rule add from "link 2 ip cím" priority 300 unreachable
ip rule add from all priority 1000 table main
ip rule add from all priority 2000 table "a preferált kimenő link default routerét tartalmazó routing tábla"
- A hozzászóláshoz be kell jelentkezni
Ha terminalból kiadod az álábbi parancsokat akkor ezeket kell kapnod:
/ip route print detail
0 S dst-address=0.0.0.0/0 gateway=1.2.3.254 gateway-status=1.2.3.254 unreachable distance=1 scope=30 target-scope=10
routing-mark=regi
1 S dst-address=0.0.0.0/0 gateway=9.8.7.254 gateway-status=9.8.7.254 unreachable distance=1 scope=30 target-scope=10
routing-mark=uj
/ip route rule print
0 I src-address=1.2.3.4 routing-mark=regi action=lookup table=""
1 I src-address=9.8.7.6 routing-mark=uj action=lookup table=""
Igy működnie kell, ha nem megy akkor valami más a probléma.
- A hozzászóláshoz be kell jelentkezni
Lenne egy idevágó kérdésem, amit nem értek. Valaki tereljen engem jó irányba!
Ha bejön egy kérés kintről a routeren keresztül a webszerverre, honnan fogja tudni a szerver/router, hogy melyik vonalon kell visszaküldeni az választ a klienshez?
- A hozzászóláshoz be kell jelentkezni
Policy routing. Rendes esetben csak a csomag cél IP cím szerint tud menni a routing, de policy routing esetében más dolgokat is figyelembe lehet venni (pl. a forrás IP címet is).
- A hozzászóláshoz be kell jelentkezni
Használok policy routingot, de szerintem az csak akkor működik, ha egyben van a router és a webszerver. Úgy, hogy a router továbbpasszolja a csomagokat a webszervernek, ami egy másik gépen van, úgy is tud működni? Mi alapján?
- A hozzászóláshoz be kell jelentkezni
Mi az, hogy továbbpasszolja a csomagokat? Változatlan formában? Akkor nyilván ugyanúgy működik, hiszen a forwardolt csomagoknál pont ugyanúgy lehet forrás IP cím szerint kezelni a dolgokat. Ha DNAT-olsz, akkor az a "helyes" technológia, hogy a webszervernek is annyi belső címe legyen, ahány kinti címen támadható (ergó a DNAT 1:1 leképezést jelent), így ugyanígy lehet a forrás IP cím szerint kezelni a dolgokat, legfeljebb a NAT-on kívüli és belüli címeket egyaránt érdemes felvenni, mert így biztosan matchelni fog valamelyikre.
Ha viszont nem akarsz belül több címet felvenni, akkor nem biztos, hogy triviális a megoldás...
- A hozzászóláshoz be kell jelentkezni