Home » Posts tagged "network" (Page 2)

GitHub 在 2/28 遭受的攻擊...

GitHub 在 2/28 遭受 DDoS 攻擊,蠻快就把事故報告丟出來了:「February 28th DDoS Incident Report」。

不過跟 GitHub 其他文章不太一樣,這篇算是 PR 稿吧,簡單來說就是花錢買 Akamai Prolexic 的過濾服務解決... Akamai 方的 PR 稿則是在「Memcached-fueled 1.3 Tbps attacks - The Akamai Blog」這邊可以看到。

17:21 UTC 發現問題,然後判斷超過 100Gbps,所以 17:26 決定讓 Akamai Prolexic 接管過濾:

At 17:21 UTC our network monitoring system detected an anomaly in the ratio of ingress to egress traffic and notified the on-call engineer and others in our chat system. This graph shows inbound versus outbound throughput over transit links:

Given the increase in inbound transit bandwidth to over 100Gbps in one of our facilities, the decision was made to move traffic to Akamai, who could help provide additional edge network capacity. At 17:26 UTC the command was initiated via our ChatOps tooling to withdraw BGP announcements over transit providers and announce AS36459 exclusively over our links to Akamai. Routes reconverged in the next few minutes and access control lists mitigated the attack at their border. Monitoring of transit bandwidth levels and load balancer response codes indicated a full recovery at 17:30 UTC. At 17:34 UTC routes to internet exchanges were withdrawn as a follow-up to shift an additional 40Gbps away from our edge.

就這樣而已,完全就是 PR 稿 XDDD

Inter-Region VPC Peering 的範圍大幅增加

AWS 的 Inter-Region VPC Peering 又多了不少區域了:「Inter-Region VPC Peering is Now Available in Nine Additional AWS Regions」。

本來是支援 us-{east,west}-{1,2} 這四個,現在又多了 9 個,來到了 13 個:

Starting today, Inter-Region Virtual Private Cloud (VPC) Peering is available in AWS EU (London), EU (Ireland), EU (Paris), Asia Pacific (Mumbai), Asia Pacific (Sydney), Asia Pacific (Singapore), Asia Pacific (Tokyo), Canada (Central) and South America (São Paulo) Regions in addition to AWS US East (Northern Virgina), US East (Ohio), US West (Northern California), US West (Oregon) Regions.

與現在的 region 表格比較,剩下的是 ap-northeast-2 (南韓首爾) 與 eu-central-1 (德國法蘭克福),其他公開使用的區域都在這波的公告全上了。(也就是美國政府專屬區域與中國區不算在內)

關於我在 Twitter 上貼的連結... (像是 Retweet,或是透過 Nuzzle/Pocket 貼的連結)

tl;dr:我把 Twitter 當暫存區,把手機上看到的連結丟到 Twitter 後再用桌機打開來看,所以有很多連結我雖然轉發,但未必看過。

我習慣在通勤或是睡前刷一下手機,看一下各類媒體有什麼資訊 (參考「為什麼我還繼續用 RSS (Feed)」這邊,是我找「未知的來源」的一部分),但這麼一來會遇到幾個問題:

  • 時間很零散,或是不長,所以有些文章我會看標題就先找個地方丟出來。
  • 手機上的廣告阻擋機制不太好,桌機的阻擋機制強大許多。

前陣子有些朋友問到為什麼 Twitter 上會有些明顯跟我的意見不同的 tweet,原因就是這樣啦...

Twitter 推出 Full-archive search API

在先前的「Twitter 要推出 Premium API」這篇文章裡有提到 Twitter 打算在 Standard 與 Enterprise 兩個層級中間推出 Premium API,算是補產品線的概念,提供 Startup 有中間階段的服務可以使用。

而在昨天,Twitter 推出了 Full-archive search API:「Introducing the premium full-archive search endpoint」,從 Rate limit 就可以看出來對 Enterprise 不夠用,但對 Startup 應該有機會使用:

台灣用 Twitter 的量偏低,也許對專注在台灣的應用來說還好,但對國外的單位來說應該是多了不少變化可以玩...

Amazon EC2 的可用頻寬提昇

AWSJeff Barr 宣佈了有 ENAEC2 instance 的頻寬提升到 25Gbps:「The Floodgates Are Open – Increased Network Bandwidth for EC2 Instances」。

分成三種,第一種是對 S3 的頻寬提昇:

EC2 to S3 – Traffic to and from Amazon Simple Storage Service (S3) can now take advantage of up to 25 Gbps of bandwidth. Previously, traffic of this type had access to 5 Gbps of bandwidth. This will be of benefit to applications that access large amounts of data in S3 or that make use of S3 for backup and restore.

第二種是 EC2 對 EC2 (內網):

EC2 to EC2 – Traffic to and from EC2 instances in the same or different Availability Zones within a region can now take advantage of up to 5 Gbps of bandwidth for single-flow traffic, or 25 Gbps of bandwidth for multi-flow traffic (a flow represents a single, point-to-point network connection) by using private IPv4 or IPv6 addresses, as described here.

第三種也是 EC2 對 EC2,但是是在同一個 Cluster Placement Group:

EC2 to EC2 (Cluster Placement Group) – Traffic to and from EC2 instances within a cluster placement group can continue to take advantage of up to 10 Gbps of lower-latency bandwidth for single-flow traffic, or 25 Gbps of lower-latency bandwidth for multi-flow traffic.

有 ENA 的有這些,好像沒看到 CentOS

ENA-enabled AMIs are available for Amazon Linux, Ubuntu 14.04 & 16.04, RHEL 7.4, SLES 12, and Windows Server (2008 R2, 2012, 2012 R2, and 2016). The FreeBSD AMI in AWS Marketplace is also ENA-enabled, as is VMware Cloud on AWS.

針對 Ubuntu 16.04 + PPPoE 時,OpenNTPD 的 -s 不會在啟動時直接校正的問題 workaround...

發現機器時間跟標準時間差了 40 秒左右,結果有些服務因為會看雙方時間,就不讓我跑... XDDD

找問題找了半天,發現開機後 ntpdate 會回報找不到伺服器,看起來是網路根本就還沒通就跑起來了:

Jan 25 13:10:30 home ntpdate[757]: name server cannot be used: Temporary failure in name resolution (-3)
Jan 25 13:10:30 home ntpdate[1171]: name server cannot be used: Temporary failure in name resolution (-3)
Jan 25 13:10:30 home ntpdate[1347]: name server cannot be used: Temporary failure in name resolution (-3)
Jan 25 13:10:30 home ntpdate[1410]: name server cannot be used: Temporary failure in name resolution (-3)

而理論上 與 openntpd 加上 -s 也會做類似的事情,所以這邊就在 /etc/default/openntpd 先加上 -s,讓他開機時強制對時一次,看看能不能解... 結果也是一樣在網路還沒通的時候就跑起來而失敗了:

Jan 25 13:10:45 home ntpd[1457]: no reply received in time, skipping initial time setting

由於這台機器是 HiNet 的 PPPoE,看起來有可能是某些條件沒寫好,造成執行順序不對... 所以就找個 workaround 來解決 @_@

後來找的方法是直接到 /etc/ppp/ip-up.d/ 下放一個 script 實作 workaround,直接在 PPPoE 連上後重跑 openntpd,然後用 hwclock 寫回主機裡,下次開機的時間就會比較準一些了:

#!/bin/sh -e

/usr/sbin/service openntpd restart
/sbin/hwclock -w

不過實際上還是要找看看要怎麼把 PPPoE 掛到 networking 那層行為裡面...

AWS KMS 可以在 VPC 內直接存取了

AWS Key Management Service 宣布支援 AWS PrivateLink Endpoint 了:「How to Connect Directly to AWS Key Management Service from Amazon VPC by Using an AWS PrivateLink Endpoint」。先前需要透過 Internet 流量存取 (透過 NAT、Proxy 之類的服務),現在則是可以接到 VPC 內直接用了:

Previously, applications running inside a VPC required internet access to connect to AWS KMS. This meant managing internet connectivity through internet gateways, Network Address Translation (NAT) devices, or firewall proxies.

With support for Amazon VPC endpoints, you can now keep all traffic between your VPC and AWS KMS within the AWS network and avoid management of internet connectivity.

KMS 需要 Internet 也是之前設計架構時比較痛的地方,現在總算是有個方向可以減少痛處了...

Jeff Barr 正在努力回顧去年 re:Invent 發表的東西:Inter-Region VPC Peering

居然是在補進度 XDDD 這是去年 AWS re:Invent 發表的功能:「New – Inter-Region VPC Peering」,在去年的時候也有提到了:「AWS 總算推出跨區 VPC Peering 了...」。

不過當時不確定跨區域時怎麼處理傳輸加密 (或者沒有處理?),這邊 Jeff Barr 補充提到了一些細節:

Data that passes between VPCs in distinct regions flows across the AWS global network in encrypted form. The data is encrypted in AEAD fashion using a modern algorithm and AWS-supplied keys that are managed and rotated automatically. The same key is used to encrypt traffic for all peering connections; this makes all traffic, regardless of customer, look the same. This anonymity provides additional protection in situations where your inter-VPC traffic is intermittent.

這樣架構會簡單不少,不需要自己再疊一層確保加密這件事情 (因為當時沒翻到資料說有加密...)。

Cloudflare 推出 Cloudflare Access,實作 Google 推出的 BeyondCorp

Google 之前發表的 BeyondCorp 採用不同的認證方式,改變企業會假設「內部網路是可信任」的這件事情:「Google 推的 BeyondCorp」,而 Cloudflare 也照著這個概念實作出一套產品,包成服務來賣:「Introducing Cloudflare Access: Like BeyondCorp, But You Don’t Have To Be A Google Employee To Use It」。


Access integrates out of the box with most of the major identity providers like Google, Azure Active Directory and Okta meaning you can quickly connect your existing identity provider to Cloudflare and use the groups and users already created to gate access to your web applications.

也可以走 TLSclient certificate 架構認證:

You can additionally use TLS with Client Authentication and limit connections only to devices with a unique client certificate.

而企業內部的服務剛好可以透過 Cloudflare 之前推出的 Wrap 串上去,不需要用 VPN 打通內部網路 (參考先前寫的「Cloudflare 推出的 Wrap 讓你不用在本地端開對外的 Port 80/443」):

If you want to use Access in front of an internal application but don’t want to open up that application to the whole internet, you can combine Access with Warp. Warp will make Cloudflare your application’s internet connection so you don’t even need a public IP.

費用的部分,第一個使用者免費,後續的使用者費用是 USD$3/month:

Access takes 5-10 minutes to setup and is free to try for up to one user (beyond that it’s $3 per seat per month, and you can contact sales for bulk discounts).