Shulou(Shulou.com)06/02 Report--

Table of contents:

(1) configuration of tcpwraps

(2) the concept of Firewalld

(3) configure firewall

(IV) use man firewalld.richlanguage

As we all know, compared with the intranet, the external public network environment is even worse, full of crimes. Although the firewall which acts as a protective barrier between the public network and the intranet can be divided into software and hardware, its main function is to filter the traffic passing through the firewall itself according to the policy. The firewall policy can be customized based on the source address, destination address, port number, protocol, application and other information of the traffic, and then the firewall uses pre-customized policy rules to monitor the incoming and outgoing traffic. If the traffic matches a certain policy rule, the corresponding processing is performed, otherwise it is discarded. In this way, only legitimate traffic can be guaranteed to flow between the intranet and the external public network.

(1) configuration of tcpwraps

There are several firewalls in the RHEL 7 system, one of which is tcpwraps. Tcpwraps mainly involves two configuration files: / etc/hosts.allow file and / etc/hosts.deny configuration file. The configuration syntax in the configuration file is mainly "daemon: client". For example, there is a sshd service in our system. When this service is running, there is essentially a program running in the background (figure 1-3). If it is configured in the hosts.allow file, the specified client is allowed to access the service. If it is configured in the hosts.deny file, it is allowed to access the service. Then the specified client is not allowed to access the service. When we specify the client, if we fill in the subnet mask, we do not support the representation of / 24 directly, but must be written completely as the representation of / 255.255.255.0 (figure 1-2).

# ps aux | grep-v grep | grep sshd

(1.2) then let's take a look at the matching rules of tcpwraps. First, go to hosts.allow to match. If the match is successful, the system is allowed to access the matching address, and then it will no longer match in hosts.deny. If the match is not successful in hosts.allow, it will match in hosts.deny. If the match is successful in hosts.deny, the system will deny the matching address access. If there is no match in hosts.deny, the system allows access through this address by default, which is consistent with the effect of not specifying this entry.

By default, when no tcpwraps rules are set, the vms002 host can normally connect to the vms001 host using the ssh service.

We configure the hosts.allow of the vms001 host to allow all hosts in the 192.168.26.0 network segment to access the ssh service of the vms001 host. At this time, we find that the vms002 host can still access the ssh service of the vms001 host.

Note: the modified entries in the hosts.allow configuration file will automatically take effect immediately after the modification.

(1.5) We have added an entry to allow 192.168.26.102 hosts in the / etc/hosts.allow configuration file and / etc/hosts.deny configuration file of the vms001 host. At this time, the entry in the hosts.allow configuration file has been passed in the system first, so the entry in the hosts.deny configuration file will not be executed, so the vms002 host can access the ssh service of the vms001 host normally.

Then we set allow 192.168.26 in the / etc/hosts.allow configuration file of the vms001 host. That is, all hosts in the 26.0 network segment are allowed to pass, and the 192.168.26.102 host is not allowed in the / etc/hosts.deny configuration file. At this time, since the comparison of the hosts.allow file is first performed, and then the comparison of the hosts.deny file is performed, the vms002 host can still access the ssh service of the vms001 host normally.

(1.7) one of the following situations is that we set in the / etc/hosts.allow configuration file of the vms001 host to allow all hosts in the 192.168.26.0 network segment, but there is no configuration in the / etc/hosts.deny configuration file except 192.168.26.102. Although the 192.168.26.102 host is allowed to pass, the system also allows it by default. So at this point, the vms002 host can still access the ssh service of the vms001 host normally (figure 1-9). When we set the 192.168.26.102 host in the / etc/hosts.deny configuration file, the vms002 host cannot access the ssh service of the vms001 host (figure 1-10 and figure 1-11).

In general, in order to ensure security, after we specify the accessible hosts in the / etc/hosts.allow file, we should also specify in the / etc/hosts.deny file that all other hosts are inaccessible, so as to improve the security of the system. At this time, we can still log in to the ssh service of the vms001 host normally on the vms002 host, but the hosts with other IP addresses cannot log in to the ssh service of the vms001 host. At this time, if we want other hosts to be able to access the ssh service of the vms001 host, we can first log in to the vms002 host, and then log in to the vms001 host through the vms002 host springboard. At this time, the vms002 host will realize the function of "fortress machine".

Configure in / etc/hosts.allow:

# sshd: 192.168.26.102/255.255.255.0

Configure in / etc/hosts.deny:

# sshd: ALL

(1.9) tcpwraps can play a good role in access control. By using the ldd command, we can check that tcpwraps can access the sshd service (figure 1-14). After we install the vsftpd service, we use the ldd command to check, and find that tcpwraps can also control the access to the vsftpd service (figure 1-15) After installing the httpd service, it is found that tcpwraps does not have access control over the httpd service because the httpd service is not linked to the tcpwraps module (figure 1-16).

Note: if we want to know more about the use of hosts allow, we can use # man hosts.allow to query.

# ldd which sshd | grep wrap

# yum install vsftpd-y

# ldd which vsftpd | grep wrap

# yum install httpd-y

(2) the concept of Firewalld

(2.1) in RHEL 7 series systems, firewalld firewall replaces iptables firewall. For readers who have come into contact with Linux system early or have studied RHEL 6 system, they will inevitably have resistance when they find that the knowledge they once mastered is no longer applicable in RHEL 7 and need to learn firewalld completely. In fact, iptables and firewalld are not the true face of a firewall, they are just firewall management tools used to define firewall policies, or rather, they are just a service. Iptables services hand over the configured firewall policies to the kernel-level netfilter network filter, while firewalld services hand over the configured firewall policies to the kernel-level nftables packet filtering framework. In other words, there are actually several firewall management tools in the Linux system, which are designed to facilitate operators to manage the firewall policies in the Linux system. We only need to configure one of them properly. Although these tools have their own advantages and disadvantages, they are consistent in the configuration of firewall policies. As long as we choose one of several firewall management tools and learn it thoroughly, it will be enough to meet the needs of daily work.

(2.2) there are multiple firewalls in RHEL 7 systems, such as firewalld, iptables, ebtables, ipv6tables, etc., but RHEL 7 systems use firewalld firewalls by default. When we use Firewalld firewall, we can configure it mainly through graphical interface and command line, and here we use two ways to work together.

(3) configure firewall

(3. 1) through the graphical interface, we find that the zone section shows all the zones of the firewall. On the command line, we can get information about all areas of the firewall through get-zones (figure 1-19).

# firewall-config &

# firewall-cmd-get-zones

We know that each Nic will need to be associated with a certain zone. If a Nic is not associated with any zone, the default zone will be used. Through the graphical interface, we can know that the default zone is trusted, and all packets are allowed to pass by default.

# firewall-cmd-get-default-zone

(3.3) if we want to modify the default area of the firewall, we can use the "option"-- "change default area" operation (figure 1-22 and figure 1-23). If we want to modify it through the command line, we can set it through the parameters of set-default-zone, and we can set the default area to public (figure 1-24)

# firewall-cmd-set-default-zone=public

(3.4) by default, all NICs are associated with the default zone. In this case, our default zone is public, so the Nic eno16777728 is associated with public. Then we try to change the default zone to trusted, and we can find that the Nic eno16777728 is also automatically associated with the trusted modified to the default zone.

# firewall-cmd-get-zone-of-interface=eno16777728

# firewall-cmd-set-default-zone=trusted

(3.5) if we want to change the interface Nic eno16777728 in the default public area to associate with the zone in the home area, if we add the eno16777728 Nic directly in the home area, then the system will pop up the zone conflict message (figure 1-26). Since each Nic can only be associated with one area, we should first remove the eno16777728 from the public area and then add it to the home area. At this time, we can normally associate the Nic with the home area through the graphical interface (Fig. 1-27 and Fig. 1-28).

# firewall-cmd-- remove-interface=eno16777728--- removes the Nic from the public area

(3.6) if we delete the Nic from the zone using the remove-interface parameter, the default zone of the firewall is public, but the Nic is associated with the home zone, so we also need to specify the zone when deleting it. If we use add-interface to add the eno16777728 network card, when no zone is specified, then the system will add the network card to the default zone public.

# firewall-cmd-remove-interface=eno16777728-zone=home

# firewall-cmd-add-interface=eno16777728

Now our network card eno16777728 is in the public area. If we want to modify the network card to the zone of other areas, we can use change-interface, for example, we modify the network card directly into the home area.

# firewall-cmd-- change-interface=eno16777728-- zone=home--- modifies the Nic directly to the home area

# firewall-cmd-get-zone-of-interface=eno16777728

(3.8) now we still set the network card eno16777728 in the public area. First, we start the httpd service and set the home page information. At this time, we try to log in to the home page of the vms001 host on the vms002 host and find that we cannot log in (figure 1-32). Then we check the http service in the public area to pass, and you can log in to the vms001 home page normally (figure 1-34). Then we implement it on the command line, first getting all the services in the system through get-services (figure 1-35), then we query whether the http service in the default public area is checked, and use add-service to add http service, and use remove-service to remove http service (figure 1-36).

# firewall-cmd-- get-services | grep http--- gets all the services in the system and queries whether the http service contains

# firewall-cmd-- query-service=http--- queries whether the http service is checked

# firewall-cmd-add-service=http--- checks the http service for the default region

# firewall-cmd-remove-service=http--- removes http services from the default area

(3.9) the above firewall settings are only temporary. If you restart the firewall service, you will find that the http service is unchecked, and the http service cannot be accessed normally. Through the graphical interface settings, we can choose to take effect permanently, and then check the http service in the public area, and after the firewall service is restarted, we can still access the http service normally (figure 1-38). If we only check the http service in the permanent configuration, but the http service is not checked in the runtime configuration, because the permanent configuration must be restarted before it will take effect, the currently running environment does not allow access to the http service. Through the command line, we should write persistent state parameters by adding "--permanent" (figure 1-39).

# firewall-cmd-query-service=http

# systemctl restart firewalld.service--- restart the service

# firewall-cmd-- add-service=http--- sets the firewall to allow http service access

# firewall-cmd-- add-service=http-- permanent--- writes configuration to persistent state

# firewall-cmd-- remove-service=http--- removes the firewall to allow access to http services

# firewall-cmd-- remove-service=http-- permanent--- writes configuration to persistent state

(3.10) sometimes we may use a non-standard port to run the service, the second let's look at the "port", for example, if we use port 808 to run the http service, when we tick http in the service configuration, we will find that we still can't access the home page of the vms001 host. We first open port 808 in the http service, modify the context of the port, and then restart the httpd service. We will find that because the firewall does not set port 808 to allow access to the vms001 home page (figure 1-42), we can use the port to solve this problem. We add port 808 to the port, using tcp protocol. In this way, we can normally access the home page of the vms001 host on port 808 (figure 1-44). Then we can also use the command line to add 808 ports. At the same time, we should remember to add the "- permanent" parameter after adding ports, so that the configuration can still take effect after restart.

# vim / etc/httpd/conf/httpd.conf

# vim / etc/ssh/sshd_config-you can use the template in the ssh configuration file to modify the port context

# semanage port-a-t http_port_t-p tcp 808Murray-change the context of the port

# systemctl restart httpd.service

# firewall-cmd-- query-port=808/tcp--- queries whether port 808 is enabled in the firewall

# firewall-cmd-remove-port=808/tcp--- deletes port 808 opened in the firewall and deletes port

# firewall-cmd-- add port 808 to add-port=808/tcp

Third, let's take a look at the "ICMP filter", where ICMP represents the Internet control message protocol, which is mainly used to send error messages between networked computers, but also sends messages such as ping requests and responses. The ICMP filter here is the opposite of the first "service" we encountered. Here, the option in the ICMP type, if checked, indicates that it is not allowed to pass, while in "service", the check box means that the service is allowed to pass, while not ticking means that it is not allowed to pass. When we check "echo-request" in the ICMP filter, the vms001 host does not allow other hosts to send ping requests to themselves. We send ping requests to the vms001 hosts on the vms002 host and find that the ping is not successful (figure 1-47). Then we use the command line operation, using the add-icmp-block parameter, and then we can implement the requirement of prohibiting other hosts from ping the current vms001 host (figure 1-48). However, it should be noted that sometimes ping requests from clients of Windows type cannot be prohibited after ICMP is set. At this time, we can make relevant settings in the kernel parameters to achieve the requirement of prohibiting ping. The icmp_echo_ignore_all kernel parameter in the / proc/sys/net/ipv4/ directory defaults to 0, which allows requests for ping from other hosts. At this point, any type of client cannot ping the vms001 host (figure 1-49 and figure 1-50)

# firewall-cmd-- get-icmptypes--- queries all types of ICMP in the current firewall

# firewall-cmd-- add-icmp-block=echo-request--- check the option requested by ICMP, deny access to other machines and disable ping

Fourth, let's learn about the "source". Because our network card is associated in the public area and the http service is not checked, it is impossible to open the home page of the vms001 host when the vms002 host accesses using http://192.168.26.101 (figures 1-51 to 1-53). We add 192.168.26.0 network segment to the source in the home area of the vms001 host. At the same time, after allowing access to the http service has been added to the Services in the home area, although it is in the public area, the home page of the vms001 host can still be accessed normally (figures 1-54 to figure 1-56). This is because after we set the "source" in the home region to allow the 192.168.26.0 network segment, then as long as the client IP address is included in this network segment, then even if the public zone is used at this time, it can still match the setting rules of the services in the home zone, while the http service is allowed in the home zone, so the vms002 host can access the home page of the vms001 host normally.

(3.13) if we want to know which "sources" are included in the current firewall, we can use the query-source parameter to verify whether the specified area contains source information. For example, we tested the "source" information containing 192.168.26.0 network segment in the home area (figure 1-57). However, we can still use the "list-all" parameter to query the region information of the "source" when the network segment is unknown (figure 1-58). We can add and delete the "source" network segment in the area by command line.

# firewall-cmd-query-source=192.168.26.0/24

# firewall-cmd-query-source=192.168.26.0/24-zone=home

# firewall-cmd-- list-all--- queries whether the public region contains "source" information

# firewall-cmd-- list-all-- zone=home--- queries whether the home region contains "source" information

# firewall-cmd-- remove-source=192.168.26.0/24-- zone=home--- deletes the "source" information in the home area

# firewall-cmd-- add-source=192.168.26.0/24-- zone=home--- adds "source" information to the home area

(3.14) the fifth is "camouflage" and the sixth is "port forwarding". At present, there is a shortage of resources in the address of IPv4. In addition to using IPv6, our solution can also use NAT solution to alleviate it. In our environment, there is an intranet, and there is a switch in the intranet, which connects to an external access router, which is connected to a host on the external Internet (2.2.2.2). The host IP address of our intranet is the private address of the intranet (10.0.0.2), and the gateway of the private address is 10.0.0.1 on an interface of the router. The public network address of the router is 1.1.1.1. Now the host in our intranet (10.0.0.2) needs to send a packet to a host on the external Internet (2.2.2.2). At this time, the source address is 10.0.0.2 and the destination address is 2.2.2.2. After arriving at the router, the network address will be translated, and the source address: 1.1.1.1 Destination address: 2.2.2.2, this translation is called SNAT (source nat). Sometimes there is a host in our intranet that provides services. When the IP address of our intranet is 10.0.0.3, when the external Internet host wants to access the internal Web server, the source address is 2.2.2.2 and the destination address is 1.1.1.1. After passing through the router, the network address is translated, and the source address is 2.2.2.2. Destination address: 10.0.0.3, this translation is called DNAT (destination nat). Corresponding to the firewall SNAT is "camouflage", and DNAT is "port forwarding".

Now the environment of our system is that there are three hosts, of which the IP address of the server host is 10.0.0.2 the IP address of the IP host is 192.168.26.102 and the IP address of the ms001 host is 192.168.26.101. The network card of the vms001 host is eno16777728, and one of the network cards of the vms002 host is eno16777728. The corresponding IP address is 192.168.26.102. Then we add a new network card eno33554968 on the vms002 host, and the corresponding IP address of this network card is 10.0.0.1. We set the firewall on the vms002 host. We first add the second network card eno33554968 of the vms002 host to our own LAN section, then we configure the corresponding IP address and subnet mask information on the network card eno33554968, and finally restart the network.

# nmcli connection--- queries the connection of the network card

# systemctl restart network--- restart the network

Next, we add the network card of the server host to the aa network segment of the LAN segment. In the server host, we edit the network card ens32 and note that we need to set the option of automatically connecting to the network. We set the IP address 10.0.0.2, mask and gateway information on the server host, where the gateway points to the IP address 10.0.0.1 of the vms002 host eno33554968 network card, and restart the service. When we ping the network card address 10.0.0.1 of the server host to the vms002 host, we can communicate normally with ping, and when we use the server host ping to the network card address 192.168.26.102 of the vms002 host, we can also ping normally.

(3.17) when we try to communicate from the server host ping to the vms001 host, we find that we cannot communicate with the ping host (figure 1-72). This is because the server host needs to enable the forwarding function when communicating with the vms001 host, but the forwarding function of the vms002 host is not enabled at this time. We set the value of ip_forward to 1 (figures 1-73 to figure 1-75).

# cat / proc/sys/net/ipv4/ip_forward--- query whether the forwarding function of the vms002 host is enabled

# echo 1 > / proc/sys/net/ipv4/ip_forward--- enable the forwarding function of vms002 host

# sysctl-a | grep forward--- queries all the forwarding features in the system

# echo 'net.ipv4.ip_forward = 1' > > / etc/sysctl.conf--- writes the forwarding function to the configuration file

(3.18) if we want the server host to access the successful vms001 host, there are two solutions. The first is to configure routing. We set the gateway of the vms001 host to point to the IP address 192.168.26.102 of the vms002 host, and restart the network service. After the vms001 host has set the routing information, the server host can ping the vms001 host normally. However, the vms001 host can see the IP address information of the server host during the packet capture process (figures 1-76 to 1-79) The second way is to configure NAT. We turn on the firewall on the vms002 host, then set the default zone to public and check the "camouflage zone". At this time, the server host can normally access the IP address of the vms001 host. At this time, because we have set NAT on the vms002 host, we can receive the message sent by the server host, but we can only see that it is vms002.example.com. Unable to obtain specific IP address information, thus playing the role of camouflage (figures 1-80 to 1-82).

# systemctl restart network--- restart network service

# tcpdump-I eno16777728 icmp--- query packet capture information

Next, let's learn about the sixth "port forwarding". We first build a Web server on the server host in the intranet. In this case, we need that the vms001 host can access the Web service provided by the server host. At this time, what we do is to set port forwarding. When we access port 80 of the vms002 host, it will automatically forward to port 80 of the server host. So you can correctly see the Web home page of the server host (figure 1-86). We can also do this through the command line. We operate on the vms002 host, and we query on the vms002 host and find that port forwarding does not have any settings. At this time, we set port port to 80 on the vms002 host, protocol proto to tcp, forwarding address toaddr to 10.0.0.2, forwarding port 80, and when we access port 80 of the 192.168.26.102 host from the vms001 host. It will be forwarded to port 80 of the server host (figure 1-88).

# firewall-cmd-- list-all--- queries all configuration information of the default zone of the current firewall

# firewall-cmd-add-forward-port= "port=80:proto=tcp:toaddr=10.0.0.2:toport=80"

(3.20) We can also set entries that will be forwarded to port 22 of the machine when accessing local port 80 (figure 1-89 and figure 1-90). We can also set that port 80 that accesses the machine will be forwarded to port 22 of the 10.0.0.2 host (figure 1-91 and figure 1-92).

# firewall-cmd-- remove-forward-port= "port=80:proto=tcp:toaddr=10.0.0.2:toport=80"-delete the entry for port forwarding

# firewall-cmd-- add-forward-port= "port=80:proto=tcp:toport=22"-- add an entry for forwarding port. If you access local port 80, it will be forwarded to local port 22.

# firewall-cmd-- remove-forward-port= "port=80:proto=tcp:toport=22"-delete the entry for port forwarding

# firewall-cmd-- add-forward-port= "port=80:proto=tcp:toaddr=10.0.0.2:toport=22"-- add an entry for forwarding port. If you access port 80 of this machine, it will be forwarded to port 22 of 10.0.0.2 host.

(IV) use man firewalld.richlanguage

Let's learn about the "rich rule". First, we install the http service on the vms002 host, then we delete the forwarding configuration in "Port forwarding" and check the http service in the "Service". At this time, we will find that if the http service is allowed to pass, then all hosts are accessible, and if the http service is prohibited, then all hosts are inaccessible. There is no precise control according to our needs (figure 4-3).

# echo vms002 > / var/www/html/index.html--- sets home page information

# systemctl start httpd

(4.2) sometimes our need is that some clients can access the home page of the vms002 host, but at the same time, some clients will be denied access to the home page of the vms002 host. At this time, we can deal with it by setting rich rules, but if we enable rich rules to control Web pages, then "service" and "port" we can not do any check control. If we want to configure with a graphical interface, we need to choose the English version. We choose "Rich_Rules", choose to control ipv4, select http as the service service, and select accept to indicate the clients that are allowed to access. We fill in 192.168.26.1 for the clients allowed by Source source (figure 4-4). At this time, our 192.168.26.1 client can normally access the home page of the vms002 host (figure 4-6), while the IP address of the client of the vms001 host is 192.168.26.101, which does not meet the requirements of rich rules and cannot access the home page of the vms002 host (figure 4-7).

# LANG=C firewall-config &

(4.3) if we want to do the above from the command line, we first use the man-k command to query all entries that conform to firewall, and then go to the firewalld.richlanguage entry, where we can follow Example 3 and Example 5 in the firewalld.richlanguage entry. First of all, we use service for access control. We set up the vms002 host to allow only 192.168.26.1 host to access the http service. At this time, the 192.168.26.1 host can normally access the home page of the vms002 host (figures 4-10 to 4-12).

# man-k firewall--- queries all entries that conform to firewall

# man firewalld.richlanguage--- queries the specific explanation of this entry

# firewall-cmd-- add-rich-rule 'rule family= "ipv4" source address= "192.168.26.1 accept'--- 24" service name= "http" accept'--- in the vms002 host setting allows only 192.168.26.1 hosts to access the http service

# firewall-cmd-- remove-rich-rule 'rule family= "ipv4" source address= "192.168.26.1" service name= "http" accept'--- removes the vms002 host setting to allow only 192.168.26.1 hosts to access http services

(4.4) then we try to use the port port for access control. We specify the address as the 192.168.26.101 host, which can be passed when accessing port 80 of the native vms002 host. At this time, we find that the Web service of the vms001 host cannot be accessed properly when using the 192.168.26.1 host, while the 192.168.26.101 host can properly access the home page of the vms001 host (figures 4-14 and 4-15).

# firewall-cmd-- add-rich-rule 'rule family= "ipv4" source address= "192.168.26.101" port port= "80" protocol= "tcp" accept'--- specifies that when the address is 192.168.26.101 host, you can access port 80 of the native vms002 host through the

# firewall-cmd-- remove-rich-rule 'rule family= "ipv4" source address= "192.168.26.101" port port= "80" protocol= "tcp" accept'--- removes the entry through which the specified address is 192.168.26.101 host and port 80 access can be passed

Now our requirement is that when the 192.168.26.101 host accesses port 88 of the vms002 host, it will be automatically forwarded to port 22 of the server host. We first use a graphical interface to operate. We choose forward-port. When we access port 88 of this machine, we automatically forward it to port 22 of the host 10.0.0.2, and fill in the address of the host that is allowed to access. At this time, we find that only the vms001 host can connect to the 10.0.0.2 host with normal ssh.

# ssh 192.168.26.102-p 88Murray-connect on the vms001 host, where-p indicates the port

(4.6) if we want to use the command line to realize that when the 192.168.26.1 host accesses port 88 of the vms002 host, it will be automatically forwarded to port 22 of the server host, we can use man firewalld.richlanguage to query the example of Example 5, and we can normally connect to port 22 of the server host (figure 4-21 and figure 4-22).

# firewall-cmd-list-all

# firewall-cmd-add-rich-rule 'rule family= "ipv4" source address= "192.168.26.1" forward-port to-addr= "10.0.0.2" to-port= "22" protocol= "tcp" port= "88"-where port represents the local port and to-port represents the forwarded port

(4.7) sometimes we need to open NAT address translation for specific network segments within the enterprise. For example, we only allow the hosts of the company's marketing department to access the public network, but the network segment hosts of the development department and finance department cannot access the public network. In this case, we can use the masquerade feature of Rich Rules on the vms002 host, and we need to make sure that masquerading is not checked in the third column. The IP of our server host is 10.0.0.2. At this time, we cannot ping the vms001 host using the server host ping (figure 4-24). Then we modify the IP address and default gateway of the server host to meet the requirements of the host IP in the rich rules. The default gateway points to the vms002 host eno33554968 network card (10.0.0.1). At this point, we can normally use NAT to achieve the need for intranet IP to access external hosts (figure 4-25).

# ifconfig ens32 10.0.0.3 netmask 255.255.255.0ash route add default gw 10.0.0.1After-modify the IP address to 10.0.0.3, modify the mask to 255.255.255.0, modify the default gateway to 10.0.0.1

# route delete default gw 10.0.0.1Murray-Delete the default gateway

-this is the end of this article. Thank you for reading-

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.