web——操作案例

合集 - RHCE(12)

1.Linux 和 Unix 系统中的at命令相关解析2024-11-26 2.【 Linux系统——crontab命令解析】01-13 3.【Linux 和 Unix 系统中的at命令相关解析】2024-10-28 4.DNS域名解析服务——过程及配置文件解读2024-11-23

5.web——操作案例2024-11-17

6.NFS服务案例练习2024-11-21 7.【Linux——使用nginx搭建web网站】2024-11-15 8.Web服务介绍2024-11-09 9.Linux系统使用第三方邮件客户端发送邮件2024-11-05 10.Linux系统——部署NFS服务2024-11-19 11.【远程登陆服务-SSH】2024-11-07 12.Linux系统时间服务——Chrony服务器2024-11-03

server-常用配置选项

在 NGINX 的 server 块中，你可以定义与处理请求相关的各种配置。这些配置决定了如何响应客户端的请求，包括监听哪些地址、使用哪个根目录、如何处理特定路径等。下面我将详细讲解 NGINX server 块中的常用配置项。

1. `listen`

listen 192.168.26.130:80;

作用：指定服务器监听的 IP 地址和端口。
常见用法：
- listen 80;：监听所有可用的 IP 地址上的端口 80（默认 HTTP 端口）。
- listen 192.168.26.130:80;：只监听特定 IP 地址 192.168.26.130 上的端口 80。
- listen [::]:80;：监听 IPv6 地址。
- 可以使用 ssl 参数指定 HTTPS，如 listen 443 ssl;。

2. `server_name`

server_name www.example.com;

作用：定义此 server 块的域名。
常见用法：
- server_name www.example.com;：处理 www.example.com 的请求。
- server_name example.com www.example.com;：同时处理 example.com 和 www.example.com 的请求。
- server_name _;：_ 可以匹配所有未被明确指定的请求（通常用于默认服务器）。
- 支持通配符：server_name *.example.com; 匹配所有以 .example.com 结尾的子域名。

3. `root`

root /www/data;

作用：设置默认的文件根目录，Nginx 会从这个路径中查找资源文件。
路径拼接：请求路径会与 root 指定的目录结合。例如，如果 root 为 /www/data，请求 /images/pic.jpg 将会被映射为 /www/data/images/pic.jpg。

4. `index`

index index.html index.htm;

作用：指定默认的索引文件。当请求目录时，如果没有提供具体的文件，Nginx 会尝试查找这些文件并返回。
常见用法：
- index index.html;：当用户请求 / 或目录时，Nginx 会查找 index.html。
- 可以指定多个文件：index index.html index.htm;，Nginx 会按顺序查找这些文件。

5. `location`

location /images/ {
    root /data;
}

作用：定义如何处理特定的 URL 路径。location 指令用于匹配和处理不同的请求路径。
常见匹配规则：
- location /：匹配所有请求路径（默认处理规则）。
- location = /exact-path：精确匹配路径 /exact-path。
- location /images/：匹配所有以 /images/ 开头的路径，如 /images/photo.jpg。
- location ~ \\.php$：正则表达式匹配，匹配所有以 .php 结尾的文件。

6. `alias`

location /real {
    alias /openlab/real/;
}

作用：将请求路径映射到不同的文件系统路径。与 root 不同，alias 替换整个路径，而不是附加路径部分。
例子：
- alias /openlab/real/：请求 /real/index.html 映射为 /openlab/real/index.html。

7. `proxy_pass`

location /app/ {
    proxy_pass http://backend_server;
}

作用：用于反向代理，将请求转发到后端服务器。
常见用法：
- proxy_pass http://backend_server;：将匹配的请求转发到后端服务器 backend_server，可以是 IP 地址或主机名。
- proxy_pass <http://127.0.0.1:8080>;：转发到本地运行在 8080 端口的服务。

8. `try_files`

try_files $uri $uri/ =404;

作用：按照顺序尝试匹配文件。如果文件存在则直接返回，否则继续按顺序匹配。
常见用法：
- try_files $uri $uri/ /index.html;：先尝试请求的文件和目录，如果不存在，则返回 index.html。
- try_files $uri $uri/ =404;：如果找不到文件，则返回 404 错误。

9. `error_page`

error_page 404 /custom_404.html;

作用：自定义错误页面。当发生特定的 HTTP 状态码错误时，返回自定义的页面。
常见用法：
- error_page 404 /custom_404.html;：当发生 404 错误时，返回 /custom_404.html。
- error_page 500 502 503 504 /50x.html;：为多种错误状态码指定相同的错误页面。

10. `client_max_body_size`

client_max_body_size 10M;

作用：设置客户端请求体的最大允许大小，常用于限制文件上传大小。
常见用法：
- client_max_body_size 10M;：限制请求体大小为 10MB。
- 默认情况下，Nginx 的限制为 1MB。

11. `access_log` 和 `error_log`

access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;

作用：记录请求和错误日志。
- access_log：记录每次访问请求的信息，如客户端 IP 地址、请求路径、响应状态等。
- error_log：记录 NGINX 运行时的错误信息。
日志级别：error_log 支持不同的日志级别，如 info、warn、error、crit。

12. `return`

return 301 https://$server_name$request_uri;

作用：直接返回指定的状态码和 URL，用于重定向或直接返回错误码。
常见用法：
- return 301 https://$server_name$request_uri;：强制 HTTP 到 HTTPS 的 301 永久重定向。
- return 404;：直接返回 404 错误。

13. `rewrite`

rewrite ^/old/(.*)$ /new/$1 permanent;

作用：用于 URL 重写。通过正则表达式匹配请求路径，并重写为新的 URL。
常见用法：
- rewrite ^/old/(.*)$ /new/$1 permanent;：将 /old/ 开头的 URL 重写为 /new/，并返回 301 永久重定向。

14. `ssl_certificate` 和 `ssl_certificate_key`

ssl_certificate /etc/nginx/ssl/server.crt;
ssl_certificate_key /etc/nginx/ssl/server.key;

作用：用于配置 HTTPS 服务，指定 SSL 证书和私钥文件的路径。
常见用法：
- ssl_certificate：指定 SSL 证书文件。
- ssl_certificate_key：指定私钥文件，用于解密 SSL 通信。

总结

server 块中的配置主要用于定义 NGINX 如何处理特定的请求，涉及到监听 IP 和端口、域名匹配、文件系统路径映射、反向代理、错误处理等功能。通过这些配置，你可以灵活地设置 NGINX 来满足不同的需求，如静态文件托管、反向代理、负载均衡、HTTPS 支持等。

前置操作

systemctl stop firewalld #临时关闭防火墙
setenforce  0 #临时关闭setenforce服务，这服务干嘛的后续补充

案例一：多IP访问多网站

dnf install nginx -y #安装nginx服务

第一种方式：
nmcli connection modify ens32 ipv4.method manual ipv4.addresses 192.168.10.130/24 ipv4.gateway 192.168.10.2 ipv4.dns 114.114.114.114 +ipv4.addresses 192.168.10.129/24 #添加多IP

nmcli connection up ens32 #连接配置
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/2)

第二种方式：
nmuti #图形化操作
nmcli  connection up ens160 #连接esn160

vim /etc/nginx/conf.d/test_ip.conf #编辑配置文件
server {
    listen 192.168.26.130:80;
    root /www.test/ip/130;
    location / {
    }
}
server {
    listen 192.168.26.131:80;
    root /www.test/ip/131;
    location / {
        index  index.html;
    }
}
server {
    listen 192.168.26.132:80;
    root /www.test/ip/132;
    location / {
        index  index.html;
    }
}

systemctl restart nginx #重启服务

mkdir /www.test/ip/{130,131,132} -pv #创建目录文件

#写入文件内容
echo this is 130 > /www.test/ip/130/index.html
echo this is 131 > /www.test/ip/131/index.html
echo this is 132 > /www.test/ip/132/index.html

#现象测试
curl 192.168.26.130
curl 192.168.26.131
curl 192.168.26.132

1.前提配置  关防火墙 关selinux
2.安装web服务程序nginx
3.当前主机添加多地址（ip  a）
4.自定义nginx配置文件通过多地址区分多网站

/etc/nginx/conf.d/test_ip.conf
server {  #标记为一个虚拟主机
}
5.根据配置在主机创建数据文件
6.重启服务加载配置

7.客户端连接测试
curl
elink

使用cpolar实现内网穿透

使用nginx建立网站
部署文档：https://dashboard.cpolar.com/get-started

案例二：多端口访问多网站

vim /etc/nginx/conf.d/test_port.conf #编辑配置文件

server { #类似于创建一个虚拟机
    listen 192.168.26.130:10000; #监听192.168.26.130的10000端口
    root /www.test/port/10000; #根目录
    location / { #根路径下的具体信息，若无，则直接在根目录下读取默认主页文件
        index index.html;
    }
}
server {
    listen 192.168.26.131:8909;
    root /www.test/port/8909;
    location / {
        index index.html;
    }
}

systemctl restart nginx #重启服务

mkdir -pv /www.test/port/{8909，10000} #创建文件

#写入文件内容
echo 8909 > /www.test/port/8909/index.html 
echo 10000 > /www/port/10000/index.html

#现象测试
curl http://192.168.26.130:10000
curl http://192.168.26.131:8909

案例三：多域名访问网站

vim /etc/nginx/conf.d/test_name.conf #编辑配置文件

server { 
    listen 192.168.26.130:80;
    root /www.test/name/node1; #根路径
    server_name www.node1.com; #绑定一个域名，即访问该域名时，从上述根路径下读取文件
    location / {
    }
}
server {
    listen 192.168.26.131:80;
    root /www.test/name/node2;
    server_name www.node2.com;
    location / {
    }
}

mkdir -pv /www.test/name/{node1,node2} #创建文件目录

写入文件内容
echo node1 > /www.test/name/node1/index.html
echo node2 > /www.test/name/node2/index.html

systemctl restart nginx #重启服务

hosts-本地`DNS`解析文件

客户端测试windows：C:\Windows\System32\drivers\etc   编辑hosts文件添加本地域名解析信息
通过浏览器http://www.node1.com

linux客户端测试:[root@node1 ~]# vim  /etc/hosts
追加写入192.168.26.130 www.node1.com   www.node2.com

影响：

访问 http://www.node1.com 和 http://www.node2.com 都会将请求发送到 192.168.26.130 。
NGINX 将根据请求头中的 Host 字段来区分访问的是哪个虚拟主机。
- 如果访问 http://www.node1.com，NGINX 会匹配到 server_name www.node1.com 的虚拟主机，并返回 node1 的内容。
- 如果访问 http://www.node2.com，NGINX 会匹配到 server_name www.node2.com 的虚拟主机，并返回 node2 的内容。

解释：

/etc/hosts 文件是本地的 DNS 解析文件，作用是将主机名（域名）映射到 IP 地址。当系统进行网络请求时，会优先查找 /etc/hosts 文件以解析域名到对应的 IP 地址。

在这种情况下，你将 www.node1.com 和 www.node2.com 都映射到了同一个 IP 地址 192.168.26.130。这意味着：

无论访问 www.node1.com 还是 www.node2.com，都会指向 192.168.26.130 这个 IP 地址。

注意事项：

由于 www.node1.com 和 www.node2.com 都指向相同的 IP 地址，但它们是不同的虚拟主机，NGINX 能够通过 server_name 来区分它们。
这种配置仅在当前机器上生效，因为 /etc/hosts 是本地文件，其他机器上的 DNS 解析不会受到影响。

案例四：虚拟目录和用户控制

vim /etc/nginx/conf.d/test_alias.conf

server {
    listen 192.168.26.130:80;
    root /www.test/ip/130;

    location /real {
        alias /openlab/real/;
        #alias  /www.test/ip/130/real /openlab/real;
    }
}

mkdir /openlab/real -pv
echo this is real > /openlab/real/index.html

systemctl restart nginx.service

curl http://192.168.26.130/real/

虚拟目录解析

1. 编辑 NGINX 配置文件

文件路径：/etc/nginx/conf.d/test_alias.conf，内容如下：

server {
    listen 192.168.26.130:80;
    root /www.test/ip/130;

    location /real {
        alias /openlab/real/;
        #alias  /www.test/ip/130/real /openlab/real;
    }
}

#使用了 alias 指令来处理特定路径的请求

监听端口：192.168.26.130:80
根目录：/www.test/ip/130，这是默认的根目录，Nginx 会将 / 请求映射到这个路径。
location /real：为 /real 路径配置了一个特殊规则：
- alias /openlab/real/：表示当访问 /real 路径时，请求会被映射到 /openlab/real/ 目录，而不是 root 目录下的 /real。

2. 创建目录并写入文件

mkdir /openlab/real -pv
echo this is real > /openlab/real/index.html

mkdir /openlab/real -pv：创建了 /openlab/real 目录，p 确保父目录不存在时会自动创建，v 用于显示创建的目录。
echo this is real > /openlab/real/index.html：在 /openlab/real/ 目录下创建了 index.html 文件，内容为 "this is real"。

3. 重启 NGINX 服务

systemctl restart nginx.service

这条命令会重启 NGINX 服务，确保刚刚修改的配置文件生效。

4. 测试访问

curl <http://192.168.26.130/real/>

当你使用 curl 访问 http://192.168.26.130/real/ 时，Nginx 将会按照配置规则，使用 alias 将 /real 映射到 /openlab/real/ 目录。

由于 /openlab/real/ 目录下有一个 index.html 文件，返回的内容应该是：
```
this is real
```

关键点：

alias vs root：在 location 中，alias 和 root 有不同的作用：
- alias 替换整个路径。例如，/real 映射到 /openlab/real/，所以 /real/ 实际上访问的是 /openlab/real/。
- root 则会在根目录下拼接请求路径。
举例：
- alias /openlab/real/：/real/ 直接映射到 /openlab/real/，访问 /real/index.html 实际上是访问 /openlab/real/index.html。
- 如果使用 root：则 /real/index.html 会被映射到 /www.test/ip/130/real/index.html。

用户认证

vim /etc/nginx/conf.d/test_alias.conf

server {
    listen 192.168.26.130:80;
    root /www.test/ip/130;
    
    location /real {
        alias /openlab/real/;
        
        auth_basic on;
        auth_basic_user_file /etc/nginx/users;
    }
}

dnf provides htpasswd
dnf install httpd-tools

htpasswd  -c /etc/nginx/users tom

systemctl restart nginx
curl 192.168.26.130/real/ -u tom

Enter host password for user 'tom':

使用`auth_basic` 实现基本的 HTTP 认证功能

1. NGINX 配置

关键配置项：

alias /openlab/real/：将 /real 请求映射到 /openlab/real/ 目录。也就是说，访问 http://192.168.26.130/real/ 实际上会加载 /openlab/real/ 中的文件。
auth_basic on;：启用了基本认证。默认情况下，它会提示用户输入用户名和密码。
auth_basic_user_file /etc/nginx/users;：指定存放用户和密码的文件路径，这个文件由 htpasswd 命令生成，包含用户名和加密后的密码。

2. 安装 `htpasswd` 工具

你使用了 dnf 安装 httpd-tools，其中包含了 htpasswd 工具。

dnf provides htpasswd
dnf install httpd-tools

dnf provides htpasswd：查找哪个包提供了 htpasswd 命令。系统会返回 httpd-tools 包。
dnf install httpd-tools：安装 httpd-tools 包，里面包含了 htpasswd 工具，用于生成用户名和密码文件。

3. 创建用户和密码文件

htpasswd -c /etc/nginx/users tom

htpasswd -c /etc/nginx/users tom：创建 /etc/nginx/users 文件，并添加用户名 tom。命令执行后会提示你输入并确认 tom 的密码。
- c 参数表示创建新文件。如果文件已经存在，使用该参数会覆盖它。
- 用户名和密码会以加密格式存储在 /etc/nginx/users 文件中。

4. 重启 NGINX 服务

systemctl restart nginx

作用：重启 NGINX 服务以应用新的配置。如果配置文件中有错误，NGINX 不会启动，因此在生产环境中重启前可以使用 nginx -t 进行语法检查。

5. 测试访问

curl 192.168.26.130/real/ -u tom

作用：你使用 curl 命令访问 http://192.168.26.130/real/，并通过 u 参数指定用户 tom。curl 会提示输入用户 tom 的密码。

Enter host password for user 'tom':

当你输入正确的密码后，NGINX 将会通过认证，并返回 /openlab/real/ 目录下的内容。如果认证失败，NGINX 会返回 401 Unauthorized 错误。

总结

案例五：`https`/443

（1）`https` 简介

超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息。HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此HTTP协议不适合传输一些敏感信息，比如信用卡号、密码等。为了解决HTTP协议的这一缺陷，需要使用另一种协议：安全套接字层超文本传输协议HTTPS。
HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer 或 Hypertext Transfer Protocol Secure，超文本传输安全协议），是以安全为目标的HTTP通道。HTTPS并不是一个新协议，而是HTTP+SSL（TLS）。原本HTTP先和TCP（假定传输层是TCP协议）直接通信，而加了SSL后，就变成HTTP先和SSL通信，再由SSL和 TCP 通信，相当于SSL被嵌在了HTTP和TCP之间。

!https://zyj-1258460726.cos.ap-nanjing.myqcloud.com//typora-pic/image-20230201170124857.png

SSL 是Secure Sockets Layer的缩写，中文叫做“安全套接层”。它是在上世纪90年代中期，由网景公司设计的。到了1999年，SSL 应用广泛，已经成为互联网上的事实标准。IETF 就把SSL 标准化。标准化之后SSL被改为 TLS（Transport Layer Security传输层安全协议）。

`SSL`协议分为两层：

SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能。

`SSL`协议提供的服务：

认证用户和服务器，确保数据发送到正确的客户机和服务器
加密数据以防止数据中途被窃取
维护数据的完整性，确保数据在传输过程中不被改变—MD5

（2）`https`协议加密所使用的算法-`HASH`算法

HASH是把任意长度的输入（又叫做预映射pre-image）通过散列算法变换成固定长度的输出，该输出就是散列值。Hash算法特别的地方在于它是一种单向算法，用户可以通过hash算法对目标信息生成一段特定长度的唯一hash值，却不能通过这个hash值重新获得目标信息。因此Hash算法常用在不可还原的密码存储、信息完整性校验等。

常见的HASH算法：MD2、MD4、MD5、HAVAL、SHA、SHA-1、HMAC、HMAC-MD5、HMACSHA1。

共享密钥加密（对称密钥加密）：加密和解密使用相同密钥。
对称加密算法：DES、3DES、DESX、Blowfish、IDEA、RC4、RC5、RC6和AES。

公开密钥加密（非对称密钥加密）：公开密钥加密使用一对非对称的密钥。一把叫做私有密钥，一把叫做公开密钥。私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。使用此加密方式，发送密文的一方使用公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听盗走。
常见的非对称加密算法：RSA、ECC（移动设备用）、Diffie-Hellman、El Gamal、DSA（数字签名用）。

但由于公开密钥比共享密钥要慢，所以我们就需要综合一下他们两者的优缺点，使他们共同使用，而这也是HTTPS采用的加密方式。在交换密钥阶段使用公开密钥加密方式，之后建立通信交换报文阶段则使用共享密钥加密方式。
如何证明公开密钥本身是货真价实的公开密钥？如，正准备和某台服务器建立公开密钥加密方式下的通信时，如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。或许在公开密钥传输过程中，真正的公开密钥已经被攻击者替换掉了。这个时候就需要第三方公证单位来帮忙啦。

对称加密
我的理解是：首先我们需要协商使用什么算法（AES）, 接着我们通过相同的密钥对数据进行加密即可实现：明文 + 密钥 ==> 密文，密文 + 密钥 ==> 明文。由此我们可以看出，都使用相同的密钥，一旦密钥泄露，那么数据相当于公开。优点：效率高。改进：能不能提前把密钥加密，只能由服务端才能解密。

非对称加密
是网络通信的基石，保证了非对称加密密钥的安全。首先，非对称加密需要私钥和公钥，公钥加密的数据只能由私钥解开，而私钥加密的数据只能由公钥解开。公钥存储在客服端，私钥存储在服务端，永远不对外暴漏。

流程：首先客服端请求公钥，服务端响应公钥，之后客服端通过公钥加密数据传输，服务端通过私钥解密获取信息。
存在的安全隐患: 我们的公钥是直接进行传输的，那么黑客就可以得到我们的公钥从而获取信息。

非对称加密 + 对称加密

客服端请求公钥响应后，客服端通过公钥可以加密一串随机数，作为以后信息传输对称加密的密钥，而这串随机数也只能由服务端的私钥才能解析。

服务端通过私钥解析后，通过对称加密对数据进行加密。
问题：假如在客服端请求公钥的时候，就被黑客拦截，充当了服务器，给了黑客的公钥给客服端，此问题产生的主要原因是：报文可能被篡改，客服端完全相信服务端！

数字签名解决报文被篡改
(1). 能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。
(2). 数字签名能确定消息的完整性 , 证明数据是否未被篡改过。

发送者将数据先于hash算法生成信息摘要，然后用私钥加密生成数字签名，一起发送给接收方。
接收方只有用发送者的公钥才能解密被加密的数据，然后通过hash对原文参数一个摘要信息，进行比对，即可确认报文是否被篡改。

问题：我们的公钥还是不安全的在网络中传输，解决证书

证书解决服务端身份问题
有专门的机构进行颁发，而证书中包含了你的公钥，同时包含数字签名
此后我们请求公钥改为请求证书，如何保证不会得到一个假证书了！我们CA机构在已把证书嵌套在了浏览器以及操作系统，所以证书都不用经过网络自然不会出现假的。

1.请求连接，tcp三次握手确认版本

2.秘钥套件的协商，开始身份认证（非对称算法）证书验证协商对称算法[客户端验证服务器身份]

3.建立ssl 会话链接

4.加密会话交互

5.断开会话链接

TLS完整的通信流程

第一阶:段客户端端申请建立https连接

!https://lxx-1258460726.cos.ap-nanjing.myqcloud.com//typora-pic/image-20230417165314605.png

第二阶段：客户端和服务器确认加密版本,加密套件

!https://lxx-1258460726.cos.ap-nanjing.myqcloud.com//typora-pic/image-20230417165757187.png

1.浏览器向服务器发送一个clientHello的报文

!https://lxx-1258460726.cos.ap-nanjing.myqcloud.com//typora-pic/image-20230417165552877.png

客户端产生一个随机数Random（ClientRandom）

会话ID：第一次肯定为空

Cipher suite: 加密套件（秘钥交换，完整性校验算法，对称机密算法，算法列表）

2.服务端向客户端回复一个ServerHello（确认使用的TLS的版本，以及加密套件）

Random随机数：服务产生的（ServerRandom）

SessionID： 0

Cipher suite:确认使用加密套件

Compression method: null 不压缩

Extension: 扩展字段

第三阶段:证书发送验证 （客户端验证证书取出公钥，用公钥加密生成的对称秘钥发送个服务器通知改变加密信息传递）

3.服务器向客户端发送Certificate （服务器的身份证，证书由第三方权威机构颁发）

4.服务器向客户端发送serverkey Exchange（通过和客户端协商的密码算法套件发送Pubkey结合HD算法生成Premastersecret(最终加密的会话秘钥)）

5.certificate Request 可选报文（认证可以是单向也可以是双向，一般都是单向客户端验证服务端身份，服务端验证客户端客户端也需要发送证书）

6.ServerHello Done 服务端发送握手信息完毕

7.客户端回复服务器报文Certificate 如果有第五阶段则提交客户端的证书进行认证

!https://lxx-1258460726.cos.ap-nanjing.myqcloud.com//typora-pic/image-20230417170109672.png

image-20230417170109672

8.ClientKey Exchange 秘钥交换信息和步骤4类似

9.ChangeCiper Spec: 通知消息（消息改变通知，及后面消息要进行加密了）

10.Encrypted Handshake Messges 校验数据包的完整性MD5(hash)将数据包的值进行散列最后和服务端的散列值进行比较一致意味着沟通过程中没有第三者的介入

第四阶段：服务收到消息，用私钥解密取，确认对称秘钥通知客户端ssl通道建立完成

!https://lxx-1258460726.cos.ap-nanjing.myqcloud.com//typora-pic/image-20230417170232066.png

image-20230417170232066

11.服务器向客户端回包：NewSession Ticket(建立会话票据，提供会话票据)

12.change cipher Spec: 改变密码通知加密发送信息

13.encrypted Handshake message (Finished)

第五阶段：客户端和服务端可以通过加密通道开始数据通信

!https://lxx-1258460726.cos.ap-nanjing.myqcloud.com//typora-pic/image-20230417170156577.png

Application Data（http）客户端和服务端可以通过加密通道开始数据通信

第六阶段：客户端断开连接

Encrypted Alert

!https://lxx-1258460726.cos.ap-nanjing.myqcloud.com//typora-pic/image-20230417170307160.png

秘钥交换的大概过程：
ClientHello客户端产生一个随机数C，Serverhello服务端产生一个随机数S--公开, 还需要一个随机数（加密）
serverhello过程中发送serverkeyexchange发送公钥pubkey给客户端
客户端通过clientkeychange发送通过pubkey加密的随机数Pre_master
服务端对客户端的发送的加密Pre_master进行解密
最终客户端和服务端各自掌握了三个随机数利用复杂的交换算法进行计算协商出彼此的对称秘钥
注：
TLS1.3 提供 1-RTT 的握手机制，还是以 ECDHE 密钥交换过程为例，握手过程如下。将客户端发送 ECDH 临时公钥的过程提前到 ClientHello ，同时删除了 ChangeCipherSpec 协议简化握手过程，使第一次握手时只需要1-RTT，来看具体的流程:
    • 客户端发送 ClientHello 消息，该消息主要包括客户端支持的协议版本、DH密钥交换参数列表KeyShare；
    • 服务端回复 ServerHello，包含选定的加密套件；发送证书给客户端；使用证书对应的私钥对握手消息签名，将结果发送给客户端；选用客户端提供的参数生成 ECDH 临时公钥，结合选定的 DH 参数计算出用于加密 HTTP 消息的共享密钥；服务端生成的临时公钥通过 KeyShare 消息发送给客户端；
    • 客户端接收到 KeyShare 消息后，使用证书公钥进行签名验证，获取服务器端的 ECDH 临时公钥，生成会话所需要的共享密钥；
    • 双方使用生成的共享密钥对消息加密传输，保证消息安全。

#key是私钥文件
#crt是由证书颁发机构（CA）签名后的证书，或者是开发者自签名的证书，包含证书持有人的信息，持有人的公钥，以及签署者的签名等信息
[root@www certs]# openssl  req  -utf8 -new -key jiami.key -x509 -days 100 -out jiami.crt
------------------------------------------------RHEL7--------------------------------
  (第一种)    [root@localhost certs]# make jiami.crt
-------------------------------------------------------------------------------------
！！！！！！！注意！！！！！！！！！！！！！！！！
  (第二种) #openssl  req -newkey rsa:4096 -nodes -sha256 -keyout haha.key -x509 -days 365 -out haha.crt
----------------------------------------------x509 key  csr crt-----------------------
[root@www certs]# openssl genrsa -aes128 2048 > openlab.key
  (第三种) #openssl req -utf8 -new -key openlab.key -x509 -days 365 -out openlab.crt
-------------------------------------------------------------------------------------

[root@node1 ~]# openssl  genrsa  -out  /etc/pki/tls/private/openlab.key
[root@node1 ~]# openssl req -utf8 -new -key /etc/pki/tls/private/openlab.key  -x509 -days 365 -out /etc/pki/tls/certs/openlab.crt
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:86
State or Province Name (full name) []:xi'an
Locality Name (eg, city) [Default City]:shannxi
Organization Name (eg, company) [Default Company Ltd]:open
Organizational Unit Name (eg, section) []:ce
Common Name (eg, your name or your server's hostname) []:local
Email Address []:admin
[root@node1 ~]# cp  /etc/nginx/conf.d/test_alias.conf /etc/nginx/conf.d/test_https.conf
[root@node1 ~]# vim /etc/nginx/conf.d/test_https.conf
[root@node1 ~]# cat /etc/nginx/conf.d/test_https.conf
server {
    listen 192.168.10.129:443 ssl;
    root /www/https;
    ssl_certificate /etc/pki/tls/certs/openlab.crt;
    ssl_certificate_key /etc/pki/tls/private/openlab.key;
    location / {
    }
}
[root@node1 ~]# mkdir /www/https
[root@node1 ~]# echo this is https > /www/https/index.html
[root@node1 ~]# openssl  genrsa  -out  /etc/pki/tls/private/openlab.key
[root@node1 ~]# openssl req -utf8 -new -key /etc/pki/tls/private/openlab.key  -x509 -days 365 -out /etc/pki/tls/certs/openlab.crt
[root@node1 ~]# systemctl restart nginx

[root@node1 ~]# curl https://192.168.10.129
curl: (60) SSL certificate problem: self-signed certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
[root@node1 ~]# curl https://192.168.10.129 -k
this is https

案例六：动态网站LAMP lnmp

echo "<?php phpinfo(); ?>" >  /usr/share/nginx/html/index.php

nmcli connection modify ens160 +ipv4.addresses  192.168.10.131/24
nmcli connection up ens160

Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3)

补充：
自定义php界面配置解析
vim /etc/nginx/test_php.conf
server {
        listen 192.168.10.131:80;
        root /www;
        location = / {
        root           /www;
        fastcgi_pass   unix:/run/php-fpm/www.sock;
        fastcgi_index  index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include        fastcgi_params;
        }
}
echo "<?php phpinfo(); ?>" >  /www/index.php

动态网站解析

1. PHP 相关配置

echo "<?php phpinfo(); ?>" > /usr/share/nginx/html/index.php

解释：这是在创建一个简单的 PHP 文件，目的是验证 PHP 是否正常工作。
- phpinfo() 是 PHP 的内置函数，显示当前 PHP 环境的详细信息，如安装的模块、配置选项等。
- 该命令将生成一个 PHP 文件，当访问该文件时，会输出服务器上 PHP 的配置信息，通常用来检查 PHP 是否正确安装和配置。
- /usr/share/nginx/html/ 是 Nginx 的默认网页根目录。

2. 网络配置

nmcli connection modify ens160 +ipv4.addresses 192.168.10.131/24
mcli connection up ens160

Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3)

解释：
- nmcli 是 Linux 中的一个命令行工具，用于控制 NetworkManager，它允许你管理网络连接。
- nmcli connection modify ens160 +ipv4.addresses 192.168.10.131/24 用于修改网卡 ens160 的 IPv4 地址为 192.168.10.131，子网掩码为 /24（相当于255.255.255.0）。
- nmcli connection up ens160 启动并激活该网卡。
- 执行这些命令后，网络接口 ens160 会启用，并开始使用新的 IP 地址。

3. 自定义 PHP 配置（Nginx 配置）

#vim /etc/nginx/test_php.conf
server {
        listen 192.168.10.131:80;
        root /www;
        location = / {
        root           /www;
        fastcgi_pass   unix:/run/php-fpm/www.sock;
        fastcgi_index  index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include        fastcgi_params;
        }
}

解释：
- location = / 表示对于根目录 / 的请求，使用以下配置处理：
  - fastcgi_pass unix:/run/php-fpm/www.sock; 表示将 PHP 请求转发给 PHP-FPM 进程，该进程通过 Unix socket /run/php-fpm/www.sock 与 Nginx 通信。
  - fastcgi_index index.php; 指定默认的处理文件为 index.php。
  - fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 设置传递给 PHP 的 SCRIPT_FILENAME 参数，指向实际的 PHP 文件路径。
  - include fastcgi_params; 包含 FastCGI 的标准参数文件。

总结：

这段内容首先通过 nmcli 配置网络接口的 IP 地址，接着配置 Nginx 来处理 PHP 请求，并通过简单的 phpinfo() PHP 页面验证 PHP 和 Nginx 的配置是否正确。

4. 再次创建 PHP 测试文件

echo "<?php phpinfo(); ?>" > /www/index.php

解释：这是再次创建 PHP 测试页面，路径为 /www/index.php，与上面的 Nginx 配置相匹配，便于通过 Nginx 服务器来测试 PHP 的运行是否正常。

案例七:`autoindex on`;当不存在网页文件时实现文件共享

[root@node1 conf.d]# cat ./test_ip.conf
server {
    listen 192.168.10.130:80;
    root /www/ip/130;
    location / { #配置/==/www/ip/100下的资源文件
         autoindex on; # 增加内容
    }
}
[root@node1 conf.d]# mv /www/ip/130/index.html{,.bak}
[root@node1 conf.d]# touch /www/ip/130/{1,2,3,4}
[root@node1 conf.d]# systemctl restart nginx

发表于 2024-11-17 10:00 怎么昵称都被占用啊阅读(10) 评论(0) 编辑收藏举报来源

server-常用配置选项

1. listen

2. server_name

3. root

4. index

5. location

6. alias

7. proxy_pass

8. try_files

9. error_page

10. client_max_body_size

11. access_log 和 error_log

12. return

13. rewrite

14. ssl_certificate 和 ssl_certificate_key

总结