Tag: to

在 AWS 上用 pfSense 串接的細節

這邊講的是在 AWS 上想要串接不同帳號的流量 (也就是 site-to-site VPN)，不使用 AWS 自己提供的串接服務，而是用 pfSense 串接。

會自己搞主要有幾個考慮：

  • 考慮到 AWS Transit Gateway 的費用，每掛一個上去就要多收一次錢，另外上面處理的流量要再收費。
  • 應用的流量不大，所以用個 t2.nano 跑也有個 100Mbps 左右的 capacity，算是夠用了。
  • 而且應用在寫的時候也考慮到斷線後的處理，加上用戶端的網路本來就不怎麼穩定，AWS Transit Gateway 的 SLA 再怎麼高，我也還是得處理斷線時的後續機制，不如就不要那麼緊張...

在設定的時候要注意的事情：

  • EC2 的 Source IP/Destination IP 檢查要關掉，這算是基本盤。
  • VPC 內的 Routing 要確認過一輪。
  • EC2 上的 Security Group 對於 pfSense 的主機得全開，因為 pfSense 會丟出不屬於他自己 IP address 的封包，也會接收不屬於自己 IP address 的封包 (透過上面提到的 routing)，這些都還是會經過 Security Group 的檢查，而 Security Group 能設定的數量有限，基本上應該會全開...
  • pfSense 在設完 IPsec 後，同樣在 pfSense 上面的 firewall 需要手動加開，因為預設是關的。

其實這套作法就是在 AWS 還沒推出 Transit Gateway 前的作法，只是老方法還是很好用...

End-to-End Encryption 的標準？

看到「The Messaging Layer Security (MLS) Protocol」這個被提出來的標準，還在討論中...

簡介就說明了這個標準除了標準的 E2E 外，還設計了有效率的 Group 機制：

Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two participants need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands.

要設計機制的人可以拿來翻翻看...

Transport-Layer Encryption 與 End-to-End Encryption 的差異

EFF 的「Transport-Layer Encryption vs End-to-End Encryption - GIF」這篇文章介紹了 Transport-Layer Encryption 與 End-to-End Encryption 的差異，最後還給了一張 GIF 說明：

其實 GIF 給的範例還蠻清楚的，在 Transport-Layer Encryption 中服務提供商可以看到原始內容 (以 GIF 內提到的例子就是 Google)，而在 End-to-End Encryption 中就不行，只有傳輸雙方可以知道原始內容。

然後文章裡也提到了 Tor Messenger，可以吃現有的通訊軟體，然後在上面疊出 End-to-End Encryption。

Google 發表新的 TTS (Text-to-Speech) 技術 Tacotron 2

Tacotron 是 Google 發表的 TTS 技術 (i.e. 輸入文字，請電腦發音)，而前一版的 Tacotron 的錄音可以參考「Audio samples from "Tacotron: Towards End-to-End Speech Synthesis"」，論文則是在「Tacotron: Towards End-to-End Speech Synthesis」這邊可以看到。

這一版的則是在 Twitter 上看到有人提到：

這一版叫做 Tacotron 2，錄音可以參考「Audio samples from "Natural TTS Synthesis by Conditioning WaveNet on Mel Spectrogram Predictions"」，論文在「Natural TTS Synthesis by Conditioning WaveNet on Mel Spectrogram Predictions」。

這次在錄音頁面的最下面提供了盲測 (人類與 Tacotron 2 的錄音)，基本上已經分不出哪個是真人了...

在 Percona XtraDB Cluster 裡使用 async replication 時人工 failover 的方式...

在使用 Galera Cluster 時還是可以架設一般的 slave server (Percona XtraDB Cluster 則是 Percona 對 Galera Cluster 的封裝)，像是這樣的架構：

其中 node{1,2} 為 cluster，node3 則是傳統的 async replication，來源的 master 為 node1。

當 node1 掛掉時，我們沒辦法自動將 node3 的 master 從 node1 改指到 node2，因為 binlog 的位置不一定正確。

在「Changing an async slave of a PXC cluster to a new Master」則是提供如何人工用最簡單的方式介入。

主要是靠 Galera Cluster 會在 binlog 內寫入 Xid 這個值，這個值可以在 global status 內的 wsrep_last_committed 看到。因為這個值在全 cluster 都是同步的，就可以拿來人工尋找 binlog 位置後手動下 CHANGE MASTER TO，而不用 pt-table-sync 同步修老半天...

而且邏輯被整理出來以後，就有機會寫成程式自動化... 這算是一個不錯的開頭 :p