瞻博(Juniper)的SRX建立×××站点比较简单,NAT的运用也简单,我要谈的是他们之间的联合运用。
要求的情况:
本地A和一个地方B建立×××站点连接,一个远程地方C通过专线到达本地,该远程只有到达本地A的路由,而且不能添加路由。要求远程C通过本地A访问×××站点B。
先来看一下×××站点的配置,虽说很简单,还是贴一下配置。该SRX是11.4R6.6的版本
security {
ike {
proposal pre-g2-aes128-sha1 {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm aes-128-cbc;
lifetime-seconds 28800;
}
policy RemoteIKE {
mode main;
proposals pre-g2-aes128-sha1;
pre-shared-key ascii-text "*****************"; ## SECRET-DATA
}
ike {
proposal pre-g2-aes128-sha1 {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm aes-128-cbc;
lifetime-seconds 28800;
}
policy RemoteIKE {
mode main;
proposals pre-g2-aes128-sha1;
pre-shared-key ascii-text "*****************"; ## SECRET-DATA
}
gateway RemoteGW {
ike-policy RemoteIKE;
address 36.*.*.89;
ike-policy RemoteIKE;
address 36.*.*.89;
external-interface ge-0/0/0;
version v1-only;
}
version v1-only;
}
ipsec {
proposal esp-3des-sha1 {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 3600;
}
proposal esp-3des-sha1 {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 3600;
}
policy g2-esp-3des-sha1 {
perfect-forward-secrecy {
keys group2;
}
proposals esp-3des-sha1;
}
perfect-forward-secrecy {
keys group2;
}
proposals esp-3des-sha1;
}
*** Remote××× {
bind-interface st0.2;
***-monitor {
optimized;
}
ike {
gateway RemoteGW;
ipsec-policy g2-esp-3des-sha1;
}
establish-tunnels on-traffic;
}
bind-interface st0.2;
***-monitor {
optimized;
}
ike {
gateway RemoteGW;
ipsec-policy g2-esp-3des-sha1;
}
establish-tunnels on-traffic;
}
routing-options {
static {
route 0.0.0.0/0 next-hop 122.*.*.185;
route 172.24.60.0/24 next-hop st0.2;
}
static {
route 0.0.0.0/0 next-hop 122.*.*.185;
route 172.24.60.0/24 next-hop st0.2;
}
}
看到这里,估计能看出来×××站点B的地址就是172.24.60.0/24,远程C的地址是172.16.0.0/16,本地A是172.18.0.0/16,远程C只有到172.26.0.0/16的路由,而没有到172.24.60.0/24,同样×××站点B也没有到远程C的路由,那么不能用了?
NAT的联合运用可以解决这个问题。
SRX的NAT分3大类,source、destination、static,源地址NAT里面可以再分为地址池和接口两种,就是把源地址替换成地址池的地址还是指定接口的地址,destination和static很相似,都是换目的地址的,但是有区别,destination用地址池,是轮换着使用的,static则是定位固化变换。另外说一下他们3个的执行顺序,静态〉目的〉源,还要说一下他们和其它的执行顺序,路由是低于NAT的,×××是低于路由的(这里用的是基于路由的×××站点),最终执行的顺序是:静态NAT〉目的NAT〉策略〉源NAT〉路由〉×××。
这里第一次出现了策略,因为牵扯到NAT的变换,到底是用变换前的地址还是后呢?
就以本例来说明。
C地点是172.16.0.0/16,我们让C访问172.18.60.0/24,这样就可以到达本地A了,在A通过源地址NAT转换把源地址为172.18.12.0/24,通过静态NAT转换把172.18.60.0/24为172.24.60.0/24,这样就变成本地A访问×××站点的B了。
那么策略的地址该如何?
172.16.0.0/16-〉172.24.60.0/24
我们看到排序,静态NAT是先执行,先把目的地址换成了172.24.60.0/24,这时候的包源地址是172.16.0.0/16,目的是172.24.60.0/24,以这样的状态过策略,策略通过之后继续源NAT,把源地址换成172.18.12.0/24,到×××站点B之后就是符合要求的。
我们来看一下配置。
nat {
source {
pool ManCo {
routing-instance {
ManCo;
}
address {
172.18.12.0/24;
}
port no-translation;
}
rule-set ShangHai-ManCo {
from zone ManIN;
to zone ManCo×××;
rule ShangHai {
match {
source-address 172.16.0.0/24;
destination-address 172.24.60.0/24;
}
then {
source-nat {
pool {
ManCo;
}
}
}
} 172.16.0.0/24
}
}
static {
rule-set 5rt {
from zone ManIN;
rule 5rt-r {
match {
destination-address 172.18.60.0/24;
}
then {
static-nat {
prefix {
172.24.60.0/24;
}
} 172.16.0.0/24
}
}
}
}
}
静态NAT的变换是一一对应,访问172.18.60.1就变172.24.60.1,访问172.18.60.2就变172.24.60.2,这和源地址NAT最大不同, 172.16.0.1的源地址访问同一个172.24.60.1,一次session访问变成172.18.12.1,2次session的时候就变成172.18.12.2了。
source {
pool ManCo {
routing-instance {
ManCo;
}
address {
172.18.12.0/24;
}
port no-translation;
}
rule-set ShangHai-ManCo {
from zone ManIN;
to zone ManCo×××;
rule ShangHai {
match {
source-address 172.16.0.0/24;
destination-address 172.24.60.0/24;
}
then {
source-nat {
pool {
ManCo;
}
}
}
} 172.16.0.0/24
}
}
static {
rule-set 5rt {
from zone ManIN;
rule 5rt-r {
match {
destination-address 172.18.60.0/24;
}
then {
static-nat {
prefix {
172.24.60.0/24;
}
} 172.16.0.0/24
}
}
}
}
}
静态NAT的变换是一一对应,访问172.18.60.1就变172.24.60.1,访问172.18.60.2就变172.24.60.2,这和源地址NAT最大不同, 172.16.0.1的源地址访问同一个172.24.60.1,一次session访问变成172.18.12.1,2次session的时候就变成172.18.12.2了。
转载于:https://blog.51cto.com/xushen/1156078