使用Apowersoft將線上影片錄影

1. 先開啟網頁 (在此以FireFox為例)

https://www.apowersoft.tw/free-online-screen-recorder

點選「開始錄製」

2、接著點選「下載啟動器」

3、接著選擇「儲存檔案」

4、接著打開剛下載儲存的檔案，選擇「執行」進行安裝

5、接著會進行安裝，安裝完成後開啟網頁https://www.apowersoft.tw/free-online-screen-recorder

再點選「開始錄製」

6、此時會出現啟動程式的提示，請點選『開啟鏈結』

7、接著會詢問安全性設定，請選擇同意執行。

8、開啟任一網頁或軟體，此時會發現有一個白色的視窗，接著可以拖曳各個角度的圖示來放大或調整視窗大小。

9、調整完成後，按下紅色的Rec鈕，就可以開始錄影了。

10、此時會提示是否準備就緒，確認後點選確定鈕。

11、錄製完成後，點選藍色暫停鈕 (或者要進行其它調整時也需按此按鈕)

12、最後點選打勾播放或儲存此影片，或者點選打叉放棄此影片。

13、最後點選向上箭頭的圖示，將檔案另存新檔。一般常見的儲存格式是MP4檔，要記得你存放在哪邊囉。

長大的壞處

我常想，長大最大的壞處就是要不斷的跟長輩告別。

這幾天，跟我們同住近兩年岳母狀況不太好。隨時都可能跟我們告別。

她這一輩子過得很辛苦，遠比日劇的阿信艱難。好不容易快退休了，卻又發現好幾個宿疾...
在幾個手術後，她鼓起勇氣希望能搬離那個傷害她很深的家，於是和老婆討論後就把她接來一起住。想著讓她晚年能舒服一點。

所謂的家人，就是指住在同一個屋簷下的人。不知不覺，你會習慣她的存在。上班前，多一個人關心你；下班後，多一個人招呼你；坐在餐桌前，多一個人陪你聊天。

她總是覺得叨擾了你，所以在身體狀況許可時，你總是看到她在幫忙做家事、幫忙掃地、幫忙洗碗、幫忙晾衣服，即使你跟她說：「不急，放著我待會會處理」。她總是帶著羞赧的微笑說：「沒關係，我閒著也是閒著，找點事情做」

於是在你不注意時，她默默的成為你的家人。

也只有在突然失去她之後，你才會發現有多痛。不知為何，心裡總是有個地方空蕩蕩的。在餵兒子吃點心時，告訴兒子這是阿嬤買的，你忍不住傷感；在洗衣服時，你看著她留下的衣服，你不禁失落；在掃地時，你會想起那痀僂的身影，忍不住神傷；在吃飯時，你會突然發現沒有人跟你聊天，好像少了點什麼；在洗碗時，你看著她空空的碗，才想到這個碗的主人再也不會回來了；在經過她的房間時，你總忍不住會看一下空蕩蕩的床，好像她還斜躺在那裡，想著她會看到你跟你打聲招呼。

如果你的長輩還有些夢想，請幫他實現吧。去年想辦法帶著病軀的她去日本做了瘋狂的三日賞楓之旅；今年計畫著要帶她來個三日賞櫻之旅，沒想到再也沒辦法實現了⋯
有時候人的離去總是這麼突然，請記得在有機會時對身邊的人好一點。

從醫院回家後，看到她幫我剝的半個橘子 (我們習慣一人吃半個，先吃的人會留半個給對方)。我不禁大哭失聲...

IPSec HA (Active Active) 網路規劃與實作

日前公司在談一個案子，架構圖大概如下：(我有再加一些料，例如最右邊的R6/R7/R8在客戶的架構上，其實是同一個ROUTER)。

另外箭頭的方向是我懶得修，其實是雙向的。


需求很簡單，R1至R8之間，要有雙路由，需要提供Active-Active 架構 (load sharing或load balance)。然後R2與R6建IPSec，R3與R7建IPSec。

其實這個架構乍看不難。依我的直覺就是R2與R6建GRE tunnel，R3與R7建GRE tunnel，然後在上面跑IPSec，接著在R2及R3上設定static route往R6/R7送，反之亦然即可。

斷線的偵測則利用GRE tunnel的keepalive功能就好了，不過這樣就不好玩了。

因此我的計畫是在沒有GRE tunnel的基礎上，用IPSec把這個架構弄出來。

測試心得及說明簡述如下：
1、所有router上都跑RIP，但是R2,R3,R6,R7不要把192.168.1.0及192.168.2.0轉出來，目的是要確認lan的流量確定是經過加密的。
2、R2與R6的WAN 建IPSec，R3與R7的WAN 建IPSec，這個IPSec要on DPD功能 (keepalive)
3、R2/R3/R6/R7的crypto map要有reverse  route static的功能。這邊要注意的是，這個static route若在route map裡面加了ACL就會自動產生，即使IPSec斷了也不會消失，acl會有兩段，一個是wan to wan的部份，一個是192.168.1.0 to 192.168.2.0的部份。要提醒一下在本機加上reverse route會讓對方的routing在自己身上產生。

4、我本來打算R2/R3/R6/R7的rip把static route轉進來，這樣就不需要在r1/r8上下192.168.1.0/192.168.2.0的static route，但如上所述，reverse static route不會消失...因此rip會一直把routing轉出來給R1/R8。所以只好改回一開始的解法，讓R1的WAN對R6/R7的WAN(利用前述的RIP讓他們可以互PING) 做IP SLA monitor然後再設定一個TRACK這個track是對應到ip sla的，最後把192.168.2.0的static route 套用這個TRACK (當然，會有兩組IP SLA monitor和兩個track對應不同的wan IP)。R8的狀況也相同。這樣一來，如果斷線時ip sla down,track down, static route就會消失。

實測的結果讓人很滿意。 確實有Active-Active及備援的效果。

RRD檔爆值導致數值爆表時的處理方式 (RRD破圖)

之前有建一些RRD檔來收設備的流量，後來就順便弄一個日報表看來有沒有線路需要擴頻或者調節頻寬的。一開始也順順的，但後來就開始遇到爆量這件事。

後來由於有更重要的報表要參考這些流量，因此只好認真的來解決這個問題。
在網路上翻了一下之後就確定問題了。

原因是我建立rrd檔時，沒有設定正確的上限值，為避免麻煩我都是定『U』，代表不做上限。

但設備的2^64的counter遲早都是會爆的，它爆了之後，rrdtool不曉得該如何處理，就幫你單純的用減法來減，因此在剛爆的時候，數值一減都很驚人。 (試想0-2^64的值有多大)

有想過很多的解法，例如異常值不進RRD檔，這邊的作法有兩種，一者是若第一名的流量是第二名的10倍以上就放棄它。(然後用遞迴來處理....)，第二種作法是先確定線路的最大頻寬若流量大於它就將之放棄。但經過實驗證實，這兩種方法都很爛。所以才有了修正RRD檔的作法 。

修正RRD檔的作法其實也很簡單，就把它dump出來，修正一下上限再倒回去就好了。問題是，上限該怎麼決定呢？


如果你有用cacti的話，可能會有印象，cacti使用的值的來源應該就是它去抓取介面的SNMP MIB的ifSpeed的值。用這個值其實就可以了。一般是10^8(100M)或10^9(1G)

但我的線路有很多種，往上還有2.5G及5G，我就設定為10^10。(不過在實務上我還是把它除以8，因為我認為ifSpeed是bit，應該要用snmpget到的byte來算會比較準)

2017/01/20 補充後續：
之前設定3.1250000000e+08的時，估計最大頻寬是2.5G，果然今天就破圖了

 

不過這也證明了，小弟的假設是正確的。max的準確設定值確實應該以BYTE來計算。

但如果要偷懶還是以cacti的預設值：10,000,000,000來填入吧，這樣最大值是80Gbps流量，除非用100Gbps的port，不然應該很難再破圖。

要讓在內網的網管主機收SNMP trap真的是有夠麻煩

要讓在內網的網管主機收SNMP trap真的是有夠麻煩

1、該內網主機不能上網，但可以從辦公室開SSH過去。
2、所以你要修改主機的sshd_config，讓root可以遠端登入也要可以建tunnel
3、然後你從oa連過去後，兩邊自動建tunnel
4、接著你在兩個tunnel 上塞IP再把它拉起來。
5、設定一下routing，讓內網主機可以連到yum的更新主機或rpmfind
6、接著要來裝相關的套件

我主要卡在5，因為routing設定了，但還是不能連外。在tunnel上和對外的網卡都有收到封包。想了一下是因為沒有做NAT，所以補一下就好了

本日關鍵：

arp -sD 10.0.0.200 eth0 pub 這一行是不需要做的。

然後要刪除的話，語法不熟很難試出來，因此記錄一下：

arp -i eth1 -d 10.0.0.200 

這樣就好了。

參考網頁如下，大致上都正確，除了不需要arp -sD之外

https://help.ubuntu.com/community/SSH_VPN 

LLMNR的封包造成設備異常，用戶無法連線？真的假的？

去年吧(2015), 我們台中的設備據說被用戶的LLMNR打到設備生活不能自理(用戶不能上網)，廠商建議我們設定ACL來保護我們的設備。又請網管部門開發了監控機制，如果有LLMNR的封包造成封包被drop就會觸發告警。

幾個月前(2016/08？)，高雄收到了封包被drop的告警。但奇怪，不是已經設定了阻擋LLMNR的ACL，怎麼還會觸發告警呢？

所以我只好作一個LAB來驗證。

BRAS的設定如下：
 





接著我在電腦上安裝了Colasoft Packet Builder來製造LLMNR的封包。






 


Destination MAC、IP和port就依RFC的規定來設定。

最後把電腦的網路線接上設備準備開始測試。


 
用tcpdump來觀察，可以看到IP、Port都有照我們的規劃在送


我們在interface裡把access-group cbu-attack-vpn拿掉。接著看一下ACL有沒有生效。






admin-acl是進入context的acl，看起來seq 300都維持在750。並沒有增加

接著把interface上的acl加回。


看起來是有match的啊，這個時候我們回頭檢查drop。但drop一直沒有增加，不管我封包打多快都一樣。
。

最後我們再把interface上的acl拿掉。但drop還是沒有增加...



結論：
我無法確定當時的drop packet是因為line card無法處理這些LLMNR封包的關係 (或許有關係，但我設定每1ms就打封包，然後一次打1萬個也無法觸發drop，感覺跟速度及量無關 (我是用1G線路對接應該比用戶家裡的VDSL快吧)。
而且就算我沒有設定acl也是不會有drop，所以我無法確認LLMNR是否因為ACL被攔阻與否造成drop。這也與我們之前2015年8月遇到的，明明有開acl卻還是有drop相同。

因此，我大擔的假設。之前台中的drop根本就與LLMNR無關...

題外話，最奇怪的是，admin-acl突然match seq 300的數量增加了..怪哉

明明之前沒有match的啊....