Имею такую лабораторию: SRX220H и 2 хоста.
Host1 (IP-address 192.168.1.100/24) connected to SRX interface ge-0/0/1 (interface address 192.168.1.1/24);
Host2 (IP-address 10.10.1.100/24) connected to SRX interface ge-0/0/2 (interface address 10.10.1.1/24);
Таким образом, я могу пинговать с Host1 (IP-адрес 192.168.1.100/24), интерфейс ge-0/0/2 (адрес интерфейса 10.10.1.1/24), НО НЕ МОГУ пинговать с Host1 (IP-адрес 192.168.1.100/24). ) Host2 (IP-адрес 10.10.1.100/24)
Также я могу пинговать с Host2 (IP-адрес 10.10.1.100/24) по интерфейсу ge-0/0/1 (адрес интерфейса 192.168.1.1/24); НО НЕ МОГУТ пинговать с Host2 (IP-адрес 10.10.1.100/24) Host1 (IP-адрес 192.168.1.100/24).
root# run show configuration
## Last commit: 2013-04-18 17:10:04 GMT+5 by root
version 11.2R4.3;
system {
time-zone GMT+5;
root-authentication {
encrypted-password "$1$aOk8oeeK$ECtJa89jmEN22kQEHi9z./"; ## SECRET-DATA
}
name-server {
208.67.222.222;
208.67.220.220;
}
services {
ssh;
telnet;
xnm-clear-text;
web-management {
http {
interface vlan.0;
}
https {
system-generated-certificate;
interface vlan.0;
}
}
}
syslog {
archive size 100k files 3;
user * {
any emergency;
}
file messages {
any critical;
authorization info;
}
file interactive-commands {
interactive-commands error;
}
file prb1 {
any any;
match 192.1.1.1;
}
}
max-configurations-on-flash 5;
max-configuration-rollbacks 5;
license {
autoupdate {
url https://ae1.juniper.net/junos/key_retrieval;
}
}
}
interfaces {
ge-0/0/1 {
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 10.10.1.1/24;
}
}
}
}
protocols {
stp;
}
security {
flow {
traceoptions {
file tshoot;
flag basic-datapath;
packet-filter ping1 {
source-prefix 192.168.1.100/32;
destination-prefix 10.10.1.100/24;
}
}
}
policies {
from-zone lan to-zone lan {
policy lan-to-lan {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
log {
session-init;
session-close;
}
count;
}
}
}
}
zones {
security-zone lan {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
ge-0/0/1.0 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
ge-0/0/2.0;
}
}
}
}
Результат pinging Host2 (IP-адрес 10.10.1.100/24) от Host1 (IP-адрес 192.168.1.100/24)
На мой взгляд, это странные вещи при отладке в следующих строках:
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: choose interface ge-0/0/2.0 as outgoing phy if
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: route lookup: dest-ip 192.168.1.100 orig ifp ge-0/0/1.0 output_ifp ge-0/0/1.0 orig-zone 6 out-zone 6 vsd 0
root# run show log tshoot
Apr 18 17:22:51 clear-log[3459]: logfile cleared
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:<192.168.1.100/54->10.10.1.100/1;1> matched filter ping1:
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:packet [60] ipid = 5479, @423fda1e
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 13, common flag 0x0, mbuf 0x423fd800, rtbl_idx = 0
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: flow process pak fast ifl 68 in_ifp ge-0/0/1.0
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: ge-0/0/1.0:192.168.1.100->10.10.1.100, icmp, (8/0)
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: find flow: table 0x4ed7f820, hash 59760(0xffff), sa 192.168.1.100, da 10.10.1.100, sp 54, dp 1, proto 1, tok 6
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: no session found, start first path. in_tunnel - 0, from_cp_flag - 0
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: flow_first_create_session
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: flow_first_in_dst_nat: in <ge-0/0/1.0>, out <N/A> dst_adr 10.10.1.100, sp 54, dp 1
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: chose interface ge-0/0/1.0 as incoming nat if.
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:flow_first_rule_dst_xlate: DST no-xlate: 0.0.0.0(0) to 10.10.1.100(1)
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:flow_first_routing: vr_id 0, call flow_route_lookup(): src_ip 192.168.1.100, x_dst_ip 10.10.1.100, in ifp ge-0/0/1.0, out ifp N/A sp 54, dp 1, ip_proto 1, tos 0
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:Doing DESTINATION addr route-lookup
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: routed (x_dst_ip 10.10.1.100) from lan (ge-0/0/1.0 in 0) to ge-0/0/2.0, Next-hop: 10.10.1.100
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: policy search from zone lan-> zone lan (0x0,0x360001,0x1)
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: app 0, timeout 60s, curr ageout 60s
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:flow_first_src_xlate: nat_src_xlated: False, nat_src_xlate_failed: False
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:flow_first_src_xlate: src nat returns status: 0, rule/pool id: 0/0, pst_nat: False.
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: dip id = 0/0, 192.168.1.100/54->192.168.1.100/54 protocol 0
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: choose interface ge-0/0/2.0 as outgoing phy if
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:is_loop_pak: No loop: on ifp: ge-0/0/2.0, addr: 10.10.1.100, rtt_idx:0
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:jsf sess interest check. regd plugins 19
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: Allocating plugin info block for 19 plugin(s) from OL
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:-jsf int check: plugin id 2, svc_req 0x0. rc 4
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:-jsf int check: plugin id 3, svc_req 0x0. rc 4
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:-jsf int check: plugin id 5, svc_req 0x0. rc 4
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:-jsf int check: plugin id 6, svc_req 0x0. rc 4
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:-jsf int check: plugin id 7, svc_req 0x2. rc 4
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:-jsf int check: plugin id 8, svc_req 0x0. rc 4
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:-jsf int check: plugin id 11, svc_req 0x0. rc 4
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:+++++++++++jsf_test_plugin_data_evh: 3
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:-jsf int check: plugin id 12, svc_req 0x0. rc 4
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:-jsf int check: plugin id 13, svc_req 0x0. rc 4
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:-jsf int check: plugin id 14, svc_req 0x0. rc 4
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:-jsf int check: plugin id 17, svc_req 0x0. rc 2
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:-jsf int check: plugin id 18, svc_req 0x0. rc 4
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: No JSF plugins enabled for session
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: Releasing plugin info block for 19 plugin(s) to OL
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:flow_first_service_lookup(): natp(0x4b8f66b8): app_id, 0(0).
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: service lookup identified service 0.
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: flow_first_final_check: in <ge-0/0/1.0>, out <ge-0/0/2.0>
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:construct v4 vector for nsp2
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: existing vector list 200-456272a0.
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: Session (id:6216) created for first pak 200
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: flow_first_install_session======> 0x4b8f66b8
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: nsp 0x4b8f66b8, nsp2 0x4b8f6738
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: make_nsp_ready_no_resolve()
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: route lookup: dest-ip 192.168.1.100 orig ifp ge-0/0/1.0 output_ifp ge-0/0/1.0 orig-zone 6 out-zone 6 vsd 0
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: route to 192.168.1.100
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:no need update ha
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:Installing c2s NP session wing
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:Installing s2c NP session wing
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: flow got session.
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: flow session id 6216
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: vector bits 0x200 vector 0x456272a0
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT:mbuf 0x423fd800, exit nh 0x80010
Apr 18 17:22:59 17:22:58.1648803:CID-0:RT: ----- flow_process_pkt rc 0x0 (fp rc 0)
НЕКОТОРЫЕ ПОЛЕЗНЫЕ ТЕСТЫ
root# run ping 10.10.1.100 source 10.10.1.1
PING 10.10.1.100 (10.10.1.100): 56 data bytes
64 bytes from 10.10.1.100: icmp_seq=0 ttl=128 time=3.797 ms
64 bytes from 10.10.1.100: icmp_seq=1 ttl=128 time=1.999 ms
^C
--- 10.10.1.100 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.999/2.898/3.797/0.899 ms
Test2
root# run ping 10.10.1.100 source 192.168.1.1
PING 10.10.1.100 (10.10.1.100): 56 data bytes
^C
--- 10.10.1.100 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
Test3
root# run ping 192.168.1.100 source 192.168.1.1
PING 192.168.1.100 (192.168.1.100): 56 data bytes
64 bytes from 192.168.1.100: icmp_seq=0 ttl=128 time=15.049 ms
64 bytes from 192.168.1.100: icmp_seq=1 ttl=128 time=2.193 ms
^C
--- 192.168.1.100 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.193/8.621/15.049/6.428 ms
Test4
root# run ping 192.168.1.100 source 10.10.1.1
PING 192.168.1.100 (192.168.1.100): 56 data bytes
^C
--- 192.168.1.100 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
Test5
root# run ping 10.10.1.1 source 192.168.1.1
PING 10.10.1.1 (10.10.1.1): 56 data bytes
64 bytes from 10.10.1.1: icmp_seq=0 ttl=64 time=0.809 ms
64 bytes from 10.10.1.1: icmp_seq=1 ttl=64 time=0.685 ms
^C
--- 10.10.1.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.685/0.747/0.809/0.062 ms
Test6
root# run show route
inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.1.0/24 *[Direct/0] 00:13:13
> via ge-0/0/2.0
10.10.1.1/32 *[Local/0] 00:52:39
Local via ge-0/0/2.0
192.168.1.0/24 *[Direct/0] 00:47:46
> via ge-0/0/1.0
192.168.1.1/32 *[Local/0] 00:52:39
Local via ge-0/0/1.0
Не могли бы вы прислать мне пример конфигурации для SRX220 с некоторыми напрямую подключенными сетями в одной зоне безопасности с разрешенным пингом между хостами в этих сетях?
Поместите оба интерфейса в одну зону:
set security zones security-zone trust interface ge-0/0/2.0
set security zones security-zone trust interface ge-0/0/3.0
Создайте политику для разрешения внутризонального трафика.
set security policies from-zone trust to-zone trust policy trust-to-trust match source-address any destination address any application any
set security policies from-zone trust to-zone trust policy trust-to-trust then permit
Это все, что нужно, вы также можете регистрировать и подсчитывать трафик. Все это легко доступно в документации. Мой синтаксис может быть несовершенным, поскольку передо мной нет устройства Junos, чтобы очистить этот код.