今天遇到個很妖的問題，雖然最終的解決方案讓人很無語，但是通過本次問題的解決還是加深了自己對網絡知識的認知。
故事是這樣的，我們負責開發的混合雲管理平臺最近要上一套新的openstack，所以要將新openstack管理進來。由於平臺是新搭建，我這邊開發環境也是新改造的，所以在openstack的對接發生一系列不順利的事情。最大的障礙是openstack創建起來的實例無法ssh登陸上去，整個排查過程如下：
1 網絡通不通？
通過ping Ip的方式排查，確定沒問題
2 端口通不通？
通過telnet ip+port的方式排查，確定沒問題
3 是否被安全組牆掉了？
登陸上openstack平臺，看到以IP地址段的方式配置的ssh入口，但是不確定自己的網絡是否在入口網段內。這是本篇的重點，後面會詳細說明，這裏先直接公佈答案，安全組沒問題，我的IP沒有被牆掉
4 鑑權是否有問題？
公司規定ssh要用key-pair方式，我檢查openstack上我管理的實例也設置了我添加的密鑰對，而且我也通過ssh -i XXX.pemuser@IP的方式指定了私鑰文件，但是確實登陸不上。關於Openstack密鑰對後面也會介紹下。
最終問題解決，是重新換了個密鑰對，只能懷疑是Openstack內部生成密鑰對的時候出現了bug，給我的私鑰與平臺上的公鑰不是一對…..
Anyway,開源的東西就是這樣，我已經習慣了，但是本文的重點不是吐槽OpenStack，它仍然是個非常優秀的產品，本文的重點是排查的過程中我對雲平臺網絡故障排查和SSH密鑰對這兩個知識點有了更深刻的理解。
路由追蹤：
Linux中traceroute命令查看全路徑路由
由於我的linux在VM裏，而且VM共享物理機網絡，所以看到路由到了192.168.44.2就沒有了，所以要回到物理機上繼續追蹤路由。
Windows的相同的命令是tracert命令
看到最終通過10.100.129.97這一跳進入到OpenStack的實例中。
然後我們有了路由信息後，再去對照下OpenStack安全組的22端口（SSH）的入參，但是是以IP段的格式配置的，所以我們要學會IP段是個什麼鬼，通過IP段我們能計算出什麼信息。
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這種方式，所以本篇的排查步驟所有平臺通用。