Thoughts on successful openvpn Configuration

Server
1.
Root @ Ubuntu :~ # Ifconfig
As0t0 link encap: The hardware address is not specified. 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
Inet address: 5.5.0.1 point-to-point: 5.5.0.1 mask: 255.255.248.0
Up pointopoint running noarp multicast MTU: 1500 hops: 1
Received data packet: 0 error: 0 discard: 0 overload: 0 frames: 0
Packet sending: 0 error: 0 discard: 0 overload: 0 carrier: 0
Collision: 0 sending queue length: 200
Received byte: 0 (0.0 B) sent byte: 0 (0.0 B)

As0t1 link encap: The hardware address is not specified. 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
Inet address: 5.5.8.1 point-to-point: 5.5.8.1 mask: 255.255.248.0
Up pointopoint running noarp multicast MTU: 1500 hops: 1
Received data packet: 7072 error: 0 discard: 0 overload: 0 frames: 0
Send data packets: 6776 error: 0 discard: 0 overload: 0 carrier: 0
Collision: 0 sending queue length: 200
Received byte: 703269 (703.2 KB) sent byte: 2863127 (2.8 MB)

Eth0 link encap: Ethernet hardware address 00: 1E: EC: C3: 07: 38
Inet address: 219.245.89.89 broadcast: 219.245.89.255 mask: 255.255.255.0
Inet6 address: fe80: 21E: ecff: fec3: 738/64 scope: Link
Up broadcast running Multicast MTU: 1500 hops: 1
Received data packet: 95993 error: 0 discard: 0 overload: 0 frames: 0
Send data packets: 90551 error: 0 discard: 0 overload: 0 carrier: 0
Collision: 0 sending queue length: 1000
Received byte: 36113891 (36.1 MB) sent byte: 51139258 (51.1 MB)
Interrupt: 18 base address: 0xd800

Eth1 link encap: Ethernet hardware address 00: E0: 4C: F0: 26: E1
Inet address: 192.168.0.1 broadcast: 192.168.0.255 mask: 255.255.255.0
Inet6 address: fe80: 2e0: 4cff: fef0: 26e1/64 scope: Link
Up broadcast running Multicast MTU: 1500 hops: 1
Received data packet: 19317 error: 0 discard: 0 overload: 0 frames: 0
Send data packets: 20911 error: 0 discard: 0 overload: 0 carrier: 0
Collision: 0 sending queue length: 1000
Received byte: 2919480 (2.9 MB) sent byte: 20111031 (20.1 MB)
Interrupt: 19 base address: 0xd400

Lo link encap: local loopback
Inet address: 127.0.0.1 mask: 255.0.0.0
Inet6 address: 1/128 scope: Host
Up loopback running MTU: 16436 hops: 1
Received data packet: 11028 error: 0 discard: 0 overload: 0 frames: 0
Send data packets: 11028 error: 0 discard: 0 overload: 0 carrier: 0
Collision: 0 sending queue length: 0
Received byte: 41685343 (41.6 MB) sent byte: 41685343 (41.6 MB)
Analysis:
According to the number of bytes received and sent by as0t0 as 0, as0t0 is useless. What is the use of this virtual network card? Or why does the server have two virtual NICs? 5.5.0.1 and 5.5.8.1 are not a network segment under the subnet mask 255.255.248.0! 5.5.0.1/21 indicates 5.5.0.1 -- 5.5.7.255 and 5.5.8.1 indicates 5.5.8.1 -- 5.5.15.255 (calculation method: the first 21 bits in 5.5.8.1 remain unchanged, and the remaining bits are all 1)
What is point-to-point understanding here?

2.
Root @ Ubuntu :~ # Route-n
Kernel IP route table
Target gateway subnet mask flag hop reference Interface
219.245.89.0 0.0.0.0 255.255.255.0 u 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 u 0 0 0 eth1
5.5.0.0 0.0.0.0 255.255.248.0 u 0 0 0 as0t0
5.5.8.0 0.0.0.0 255.255.248.0 u 0 0 as0t1
169.254.0.0 0.0.0.0 255.255.0.0 u 1000 0 0 eth1
0.0.0.0 219.245.89.254 0.0.0.0 ug 0 0 0 eth0
Analysis:
The destination CIDR Block 5.5.8.0/255.255.248.0 is the virtual CIDR Block of the client,
But what about the 5.5.0.0/255.255.248.0 network segment?
How about removing this route?
Route del-net 5.5.0.0 netmask restart 255.248.0 (terminal operation, no network restart operation );
Deleting this route does not affect the ping to Baidu;
But Delete another one.
Route del-net 5.5.8.0 netmask 255.255.248.0
The client pinging Baidu does not respond, but the intercepted packets can still be viewed on the server!
Add route add-net 5.5.8.0 netmask after route 248.0 Dev as0t1
The client can ping Baidu again to respond !!

To sum up, the route whose destination address is 5.5.8.0 is related to forwarding. Remove this route,
The server can still see the intercepted packets (interception should be related to the client, that is, to whom the client is encapsulated ),
But not forwarded!

3. I still need to check iptables for forwarding.
Root @ Ubuntu :~ # Iptables-save
# Generated by iptables-save v1.4.4 on Wed Aug 22 16:11:05 2012
* Mangle
: Prerouting accept [37781: 3441345]
: Input accept [83316: 56485864]
: Forward accept [29705: 11635358]
: Output accept [72943: 88733163]
: Postrouting accept [102557: 100363435]
: As0_mangle_pre_rel_est-[0: 0]
: As0_mangle_tun-[0: 0]
-A prerouting-M state -- state related, established-J as0_mangle_pre_rel_est
-A prerouting-I as0t +-J as0_mangle_tun
-A as0_mangle_pre_rel_est-J accept
-A as0_mangle_tun-J mark -- Set-xmark 0x2000000/0 xffffffff
-A as0_mangle_tun-J accept
Commit
# Completed on Wed Aug 22 16:11:05 2012
# Generated by iptables-save v1.4.4 on Wed Aug 22 16:11:05 2012
* Nat
: Prerouting accept [16598: 1611064]
: Output accept [2931: 189542]
: Postrouting accept [2931: 189542]
: As0_nat-[0: 0]
: As0_nat_post_rel_est-[0: 0]
: As0_nat_pre-[0: 0]
: As0_nat_pre_rel_est-[0: 0]
: As0_nat_test-[0: 0]
-A prerouting-M state -- state related, established-J as0_nat_pre_rel_est
-A postrouting-M state -- state related, established-J as0_nat_post_rel_est
-A postrouting-m mark -- mark 0x2000000/0x2000000-J as0_nat_pre
-A postrouting-s 192.168.0.0/24-O eth0-J Masquerade
-A postrouting-s 192.168.1.0/24-O eth0-J Masquerade
-A as0_nat-O eth0-j snat -- to-source 219.245.89.89
-A as0_nat-O eth1-j snat -- to-source 192.168.0.1
-A as0_nat-J accept
-A as0_nat_post_rel_est-J accept
-A as0_nat_pre-D 5.5.0.0/20-J as0_nat_test
-A as0_nat_pre-D 192.168.0.0/16-J as0_nat_test
-A as0_nat_pre-D 172.16.0.0/12-J as0_nat_test
-A as0_nat_pre-D 10.0.0.0/8-J as0_nat_test
-A as0_nat_pre-J as0_nat
-A as0_nat_pre_rel_est-J accept
-A as0_nat_test-O as0t +-J accept
-A as0_nat_test-D 5.5.0.0/20-J accept
-A as0_nat_test-J as0_nat
Commit
# Completed on Wed Aug 22 16:11:05 2012
# Generated by iptables-save v1.4.4 on Wed Aug 22 16:11:05 2012
* Filter
: Input accept [28141: 2771549]
: Forward drop [124: 7519]
: Output accept [72665: 88709799]
: As0_accept-[0: 0]
: As0_in-[0: 0]
: As0_in_post-[0: 0]
: As0_in_pre-[0: 0]
: As0_out-[0: 0]
: As0_out_local-[0: 0]
: As0_out_s2c-[0: 0]
: As0_webaccept-[0: 0]
-A input-M state -- state related, established-J as0_accept
-A input-I lo-J as0_accept
-A input-m mark -- mark 0x2000000/0x2000000-J as0_in_pre
-A input-D 219.245.89.89/32-p udp-M state -- state new-m udp -- dport 1194-J as0_accept
-A input-D 219.245.89.89/32-p tcp-M state -- state new-m tcp -- dport 443-J as0_accept
-A input-M state -- state related, established-J as0_webaccept
-A input-D 219.245.89.89/32-p tcp-M state -- state new-m tcp -- dport 943-J as0_webaccept
-A forward-M state -- state related, established-J as0_accept
-A forward-m mark-mark 0x2000000/0x2000000-J as0_in_pre
-A forward-O as0t +-J as0_out_s2c
-A forward-M state -- state related, established-J accept
-A forward-M Mac -- Mac-source 00: 16: D3: BA: FC: E6-J accept
-A forward-M Mac -- Mac-source 20: 6a: 8A: 43: BA: E3-J accept
... Mac whitelist omitted
-A output-O as0t +-J as0_out_local
-A as0_accept-J accept
-A as0_in-D 5.5.0.1/32-J accept
-A as0_in-D 192.168.0.0/24-J accept
-A as0_in-J as0_in_post
-A as0_in_post-O as0t +-J as0_out
-A as0_in_post-J Drop
-A as0_in_pre-D 5.5.0.0/20-J as0_in
-A as0_in_pre-D 192.168.0.0/16-J as0_in
-A as0_in_pre-D 172.16.0.0/12-J as0_in
-A as0_in_pre-D 10.0.0.0/8-J as0_in
-A as0_in_pre-J accept
-A as0_out-J Drop
-A as0_out_local-p icmp-m icmp -- ICMP-type 5-J Drop
-A as0_out_local-J accept
-A as0_out_s2c-J as0_out
-A as0_webaccept-J accept
Commit
# Completed on Wed Aug 22 16:11:05 2012

Analysis of iptables:
1. After iptables rules are cleared, the VPN cannot be used normally.
(Supplement: import the rule to the file: iptables-Save & gt; myiptables.txt import the file content to iptables: iptables-Save & lt; myiptables.txt)
2/key analysis NAT table-A as0_nat-O eth0-j snat -- to-source 219.245.89.89
-A as0_nat-O eth1-j snat -- to-source 192.168.0.1

Figure: server-side packet capture