路由器chap的双向配置命令

路由器chap的双向配置命令,第1张

添加同步账户。向两台服务器上的mysql添加账户,进入Mysql命令界面,输入密码进入。如下图:执行Mysql命令,mysql> grant replication slave,replication client on *.*    -> to repl@'192.168.1.%' identified by '123456'说明:repl是账户名称,123456是对应的密码,192.168.1.%是局域网内可访问,也可指定某一台服务器,把%换成对应的IP即可。注:以上命令在A、B服务器上都要执行。

配置A服务器。找到mysql的配置文件my.ini,在[mysqld]下面添加以下配置:log_bin=mysql-binserver_id=5replicate_do_db=ftestsync_binlog=1log_slave_updates=1说明:log_bin:指定二进制日志文件的位置和命名,      server_id:MySql服务器标示,必须保证唯一,      replicate_do_db:要同步的数据库名称,多个用逗号隔开,此项可不配置,      sync_binlog:是否将二进制日志文件同步到磁盘上,大于0为开户,      log_slave_updates:将事件自动写到填制日志中注:保存文件后,要重新启动MySql服务,然后同样的 *** 作在B服务器上 *** 作一遍。

两台服务器配置完成以后,先在B服务器上开启复制功能。这一步不需要修改my.ini文件,只需要执行mysql命令,以下是命令:mysql> change master to master_host='192.168.1.2',    -> master_user='repl',    -> master_password='123456',    -> master_log_file='mysql-bin.000001',    -> master_log_pos=0说明:master_host:A服务器的IP地址      master_user:我们在第一步创建的同步账号      master_password:对应的账号密码      master_log_file:二进制日志文件名称,不一定是这个名称,可以用命令来查看                      用 show master status\g来查询名称和pos      master_log_pos:用上面的命令可以查出来此值

开启复制功能。用 show slave status\g 来检查复制是否已经正常运行,若Slave_IO_State为空,Slave_IO_Running、Slave_IO_Running为NO,则复制功能未运行,我们用 start slave来启动 复制功能。再用命令 show slave status\g 查看,这时我们看到Slave_IO_State为:Waiting for master to send eventSlave_IO_Running、Slave_SQL_Running为YES,表明配置已经成功,复制功能已经正常运行。然后配置A服务器,步骤和配置B服务器一样。注:一定要小心配置里面的参数,要把对应的master_host、master_log_file、master_log_pos配置正确。

测试数据是否同步成功,在A服务器上修改ftest数据库的一个表数据,然后在B服务器上查看,数据是否变化了呢,如果变化了,说明已经配置成功。然后修改B服务器的数据,再去A服务器上查看,如果数据也变化了,双向同步 的数据同步功能就成功了。

TLS其实是SSL,可能更正式的说法已经不用SSL了。TLS是一套基于非对称加密算法的安全传输协议,更严格来说,TLS先是通过非对称加密方式交换对称加密秘钥,然后采用对称加密算法进行安全传输。

非对称加密是这样的一把锁,有两把钥匙,任意一把钥匙可以把锁锁上,只有另一把钥匙才能将锁打开。这两把钥匙是成对的,可以互相解密。其中一把是公开的公钥,另一把是服务器持有的私钥。

任何人都可以用公钥加密一段消息发送给服务器,做到安全发送。另一方面,服务器可以用私钥加密一段消息,将消息明文和密文发送给接收者,以此证明自己的真实身份,这叫做签名。当然,现实中,是对消息的摘要进行签名加密,因为摘要比较小。

TLS的第一步,就是让发送者持有服务器的公钥。通常获得服务器公钥的方式,都是向服务器进行询问,然后由服务器明文发送过来的。为了保证这一步的安全性,确保明文发送过来的公钥没有被串改,我们又发明了证书

证书由服务器名称信息和服务器公钥组成,然后加上证书签发机构CA和签发机构对前面信息的签名。改用证书机制后,服务器以明文发送自己的证书信息,使用者用CA的公钥验证证书签名,核对相关的服务器信息,然后就可以信任服务器的公钥了。

至于CA公钥的传递方式,一般是内置的或者通过实体进行传递。

一般服务器是不限制使用者访问的,所以服务器配置了证书和私钥,让发送者能够安全的从第一步开始建立加密通信机制。即使使用者不验证服务器证书,TLS仍旧是以加密方式进行,虽然安全度不是最高,但是屏蔽掉无聊的阿猫阿狗访问已经足够了。

更进一步,服务器可以配置双向认证,配置CA证书并要求认证使用者的证书。那么使用者在访问前就要配置由CA签发的个人证书和私钥,在第一步开始时把自己的证书和随机签名发过去让服务器进行认证。

使用双向认证的时候,通信的安全性已经足够高了:消息是加密的,并且不太容易在某个环节被串改,而使用者必须经过服务器用自己的CA签发授权证书后才能访问服务。

TLS的运用其实应该非常广,只要不是内网服务,而是向不安全的互联网公开的服务,并且在通信上没有使用任何加密手段,也没有特别有效的客户鉴权,都应该使用TLS。

比如有时候因为某种原因,不得不向互联网暴露mysql,redis或者其他开源软件的服务端口,这种大作死的行为,软件自带的脆弱的客户鉴权机制就跟杂草一样一踩就倒,已经是业界人尽皆知的情形。

如果能为这些开放的服务端口加上TLS双向认证通信,基本能把侵害排除99%了吧。那如何给这些服务增加TLS安全通信呢?

首先, 把公开的服务改成内网服务 。

第二, 在服务器和客户端之间配置TLS tunnel ,通过tunnel转发客户端和服务器之间流量。有很多TLS tunnel客户端可以使用,这种方式也不会对原系统造成任何改动,所谓各司其职。


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/zaji/8444075.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-16
下一篇 2023-04-16

发表评论

登录后才能评论

评论列表(0条)

保存