juniper srx - routing - routemap?
juniper srx - routing - routemap?
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?
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?
w skrócie ruch z 192.168.100.0/24 pchaj przez GW 192.168.224.2 a resztę normalnie
nat'a jakiegoś musisz dodać, żeby np na adres interfejsu tłumaczył
np
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;
}
}
}
}
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”.
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;
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 przykladziepysiok83 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;
Remember that the lab is just looking for reachability and not “optimal reachability”.
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'iepysiok83 pisze:tylko w tym przykładzie nie widze wpisu ściezki domyslnej.
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;
}
}
Remember that the lab is just looking for reachability and not “optimal reachability”.
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.
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.
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.
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?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;
}
- bo w między czasie wymagania zmieniłeśpysiok83 pisze:garfield
Zrobiłem jak pisałeś wczesniej, niestety niedziała.
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”.
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).
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:
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ę!!!!!!!
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).
Czy dobrze myślę jak działa to powyżej?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;
}
}
}
}
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:
PS2 znalazłem coś takiego jeszcze http://www.juniper.net/techpubs/en_US/j ... tions.htmlinterface-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ć?
}
}
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ę!!!!!!!
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)
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”.
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
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”.
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.
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.
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
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”.
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?
W tym momencie nie za bardzo koncepcja podana wcześniej się sprawdzi. Chyba, że jakoś inaczej jeszcze można to zrobic?