網絡
    今天寫了一個自動拉起腳本,調試的時候出了點狀況,導致啟動了很多個openvpn實例,并且還在不斷啟動中。對于使用同證書的實例,默認會后面的踢掉前面的,所以網絡就陷入了還沒連上就被踢掉的循環,無法登陸,也就失去了控制。

    首先嘗試打開server端的duplicate-cn支持。這樣每個連接都會分配到一個單獨ip,不會互相踢掉。但由于進程太多,每個進程連接上后都試圖刷新路由表,導致路由表不停變更,網絡依然不能連通。

    這時就需要從server端限制:只能有一個客戶端連接上。首先調研了下是否支持只接受第一個連接上的實例而忽略掉后面的連接請求,發現是沒有這個特性的。因為如果正常使用中客戶網絡閃斷,這種情況下就不得不等待很久session超時后才能連上,用戶體驗太差。

    對于網絡層面的控制,iptables是個很有效的利器。于是采用了如下的方式:
    1,首先設置DROP掉指定機器所有入包     iptables -I INPUT 1 -p udp -s xxx.xxx.xxx.xxx -j DROP
         這時候所有連入請求都會timeout。
    2,然后使用tcpdump host xxx.xxx.xxx.xxx
         查看所有連入請求的來源端口,選取其中一個。
    3,執行          iptables -I INPUT 1 -p udp -s xxx.xxx.xxx.xxx --source-port yyyyy -j ACCEPT
         為這個實例單獨開一個入口。

等待幾秒,等待其重試連接,這時候只有這一個實例可以連入。成功恢復連接。

這里需要注意,第一步應使用DROP而不是REJECT,因為前者會讓請求方重試的時間間隔更長一些,為后續操作贏得更多時間。









Tags:

dns緩存nscd原理及相關知識

[| 不指定 2016/06/12 15:05]
    由于sshd是支持包轉發的。所以最近配置了一些規則,將指定uid的包轉發到指定目標。通過統計包數量,發現tcp的數據是正常的,但dns請求包不生效,還是走原路徑。tcpdump抓包發現確實是發到系統配置的resolver那里去了。看了眼sshd的代碼,是使用了libc里面的res_query方法來做域名解析的。像gethostbyaddr也是使用的這個方法。考慮到可能是這里發生的問題,于是用strace抓包看了一眼。發現該方法是先去連接/var/run/nscd/socket。如果成功,則發送域名解析請求,然后由nscd服務進行dns解析。所以按uid來抓包會失效。

    nscd是一個緩存服務。會緩存passwd、hosts、resolv三類信息。和dnsmasq類似。先試圖停掉nscd服務再進行嘗試,果然進程在試圖連接/var/run/nscd/socket失敗后,轉為連接resolv.conf里指定的server,可以成功被iptables轉發。


    定位了具體問題原因后,開始尋找更多解決方案。停掉nscd固然最簡單,但會導致整個系統都失去dns緩存,對性能還是有一定影響的。于是尋找優化一些的方案。思路是對于指定進程繞過nscd機制。


    研究了一下。發現nscd為了避免自己的請求發送給自己導致死循環,調用了一個__nss_disable_nscd方法。調用該方法后即可關閉nscd機制。于是改動了一下sshd源碼,重新編譯了一個。再次重試。果然ok了。












Tags: ,
最近由于需要撥號到l2tp vpn服務器上。弄了一下linux下的客戶端xl2tpd
其實xl2tpd既可以當服務端。又可以當客戶端。在本文里只介紹客戶端相關的功能

安裝比較簡單。apt-get或者yum直接搜xl2tpd,裝上即可。沒有自己編譯也很簡單。
注意依賴了/dev/ppp設備。如果不存在,需要
mknod /dev/ppp c 108 0
創建一下。

配置文件/etc/xl2tpd/xl2tpd.conf
[lac myvpn]
name = 'myvpn'
lns = myvpn
pppoptfile = /etc/ppp/peers/myvpn.l2tpd
ppp debug = yes

配置文件 /etc/ppp/peers/myvpn.l2tpd
remotename myvpn
user "xxx"
password "ooo"
ipcp-accept-local
ipcp-accept-remote
refuse-eap
require-mschap-v2
noccp
noauth
noipdefault
mtu 1410
mru 1410
usepeerdns
debug
lock
connect-delay 5000


然后就可以啟動xl2tpd。然后echo "c myvpn" > /var/run/xl2tpd/l2tp-control
來連接了。

注意ppp的配置里有:noipdefault  選項。
其他很多資料都沒有這一項。包括阿里云的官方文檔。但在debian系里面。不加這個且機器有內網網卡時,是不太好用的。
連接的ppp0設備會自動使用內網ip。導致很多奇葩的事情發生。

noipdefault這個選項表示不使用本地默認ip分配策略。直接用服務器分配的。如果不要求每次撥號都使用固定ip的話,建議加上該參數




Tags: ,

更換了泛域名證書

[| 不指定 2015/01/22 00:26]
    之前搞的單域名ssl證書要到期了,最近正好搞了個泛域名證書,換上了。

    好久沒更新blog了,比較忙。刷一下新文章。

dns glue record的查看與校驗

[| 不指定 2013/03/31 21:23]
    在使用自有dns服務器時,一般會使用glue record。即使用ns01.snooda.com作為snooda.com的dns服務器,這樣就會遇到一個先有雞還是先有蛋的問題。為了解決此問題,會使用glue record,即由com域dns服務器提供ns01.snooda.com的ip地址。一般這個記錄在域名注冊商那里修改。但怎么查看是否修改成功了呢?這里dig就派上了用場。


    使用dig +trace +nosearch +all +norecurse snooda.com

    在返回的結果里,我們會在com域dns返回的結果中,看到一個”ADDITIONAL SECTION“,里面提供了兩個a記錄。這就是glue record。由于我們試圖解析snooda.com,所以先從com域dns服務器獲取snooda.com的dns服務器地址,com域dns判斷結果是一個snooda.com的子域,所以是glue record。所以不但返回了dns地址,還返回了對應的a記錄。

    用這個方式就可以檢驗設置的glue record是否生效。





Tags:
    當使用國外服務器時,經常會發現,下載速度只有十幾k。平時可能不太注意,認為服務器帶寬不足,或者自己使用的寬帶不給力,其實很有可能原因并不在此。

    由于光速的局限性,延遲會比較高(即使光沿直線傳播,太平洋一個往返也要一百多毫秒)。并且由于距離較遠,途徑路由跳數較多,并且網絡擁堵的原因。經常會發生丟包的情況。

    對于平時使用最廣泛的TCP協議來講,發送端發出包后,接收端會回復ACK,表示自己收到了。用這種機制來保證可靠性。但對于高延遲鏈路來講,如果每發送一個包都等待應答,那么大部分時間都在等待數據包到達,而鏈路則空置了。為此一般會采用滑動窗口技術。即在窗口滿之前,發送端一直發送包,然后收到應答后將確認收到的包從窗口中移除。這樣可以提高鏈路利用率。

    TCP還有一個特性則是擁塞控制。當發送端檢測到鏈路發生丟包時,則會主動縮小窗口大小以減慢發送速度,避免擁塞。不過對于跳數較多的鏈路來講,只要有一個路由不夠穩定丟包,就會被發送端判斷為擁塞,從而影響網絡速度。

    為了解決丟包問題,最簡單粗暴的方法就是雙倍發送,即同一份數據包發送兩份。這樣的話在服務器帶寬充足情況下,丟包率會平方級降低。

    這種方式下,直接優點是降低丟包率,直接缺點是耗費雙倍流量。一些延伸影響是更容易觸發快速恢復邏輯,避免了丟包時窗口縮減過快。一定程度也能提高網絡速度。


    最近比較忙,空閑時間做了一個最簡單的程序,試用效果很好,在一臺VPS上測試后發現,未開啟時單線程下載、ssh管道速度在十幾K級別。開啟后可以達到平均300KB+的速度。效果非常明顯。但對于不加速就可以跑滿帶寬的類型來講(多線程下載),開啟后反而由于多出來的無效流量,導致速度減半。所以對于多線程/高速鏈路,這個方案是不適合的。

     目前版本是最簡單的邏輯,未來會進行細化(主動觸發快速恢復、快速重傳等),降低流量浪費,提升加速效果。

     目前程序起名net-speeder,相對于修改協議棧來講,由于后者需要重新升級編譯內核,使用用戶態程序部署更方便,穩定性更高,兼容性更好。缺點則是性能開銷稍大和自由度有損失。總體比較起來,個人使用還是使用用戶態程序更合適一些,特別是在虛擬機中使用(OpenVZ,LXC等虛擬機無法自己定制內核)。




      項目托管地址:http://code.google.com/p/net-speeder/
                           https://github.com/snooda/net-speeder


      

關注微信公眾號隨時接收最新開發進度。近期將會推出加速效果體驗ssh/pptp賬號
點擊在新窗口中瀏覽此圖片


Tags:
    最近發現有個問題,一個自制的webserver在應答前端請求時,總是要處理1s以上,似乎是由于哪里等待了1秒。研究了下發現:Expect: 100-continue這個東東。

    100-continue這個狀態碼之前是很少遇到的。這個是http1.1協議為了提高效率設置的。當客戶端要POST較大數據給webserver時,可以在發送http頭時帶上Expect: 100-continue,服務器如果接受這個請求,應答一個HTTP/1.1 100 Continue,那么客戶端就繼續傳輸正文,否則應答417,客戶端就放棄傳送剩余的數據了。這樣就避免客戶端吭哧吭哧傳了一大堆數據上去,結果服務端發現不需要的情況。

    libcurl在不同版本里邏輯不同,有的版本libcurl會在POST數據大于1024字節的時候發送100-continue請求,有的版本則不會。我們用到的libcurl版本會發送,而自制webserver不會應答這個請求,客戶端等待1s鐘沒有收到肯定或否定的應答,還是繼續傳輸了正文,雖然邏輯上并沒有問題,但速度上就慢了下來。

    加了下邏輯,對100-continue進行應答,速度馬上提高很多。



Tags: ,
    最近一直苦于沒有什么話題來寫博,今天終于找到一個。    有人疑惑為什么使用fq代理后訪問某些網站反而快了,疑問是不是某防火墻在搗鬼。    世界上一共40億個ipv4地址,ipv6就更多了,為啥訪問任意一個地址就能訪問的到?是誰維護了這40億個地址的分布?從這個ip到那個ip途徑的路由是誰來指定的?

    從我們電腦的上網來講,接入網絡就能上網,這個是很稀松平常的事,但如果同時接入兩個網絡呢?比如一根有線一根無線,那么流量是怎么走的呢?這個時候電腦里的路由表就發揮了作用,運行route print命令,可以看到一行行的規則,每個網絡包都會從上到下匹配這些規則,如果匹配上,就按規則指定的端口轉發出去。一般同一時間段內流量只從一個網卡流出。


    進一步講,家里多人上網的話會有路由器,對于家里電腦間傳送文件和訪問公網網站,流量是分發到不同端口的,路由器的路由表規則就不再是簡單的向某一個端口分發,而是針對不同的ip段走不同的分發規則,一般內網ip流量分發至對應內網端口,公網流量統一從公網端口發送。

    對于公網上的流量,一樣是按照路由表指示的路徑行進,路由表是如何生成的呢?

    首先不會是每個ip一條記錄,因為數據量太大,這里就用到了ip的分塊,最早是用a,b,c三類來劃分,后來由于粒度太粗,后來改用子網掩碼的形式,子網掩碼規定的范圍是ip段的網絡名,其余部分是可用地址范圍(不全是,本文內容不做涉及),這樣,路由表的尺寸就能縮減不少。

    互聯網是網狀的,每個路由都會于1個或多個其他路由進行連接,連接可能斷開,可能阻塞,可能新建,所以路由表也會不斷更新,一個路由器如何得知互聯網上其他路由間的連接狀態從而更新自己的路由表,就需要用到路由交換協議,比如RIP,路由器將自己所知道的路由信息廣播給周邊路由,這樣網絡連通信息就能不斷擴散至全網。


    不過網絡上的路由器成千上萬,如果所有路由都按照這種方式,效率非常低下。

    現實中,網絡劃分為了不同的自治系統:AS,AS的編號由ICANN管理,成為一個AS需要有多線路的連通能力,像電信、聯通都是AS,一些較大的網絡服務商也可以申請AS號和自己的地址空間。每個AS系統內部維護自己地址空間的路由信息,AS系統間的邊界路由器使用BGP協議交換各自地址空間,這樣,發往一個AS的網絡流量只需要發給對應AS的邊界路由即可。不過如果AS間網絡帶寬較小或者不穩定,就會有“跨網絡互通問題”,就像國內電信和聯通間訪問效果不佳。

    早期國內主機解決網絡互通問題會使用雙ip的方案,同時接入一個電信ip和一個聯通ip,再搭配智能dns,可以較好的解決了互通問題。但還是有浪費ip地址、智能dns解析不夠準確的問題。

    后來就有了多線主機有的也叫bgp主機,只有一個ip,但同時接入多個線路,有雙線、三線、甚至五線。對于接入的線路,均可以實現較好的訪問效果。原理就是機房同時實現和多條線路的互通,將ip廣播至每條線路。

    對于服務器可以通過接入多線的方式提高接入性能,對于上網者來說也一樣。但同時開通兩條甚至多條寬帶的成本是比較高的,這樣我們就可以借助多線服務器來提高網絡訪問速度。比如遼寧教育網用戶訪問遼寧聯通,需要繞行至東北教育網節點甚至中國教育科研網節點,但如果借助一臺部署在遼寧、同時接入教育網線路和聯通線路的服務器中轉。網絡速度就能大大提高。對于訪問國外站點也是一樣。
    

    資料:
    查看全球bgp路由表:http://www.ris.ripe.net/bgpviz/
    telnet:route-views3.routeviews.org




    
Tags: , ,
    臺灣vps已經不靠譜了。于是開始遷移至香港,臺灣vps決定放棄。這時遇到了問題,就是dns又變成了單點。

    所幸服務商提供了slave dns功能,這個還是很少見的,不過這個功能對于我來說實在太有用了。

    估計也是這個服務太過小眾,服務商的功能也是bug多多,發了無數ticket才搞定。

    首先是管理頁面就有問題,添加slave dns記錄后刷新頁面,記錄就消失了。也不生效。通知他們修正了下,搞定了。

    然后發現添加記錄倒是成功了,但沒有slave dns來拉取記錄。而這時我操作太激進,把ns記錄都切換過來了,結果導致落到slave dns上的請求都返回空記錄了,發現后急忙切換回來。發ticket通知他們,告訴我要在allow-transfer里把所有的服務器ip都加上,試了下,似乎nslookup - slave dns ip 使用指定dns后還能成功了。很高興。

     但過了一會發現請求還是落到了主dns上,并且有很大概率的失敗,于是再次聯系客服。客服說在添加slave dns記錄時我的master dns ip沒有記錄上,重新添加不行,后來客服搞了一下,可能修復了bug,可以了。

     然后發現slave似乎不支持notify請求,我用rndc reload更新記錄時沒有slave來請求。

     先是添加also-notify,通知所有slave dns,因為默認是通知所有ns記錄里的服務器,不過我并沒有用到全部slave server,所以要手動添加其他服務器收到通知。

     發現還是無效,猜測可能是出口ip不對,于是添加notify-source指定了notify時的來源ip。

     重啟bind9, 成功了。


Tags: ,
    之前經常拿來備份數據的企業郵箱滿了,而qq為了賺錢不讓企業郵箱擴容了,所以沒辦法,準備換成可自動擴容的qq郵箱。但發現一些大郵件無法收到,查看mail.log后發現發送超時。錯誤信息:
dsn=4.4.2, status=deferred (lost connection with mx3.qq.com[119.147.6.81] while sending message body

而用企業郵箱的時候從來沒有這個問題,排查了下,把postfix發送超時設長,無效,還是發送一分鐘后就超時,看來是qq的mail服務器設置了1分鐘超時,如果1分鐘內郵件發送不完就斷開連接。

    tracert了一下到兩個郵件服務器的路由,前若干跳都是一樣的,但后續設置了禁ping,無法得知具體路徑。

    看來我的機器到qq郵箱mail服務器速度比較慢,而到企業郵箱速度快,有可能是qq郵箱設置了速度限制之類的東東,只能給企業郵箱開自動轉發,把郵件中轉一下了。



Tags:
分頁: 1/2 第一頁 1 2 下頁 最后頁 [ 顯示模式: 摘要 | 列表 ]
黄se大片全集,s8视频 情色视频,国产在线久久播放,天天鲁天一鲁,第一色色资源站 一色屋,3X免费视频 <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>