OpenStack 的防火墙规则流程

Contents [hide]
1 发现的问题 2 解决过程 3 删除临时错误数据 4 其实前面的解决办法是错的

发现的问题

3台虚拟机在同一宿主机，防火墙配置都一样，但是他们的网络表现不一致，有的能ping通，能ssh，有的能ssh，不能ping通。

解决过程

看完了在操作解决!在界面中点击主机发现主机规则上有一个default id=61,而未应用规则中还有一个default id=1,而我们的安全规则组中只存在一个default id=1,所以可以判定，default id=61是后来创建了和系统default id=1相同的防火墙，而实际上该防火墙在后面的操作中已经删除。 而主机在创建过程中，加载防火墙规则是以防火墙名称作为识别符号，而不是以防火墙的ID为识别符号，所以我们在创建防火墙的时候，需要要求防火墙名称不能重复。 而防火墙在删除的过程中，我们也需要知道是否有主机应用该防火墙才能决定删除与否。

删除临时错误数据

mysql> select * from security_group_instance_association where security_group_id=61;
+---------------------+------------+---------------------+------+-------------------+--------------------------------------+---------+
| created_at          | updated_at | deleted_at          | id   | security_group_id | instance_uuid                        | deleted |
+---------------------+------------+---------------------+------+-------------------+--------------------------------------+---------+
| 2014-11-13 09:54:04 | NULL       | 2014-11-13 09:56:55 | 1366 |                61 | e608f85a-0a8e-43bb-b1fc-07e3b454c8e7 |    1366 |
| 2014-11-13 09:55:52 | NULL       | 2014-11-13 09:58:49 | 1369 |                61 | 841dfad9-3b07-4cf8-a129-24660b1e3b5f |    1369 |

mysql> delete from security_group_instance_association where id =1372;
Query OK, 1 row affected (0.04 sec)

这样当前主机中就没有了default id=61的规则了。我们还要查找是否有主机名为default的防火墙规则。

mysql> select * from security_groups where name= "default" ;
+---------------------+------------+------------+----+---------+-------------+----------------------------------+----------------------------------+---------+
| created_at          | updated_at | deleted_at | id | name    | description | user_id                          | project_id                       | deleted |
+---------------------+------------+------------+----+---------+-------------+----------------------------------+----------------------------------+---------+
| 2014-07-01 03:32:30 | NULL       | NULL       |  1 | default | default     | 9c1ef7685d2a4730824cfb1eb1b0f7e0 | 8ce839b479074083aac8c7101a4e3593 |       0 |
| 2014-07-01 05:13:09 | NULL       | NULL       |  4 | default | default     | 59f5b5f637ff42319b7c54fca17e5599 | c8a6e5e40980442887255c53ae8a80ac |       0 |
| 2014-07-15 10:03:13 | NULL       | NULL       | 13 | default | default     | 1a0b21088e69480c860c32b9a2c733dc | f347580bc86e45d28753680267a581c2 |       0 |
| 2014-09-02 08:57:35 | NULL       | NULL       | 25 | default | default     | 8bef7299e2534b8dbbace89fddf17f80 | 02787b5a67b14bda8fab79caca734396 |       0 |
| 2014-09-09 10:18:35 | NULL       | NULL       | 27 | default | default     | b249207d7d3a4e40979d667b0fdd1d84 | 127857f79b8f4dd5a87f23298d3f72c2 |       0 |
| 2014-10-29 05:55:33 | NULL       | NULL       | 48 | default | default     | c336cc2d03774f89b9bccbbfb0d96f96 | 7bf38fd4bc1c4ba7ab8da412a7e4157c |       0 |
| 2014-11-06 06:30:55 | NULL       | NULL       | 53 | default | default     | 31f50cdf18954385af557a55d8ed0fbd | 0402811ede7247bf8b2b7eabba597d95 |       0 |
| 2014-11-27 03:10:11 | NULL       | NULL       | 67 | default | default     | 2f25e90d28b842cc992e1ef0f2766d90 | a89bd4ea815b46d3a58ccdbf05bc8bc0 |       0 |
+---------------------+------------+------------+----+---------+-------------+----------------------------------+----------------------------------+---------+

发现很多，为什么？

其实前面的解决办法是错的

我们发现这里的project_id都不一样！实际上是每个项目会有一个default。

storm的openstack主机不通是因为我们在操作防火墙的时候没有正确使用权限，每一个项目都有一个防火墙权限default,主机创建的时候会加载该项目的default防火墙。

并且每个项目自定义的防火墙只能使用该项目的用户名，密码登录上去进行操作。

   如果使用超级管理员的防火墙赋给具体项目的主机，将导致:如果nova-network重启，或机器重启，主机不能访问。

  结论：具体项目需要使用具体项目的用户登录对其主机进行操作。请@penny以后在测试的时候多测试普通项目的情况。

转载于:https://www.cnblogs.com/CLTANG/p/4332662.html