今天遇到個很妖的問題，雖然最終的解決方案讓人很無語，但是通過本次問題的解決還是加深了自己對網路知識的認知。

故事是這樣的，我們負責開發的混合雲管理平臺最近要上一套新的openstack，所以要將新openstack管理進來。由於平臺是新搭建，我這邊開發環境也是新改造的，所以在openstack的對接發生一系列不順利的事情。最大的障礙是openstack建立起來的例項無法ssh登陸上去，整個排查過程如下：

1 網路通不通？

通過ping Ip的方式排查，確定沒問題

2 埠通不通？

通過telnet ip+port的方式排查，確定沒問題

3 是否被安全組牆掉了？

登陸上openstack

4 鑑權是否有問題？

公司規定ssh要用key-pair方式，我檢查openstack上我管理的例項也設定了我新增的金鑰對，而且我也通過ssh -i [email protected]的方式指定了私鑰檔案，但是確實登陸不上。關於Openstack金鑰對後面也會介紹下。

最終問題解決，是重新換了個金鑰對，只能懷疑是Openstack內部生成金鑰對的時候出現了bug，給我的私鑰與平臺上的公鑰不是一對…..

Anyway,開源的東西就是這樣，我已經習慣了，但是本文的重點不是吐槽OpenStack，它仍然是個非常優秀的產品，本文的重點是排查的過程中我對雲平臺網路故障排查和SSH金鑰對這兩個知識點有了更深刻的理解。

路由追蹤：

Linux中traceroute命令檢視全路徑路由

由於我的linux在VM裡，而且VM共享物理機網路，所以看到路由到了192.168.44.2就沒有了，所以要回到物理機上繼續追蹤路由。

Windows的相同的命令是tracert命令

看到最終通過10.100.129.97這一跳進入到OpenStack的例項中。

然後我們有了路由資訊後，再去對照下OpenStack

IP段：

先要了解子網掩碼

子網掩碼的作用在於定義了哪些是網路標識，哪些是主機標識，子網掩碼必須與IP地址一起出現才有意義。

雖然有3類：

A類：255.0.0.0　　　11111111.00000000.00000000.00000000
B類：255.255.0.0　　11111111.11111111.00000000.00000000
C類：255.255.255.0　11111111.11111111.11111111.00000000

但是凡是連續的1開頭0結尾的32位二進位制都是合理的子網掩碼，例如

255.255.255.252　11111111.11111111.11111111.11111100

我們一般會將ip/0-32的方式來標識一個ip段，其中0-32代表了掩碼中有多少個0.

子網掩碼的意義是：該子網能支援多少個IP，計算方式是後面有多少個0就有2的N次方個ip。

如上有2個0，2的2次方是4，該子網有4個ip

例如10.100.129.97/30，我們來計算下子網有多少個IP：

00001010.01100100.10000001.01100001
&
11111111.11111111.11111111.11111100
=
00001010.01100100.10000001.01100000
=
10.100.129.96（這個是網路標識）

網路標識相同的機器才會處於同一網段，這是網路標識的意義，從演算法上可以反向推斷出，是否處於同一網段是由IP+子網掩碼2部分決定的。

而剛才也說過該子網能支援4個IP，那IP是哪些呢？ 從網路標識的演算法上可以推算出，ip的第四段為01100000、01100001、01100010、01100011，也就是：10.100.129.96、10.100.129.97、10.100.129.98、10.100.129.99

子網雖然具有4個IP，但並不能都用於主機IP，與掩碼0位對應IP的二進位制位全1，是留給子網自己組播用的，也就是說00001010.01100100.10000001.01100011=10.100.129.99不能作為主機IP。網路標識也不能作為主機IP。所以該子網可以分配給主機的IP只有10.100.129.97、10.100.129.98

子網支援的IP數是2的N次方（N=後面子網掩碼後面幾個0），能分配給主機的IP還要再減2.

那現在問題又來了，既然子網掩碼我們可以自己定義的，為什麼還要做A類、B類、C類這種劃分呢？其實ABC是代表著子網的規模，有了這些基本的劃分後我們先根據自己的需要大體知道自己屬於哪個規模，也就是哪類子網，然後再決定是否啟用自定義的掩碼更精細的管理網路。

舉個例子，我現在需要搭建500臺主機的區域網，那麼我知道C類子網只能支援250多個，所以C網是不夠用的，我的網路是一個B網（B網能支援6萬多臺主機）。當然標準B網對我500臺機器來說臺奢侈了，我可以選擇用255.255.253.0，或者為了公司規模預見性的多配置一些，255.255.252.0就差不多了。

我們剛才講了網路標識的概念，在同一個網路中還有主機標識的概念，代表著該主機在該網路中的標識。主機標識的計算與網路標識正好相反，是IP與掩碼取反後再AND，還是以10.100.129.97/30為例，如下：

00001010.01100100.10000001.01100001
&
00000000. 00000000.00000000.00000011
=
00000000. 00000000. 00000000.00000001
=
0.0.0.1（這個是10.100.129.97這個IP在網路中主機號）

同理可以計算出

10.100.129.96：0.0.0.0

10.100.129.98：0.0.0.2

10.100.129.99：0.0.0.3

主機號全0表示網路本身，全1表示網路廣播，這倆不能作為主機IP使用，這點前面已經介紹過了。

SSH Key-Pair

Key-Pair是非對稱加密的一組金鑰（對稱加密非對稱加密在https://blog.csdn.net/yejingtao703/article/details/78712386這一篇中有詳細介紹，而且在https://blog.csdn.net/yejingtao703/article/details/78723276這一篇https領域也有廣泛應用），public的公鑰由被請求端保留，而且在OpenStack的UI平臺上是可以看得到，而private的私鑰是由ssh請求發起端保留的，只有建立key-pair的人才擁有。

SSH的key-Pair是單向的，public key是鎖，private key是鑰匙，也就是說我們只能拿鑰匙去開鎖，而不能用鎖去訪問鑰匙。所以說如果有雙向訪問的需求需要2套key-pair，各自拿一個自己的鎖和對方的鑰匙。

OpenStack中設定金鑰對有2種方式：

1在平臺上建立金鑰對，生成金鑰對的同時操作員可以下載到該金鑰對的私鑰pem檔案。

2 操作員自己通過ssh-keygen-f filename方式建立金鑰對，將公鑰上傳到平臺。

無論哪一種方案其結果都是一樣的，平臺保留公鑰，操作員自己保留私鑰。雲平臺在建立例項時將公鑰設定到~/.ssh/authorized_keys中，這樣操作員就可以用自己手上的鑰匙開啟雲實例上的鎖了。

回到我今天遇到的問題，最終換了一套鑰匙和鎖就解決了，可能是OpenStack生成了一對劣質產品，也可能鑰匙在傳輸的構成中被汙染了，總之鑰匙打不開鎖。

我這裡用的是OpenStack，AWS、阿里雲、騰訊雲等平臺也是安全組+key pair這種方式，所以本篇的排查步驟所有平臺通用。