juniper srx - routing - routemap?

JunOS / Juniper / Netscreen
Wiadomość
Autor
pysiok83
wannabe
wannabe
Posty: 221
Rejestracja: 21 wrz 2009, 12:06

juniper srx - routing - routemap?

#1

#1 Post autor: pysiok83 »

Witam!
Mam w SRX ustawiony kanał VPN z innym SRXiem w 2 lokalizacji. Mam ustawiony routing statyczny na SRX w 1 lokalizacji, że z 0.0.0.0 next-hop adres publiczny 2 srx. Chciałbym jednak aby pewne adresy z wewnątrz 1 lokalizacji wychodziły bezpośrednio do internetu nie przez 2 srx. Czy można jak w cisco jakąś rout mape zrobić? Czy coś takirgo istnieje?
PS czy wówczas będzie potrzebny nat?

Awatar użytkownika
garfield
CCIE
CCIE
Posty: 2882
Rejestracja: 25 sie 2006, 18:32
Lokalizacja: Gdynia

#2

#2 Post autor: garfield »

w skrócie ruch z 192.168.100.0/24 pchaj przez GW 192.168.224.2 a resztę normalnie

Kod: Zaznacz cały

interfaces {
fe-0/2/2 {
description LAN;
unit 0 {
family inet {
filter {
input ROUTE-MAP-NET-100-0;
}
address 192.168.5.1/29;
}
}
}

routing-options {
interface-routes {
rib-group inet all-ribs;
}

rib-groups {
all-ribs {
import-rib [ inet.0 REDIRECT-100-0.inet.0 ];
}
}

firewall {
family inet {
filter ROUTE-MAP-NET-100-0 {
term 1 {
from {
source-address {
192.168.100.0/24;
}
}
then routing-instance REDIRECT-100-0;
}
term 2 {
then accept;
}
}
}

routing-instances {
REDIRECT-100-0 {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 192.168.224.2;
}
}
}
}
nat'a jakiegoś musisz dodać, żeby np na adres interfejsu tłumaczył
np

Kod: Zaznacz cały

[edit security nat]
root@host# show
source {
    rule-set rs1 {
        from zone trust;
        to zone untrust;
        rule rl1 {
            match {
                source-address 192.168.100.0/24;
            }
            then {
                source-nat {
                    interface;
                }
            }
        }
    }
Remember that the lab is just looking for reachability and not “optimal reachability”.

pysiok83
wannabe
wannabe
Posty: 221
Rejestracja: 21 wrz 2009, 12:06

#3

#3 Post autor: pysiok83 »

No dobra, nie rozumiem co to znaczy normalnie?
Ja chciałbym aby ruch w zależnośći od źródła szedł bezpośrednio czyli na DG.
czy mogę kilka DG zrobić?

poniższy route jak idzie z danego źródła
route 0.0.0.0/0 next-hop 192.168.224.2;

poniższy route jak idzie z czegokolwiek poza tym co powyżej
route 0.0.0.0/0 next-hop 10.0.0.1;

Awatar użytkownika
garfield
CCIE
CCIE
Posty: 2882
Rejestracja: 25 sie 2006, 18:32
Lokalizacja: Gdynia

#4

#4 Post autor: garfield »

pysiok83 pisze:No dobra, nie rozumiem co to znaczy normalnie?
Ja chciałbym aby ruch w zależnośći od źródła szedł bezpośrednio czyli na DG.
czy mogę kilka DG zrobić?

poniższy route jak idzie z danego źródła
route 0.0.0.0/0 next-hop 192.168.224.2;

poniższy route jak idzie z czegokolwiek poza tym co powyżej
route 0.0.0.0/0 next-hop 10.0.0.1;
to wlasnie masz w powyzszym przykladzie
Remember that the lab is just looking for reachability and not “optimal reachability”.

pysiok83
wannabe
wannabe
Posty: 221
Rejestracja: 21 wrz 2009, 12:06

#5

#5 Post autor: pysiok83 »

tylko w tym przykładzie nie widze wpisu ściezki domyslnej.

Awatar użytkownika
garfield
CCIE
CCIE
Posty: 2882
Rejestracja: 25 sie 2006, 18:32
Lokalizacja: Gdynia

#6

#6 Post autor: garfield »

pysiok83 pisze:tylko w tym przykładzie nie widze wpisu ściezki domyslnej.
PBR'em sprawisz że ruch z wybranego SRC idzie do VRF'a REDIRECT-100-0 i korzysta z tablicy routingu inet.0 w tymże VRF'ie
reszta ruchu idzie przez domyślnego VFR'a master i jego tablice routingu inet.0
a co tam masz to nie wiem (statici, dynamiczne ?)
jeśli statici to wstaw takie coś tylko nie w VRF'ie a w konfiguracji głównej

Kod: Zaznacz cały

routing-options {
static {
route 0.0.0.0/0 next-hop 10.0.0.1;
}
} 
teraz już jasne :?: :D
Remember that the lab is just looking for reachability and not “optimal reachability”.

pysiok83
wannabe
wannabe
Posty: 221
Rejestracja: 21 wrz 2009, 12:06

#7

#7 Post autor: pysiok83 »

jest jeszcze jeden problem, wczesniej dostawałem sie po publicznym adresie na urzadzenie z zewnatrz po ssh, mailem jednak routing jako brame ostatniej szansy ustawioną na właśnie ten adres publiczny. Teraz brama wskazuje na tunel VPN czyli st0.0 i z zewnatrz juz nie moge sie dostac .... generalnie z uwagi na to, że w centrali mam serwer proxy wolalbym, żeby cały ruch, nawet internet przechodził przez kanał, chciałbym jednak dostawać się do urządzenia po publicznym IP. Teraz dostaję się tylko po adresie prywatnym.

pysiok83
wannabe
wannabe
Posty: 221
Rejestracja: 21 wrz 2009, 12:06

#8

#8 Post autor: pysiok83 »

garfield
Zrobiłem jak pisałeś wczesniej, niestety niedziała. W skrócie to co chce osiagnac:
Wchodzac z internetu po ssh chcialbym sie dostac do urzadzenia. W tej chwili moge się dostać do urzadzenia jedynie z wewnatrz sieci firmowej.

Mój routing statyczny na SRX w lokalizacji wyglada jak ponizej.
Jak widać: jak chce pogadac z innymi lokalizacjami idz do centrali, jak cos chce pogadac z siecia LAN w lokalizacji idz na IP bramy tej lokalizacji, 3 wpis potrzebny do zestawienia kanalu, ostatni wpis wszytko co nie wiesz gdzie wywalaj do kanalu - w centarli jest proxy i tam ma isc.
routing-options {
static {
route 192.168.0.0/16 next-hop st0.0;
route 192.168.x.0/24 next-hop adres w LAN jaki jest DG dla urzadzen w sieci LAN;
route publiczny SRX - centrala/32 next-hop publiczny SRX lokalizacja;
route 0.0.0.0/0 next-hop st0.0;
}
Czy można to jakoś zrobić bez zbednego kombinowania? Nie chciałbym niepotrzebnie robić route map - np. 2. Może można tylko zdefiniować, że jeśli coś przychodzi z source IP na ssh to route wywalaj na interfejs gdzie jest IP publiczny?

Awatar użytkownika
garfield
CCIE
CCIE
Posty: 2882
Rejestracja: 25 sie 2006, 18:32
Lokalizacja: Gdynia

#9

#9 Post autor: garfield »

pysiok83 pisze:garfield
Zrobiłem jak pisałeś wczesniej, niestety niedziała.
- bo w między czasie wymagania zmieniłeś :)

ja już się trochę pogubiłem co Ty chcesz osiągnąć - najpierw pytasz o PBR'a a teraz że go nie chcesz
Powyższy PBR z NAT'em działa bo nawet to sobie w labie skonfigurowałem - nie wiem jak masz zrobioną całą konfigurację security i rule'i miedzy zone'ami

To co chcesz osiągnąć z tym ssh zrobisz tylko przez zmianę default routing na adres publiczny ponieważ ruch powrotny do klienta ssh musi jakoś wrócić czyli default nie możesz mieć przez tunel (chyba że jesteś w stanie sprecyzować wszystkie adresy publiczne z których się łączysz w co wątpię )

czyli podsumowując masz dwie opcje:
1) default przez publiczny adres + zwykły static routing lub PBR żeby wybrany ruch pchać przez tunel (na podstawie SRC lub DST albo obu)
2) default przez tunel + static routing aby wybrany ruch (np powrotny ssh) pchać przez publiczny adres - ale tutaj jak pisałem musiałbyś znać wszystkie adresy z jakich się łączysz po ssh
Remember that the lab is just looking for reachability and not “optimal reachability”.

pysiok83
wannabe
wannabe
Posty: 221
Rejestracja: 21 wrz 2009, 12:06

#10

#10 Post autor: pysiok83 »

hej!
garfield
Wymagania niecio zmieniłem :) to fakt jednak chodziło mi o samo zastosowanie - przykład na rozwiązanie.

Wracając, ostatecznie chiałbym, żeby cały ruch szedł przez tunel z wyłączeniem tego co przyjdzie na adres publiczny lokalizacji na ssh - wówczas DG jest zmieniany z tunelu na adres publiczny.

Poniżej to co do tej pory mam (routing zamieściłęm wcześniej).
firewall {
filter WAN->SSH {
term 1 {
from {
destination-address {
publiczny lokalizacji/32;
}
destination-port {
ssh;
}
}
then {
routing-instance ROUTE_WLAN->SSH;
}
}
term DEFAULT {
then accept; - czy to oznacza, że ma iść realizaować to co jest w routingu w tej chwili?
}
}
}
routing-instances {
ROUTE_WLAN->SSH {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop publiczny adres bramy w lokalizacji;
}
}
}
}

routing-instances {
ROUTE_WLAN->SSH {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop publiczny adres bramy w lokalizacji;
}
}
}
}
Czy dobrze myślę jak działa to powyżej?
Jak coś przyjdzie na publiczny adres na ssh - czyli host z zewnatrz chce się dodtać do urzadzenia -> zmien DG na ROUTE_WLAN->SSH, pozostały ruch tak jak jest w tablicy routingu z domysłu - czyli ten routing statyczny jaki zamieściłem wcześniej?


PS nie za bardzo ruzumiem tego wpisu:
interface-routes {
rib-group inet all-ribs; - ten wpis z tego co czytałem obsługuje grupy routingu tak?
}

rib-groups { - tu definicja tych grup?
all-ribs {
import-rib [ inet.0 REDIRECT-100-0.inet.0 ]; - inet.0 ? - co to takiego REDIRECT-100-0.inet.0 - ten wpis to w częsci routing zdefiniowany wcześniej, jednak .inet0?
Czy mógłbyś mi to jakoś objasnić?
}
}
PS2 znalazłem coś takiego jeszcze http://www.juniper.net/techpubs/en_US/j ... tions.html
Czy tak mógłbym to zastosowac u mnie?

Przepraszam garfield, że Cię tak zasypuje, jednak dopiero zaczynam prace z SRXem i szukam często odpowiedników w CISCO, jednak tutaj podejscie różni się znacznie.
Dziękuję!!!!!!!

Awatar użytkownika
garfield
CCIE
CCIE
Posty: 2882
Rejestracja: 25 sie 2006, 18:32
Lokalizacja: Gdynia

#11

#11 Post autor: garfield »

hej

dobra jest chwila to odpisze
generalnie to co napisałeś w oparciu o mój post jest dla ruchu przelatującego przez router (zwróć uwagę ze pbr'a masz zapiętego na wejściu na interfejsie lan)
Po zmianie Twojej koncepcji :) czyli w przypadku ruchu generowanego do srx'a lub od srx'a to nie ma zastosowania (ruch nie jest tranzytowy przez srx;a) - np ruch mgmt typu ssh do SRX'a

Przerób swój przykład tak aby łapać ruch self-generated czyli z/do zone'y junos-host
czyli np from zone junos-host to-zone WAN

jeszcze jedno:
w powyższym przykładzie jak chcesz ruch powrotny ssh złapać to powinieneś łapać SRC=ssh a nie DST

DST=ssh, SRC=>1024 jest na kliencie przy łączeniu
serwer odpowiadając używa:
SRC=ssh, DST=>1024

Dzisiaj wieczorem w labie sam z ciekawości sobie takie coś skonfiguruje (do tej pory robiłem tylko dla ruchy tranzytowego)
Remember that the lab is just looking for reachability and not “optimal reachability”.

Awatar użytkownika
garfield
CCIE
CCIE
Posty: 2882
Rejestracja: 25 sie 2006, 18:32
Lokalizacja: Gdynia

#12

#12 Post autor: garfield »

polabowałem trochę i wydaje się że chyba jednak się nie da tak jak Ty chcesz
jest możliwość co prawda złapania ruchu self-generated i przeNATowania go ale raczej nie da sie takiego ruchu zmatchowac pod PBR'a, poza tym w PBR można łapać tylko po DST-PORT, po SRC-PORT nie ma opcji
sprawdzałem na sofcie 12.1

Zostaje Ci przerobienie routingu żeby default był na publiczny IP a wybiórczy ruch przez tunel
Remember that the lab is just looking for reachability and not “optimal reachability”.

pysiok83
wannabe
wannabe
Posty: 221
Rejestracja: 21 wrz 2009, 12:06

#13

#13 Post autor: pysiok83 »

Dzięki!
A jeśli chodzi o wybiórczy ruch przez tunel. Mam to zrobić za pośrednictwem tej opcji firewall i zmianą DG? Tylko czy to wówczas zadziała jak zrobię warunek, że jeśli ruch idzie na publiczny IP lokalizacji głównej, z którą zestawiam kanał po ipsec to ma zmienić DG? To jest taka sama sutacja jak wcześniej. Ruch wchodzi na tym samym interfejsie co ma wyjść (ge-0/0/7). To raczej nie zadziała.

PS a co z loopbackiem? Może użyć loopbacka?
Tak jak pisałem na prv mam drobny problem z tym lo0. Mój ge0/0/7 ma IP publiczny z maską 27 (x.x.x.30/27). Określiłem na tym interfejsie wszytkie publiczne adresy jakie mam od ISP. Na Lo0 ustawiłem adres x.x.x.29/32 (jest to jeden z adresów jaki jest ustawiony na WAN ge0/0/7 przez wskazanie maski 27). Gdy chce z Lo0 wyjść na sewnątrz (pinguje np. adres publiczny inny) to wogóle nie wychodze poza SRX. Tak jakby nie wiedział gdzie ma wyjść. To samo jak od strony WAN chce sie na Lo0 dostać, otrzymuje komunikat od modemu (jaki jest bezpośrednio przyległy do SRX na jakim ustawiłem Lo0), że host nie istnieje.

Awatar użytkownika
garfield
CCIE
CCIE
Posty: 2882
Rejestracja: 25 sie 2006, 18:32
Lokalizacja: Gdynia

#14

#14 Post autor: garfield »

apropo loopbacka to jak Ty sobie to wyobrażasz ? to jest interfejs jak każdy inny, to co chcesz zrobić nie zadziała - temat loopbacka koniec

co do reszty określ routingiem jakie dst pchac przez st0 a default zrób na public next-hopa jakiego dostales od operatora i to wszystko, przy takiej konfiguracji nie potrzebujesz PBR'a
Remember that the lab is just looking for reachability and not “optimal reachability”.

pysiok83
wannabe
wannabe
Posty: 221
Rejestracja: 21 wrz 2009, 12:06

#15

#15 Post autor: pysiok83 »

No wszystko ładnie pięknie :). Tylko jest jeszcze jeden problem. W centrum, do którego pcham ruch jest proxy. Ruch jaki idzie z lokalizacji do serwerów, poczty itp. wszystkie wewnętrzne zasoby mają iść przez kanał VPN. Jest równiez ruch jaki idzie do Internetu itp. wówczas ma on iść poza kanałem, ale do centrum ponieważ tam jest zdefiniowane proxy. Uważam, że nie ma sensu wkładać do kanału VPN ruch do Internetu.
W tym momencie nie za bardzo koncepcja podana wcześniej się sprawdzi. Chyba, że jakoś inaczej jeszcze można to zrobic?

ODPOWIEDZ