因为骨干路由从OpenWRT换到了RouterOS,所以pxe服务器也得从新搭建。

过程不是很麻烦,但是RouterOS并没有nfs服务器,所以有些linux发行版的netboot需要nfs的,就需要什么额外的机器来当这个nfs服务器了,当然,kvm是个好东西。

可以参考之前的老文https://ferrets.space/2014/04/07/在家里做了个pxe服务器/,有些东西还是自己动手丰衣足食。

目前拿了个debian来做实验:

首先,去下载必要的文件,然后,找到

pxelinux.0
ldlinux.c32
vesamenu.c32
libcom32.c32
libutil.c32
pxelinux.cfg/default
linux
initrd.gz

接下来首先就是要编辑pxelinux的配置文件pxelinux.cfg/default,内容可以参考之前的文章,大概像这样子:

DEFAULT vesamenu.c32
PROMPT 0
MENU TITLE RouterOS PXE-Boot Server

label Ubuntu
        MENU LABEL Debian
        KERNEL debian/linux
        APPEND initrd=debian/initrd.gz
        TEXT HELP
                Starts the Debian Net installer
        ENDTEXT

至于各字段怎么自定义那就自行Google了,保存好配置文件之后呢,就将这么几个文件,丢到RouterOS的文件系统(真他么的不好用)里,比如说这样:

好了之后,就在ip/tftp菜单下面增加tftp文件的配置,比如说像这样:

请求文件名可以和实际文件名不一样,实际文件名是给RouterOS看的,请求文件名是给客户端看的,所以实际文件名可以自行决定。这里要主意的是ip地址填的是客户端的ip地址,而pxe服务器嘛,基本上并没有固定ip,所以ip地址最好还是填ip段。

配置就这么多,接下来只要在客户端执行pxe启动就行了。

参考:
https://a.iwshare.me/?p=48
https://plus.google.com/+GhostAssassin/posts/bMBbFYD6JZ3
https://www.liquidweb.com/kb/how-to-install-pip-on-centos-7/

 

最近听闻了一个模糊协议,叫做obfs,是开发Tor那群人搞出来的东西,用来模糊流量避免GFW的深度包检测,我尝试了一下可以做port forward,于是顺手再搭个梯子,感觉效果似乎比shadow socks好一点(心理作用?)。

搭建过程不算太麻烦,只需要一个叫做obfsproxy的软件就可以了,在ubuntu和debian似乎可以直接安装,不过pip安装的方法更加通用。

debian系的需求包

apt-get install gcc python-pip python-dev

redhat系的需求包

yum install python-pip python-devel gcc pycrypto

其中出现了我的CentOS软件源里并没有pip这种情况,可以实用python脚本来安装,方法如下:

curl "https://bootstrap.pypa.io/get-pip.py" -o "get-pip.py"
python get-pip.py

搞定之后可以用pip来安装obfsproxy

pip install obfsproxy

安装完毕后用法如下:

服务器端:

obfsproxy --data-dir ~/.obfs/ scramblesuit --dest 127.0.0.1:1194 --password ABCDEFGHIJKLMNOPQRSTUVWXYZ234567 server 0.0.0.0:1234 &

客户端:

obfsproxy scramblesuit –dest serveraddress:1234 –password ABCDEFGHIJKLMNOPQRSTUVWXYZ234567 client 127.0.0.1:56789 &

至此通道就搭起来了,例子中,客户端访问127.0.0.1:56789就相当于在服务器端访问127.0.0.1:1194。另外要注意的就是,obfsproxy似乎并不能保证数据加密的效果,最好搭配一个更加好的加密通道来使用。

不得不承认,不愧是服务器血统,这权限管理真的严格的,搭建好的owncloud报告没法发邮件,经过一番bing之后,找到了答案。

参考:http://stackoverflow.com/questions/25517281/swiftmailer-connection-could-not-be-established-with-host-smtp-gmail-com-conne

解决办法如下:

  1.  检查httpd_can_sendmail 是否设置为on
    getsebool httpd_can_sendmail
    • 如果返回的输出是 httpd_can_sendmail –> off , 运行
      setsebool -P httpd_can_sendmail 1
    • 如果你看到 httpd_can_sendmail –> on 那么跳到下一步
  2.  检查 httpd_can_network_connect 是否为on
    getsebool httpd_can_network_connect
    • 如果返回的输出是 httpd_can_network_connect –> off ,运行
      setsebool -P httpd_can_network_connect 1
    • 如果你看到 httpd_can_network_connect –> on 那么就跳到下一步
  3. 在服务器地址直接填ip而不是域名。

第三步感觉是另外的问题,而不是SELinux的权限阻止了邮件发送。

参考:https://blog.lysender.com/2015/07/centos-7-selinux-php-apache-cannot-writeaccess-file-no-matter-what/

一般的文件读写权限,所属用户和组这些先不讨论,毕竟这些相关的文档太多,也相对基础了点。这里记录的是CentOS种由SELinux引起的权限问题。

刚在家重新搭建了owncloud,这时候出现了一个非常诡异的权限问题,文件和文件夹的所有权都是apache(CentOS中默认的所属用户和用户组),但是访问owncloud的安装程序的时候却提示没有写权限。我试过用sudo切换到apache用户来执行touch创建文件,没问题,甚至写一个简易的php脚本来测试文件的读写,都没有遇到权限的问题,但是在使用浏览器访问的时候,php脚本就遇到了权限的问题。

经过一番Google,确定时SELinux的问题。

ls -Z可以看到一些额外的属性,像这样

drwxr-xr-x. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 application
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 index.php
修复的办法是
# SELinux serve files off Apache, resursive
sudo chcon -t httpd_sys_content_t /data/www/html/sites/mysite -R
# Allow write only to specific dirs
sudo chcon -t httpd_sys_rw_content_t /data/www/html/sites/mysite/logs -R
sudo chcon -t httpd_sys_rw_content_t /data/www/html/sites/mysite/uploads -R

httpd_sys_content_t – 允许apache读取文档
httpd_sys_rw_content_t – 允许apache读写文档
更加详细的标记说明,可以参考https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Confined_Services/sect-Managing_Confined_Services-The_Apache_HTTP_Server-Types.html

最近在折腾RouterOS,发现了一种相当有趣的用法,可以基于域名来选择路由。
首先,在ip/firewall/address lists中添加地址,地址可以是ip地址或者是域名,如果是域名,则RouterOS会自动进行一次域名解析,例如这样:
ip.firewall.addresslist
可以看到域名被自动解析成了ip地址,而解析出来的记录前面有个D标记,这意味着这是动态的,ip地址记录会随着dns解析记录而变更。

例子中,我就创建了一个叫做twitter.com的address list,这就可以在mangle中做点手脚了,就像这样:

我在prerouting链中添加了一个mangle,对目标地址在twitter.com列表中的路由都进行一个标记,打上一个叫做gfw的路由标记,在打上标记之后呢,就可以在路由表中,添加一个新的路由:

例子中,我有一个名字叫做gfw的接口,作用就不多说,因为是一个ppp的链接,所以gateway可以不填地址,直接填一个接口的名字,RouterOS可以处理这种情况。上图中,就是说所有打着gfw标记的路由,默认路由是走gfw这个接口。至此,全部基本设置已经完成。

这种addresslist配合mangle的用法除了策略路由还有很多其他的用法,比如说想要屏蔽某些网站,不让用户访问,这就可以在route中,选择这个unreachable的类型,这可比用web-proxy什么的实用多了,屏蔽掉的就不仅仅是80端口了,而是整个ip,无论是http还是https或者其他协议之类的,都会屏蔽掉。当然,在一些比较精细的控制方面,比如说允许访问http://www.helloworld.com但是不允许访问http://www.helloworld.com/something这种就无能为力了,只能向L7方面寻求帮助。


这种方法还有类似的,比如说传统一点,在address lists中,不用域名,而是用地址块,比如说这样:

把一整块地址加进去address lists里面,也是可以的,这样更加容易绕开方法里面的一种缺陷,因为这种方法只能对应一个域名,无法处理子域名或者使用通配符,如果是大量的域名,这会让工作变得相当的麻烦,需要脚本来进行处理。

这种方法有另外一种缺陷,就是面对着同一个域名会有大量ip地址或者是使用CDN网络的网站的时候,容易出问题,RouterOS本身缓存的dns解析地址一般来说只有2条,如果客户端使用了其他dns服务器而不是RouterOS本身作为DNS服务器的话有可能会存在这样一种情况:

RouterOS解析域名A,得到ip地址1ip地址2,并对ip地址1ip地址2进行了策略路由,客户端从dns服务器解析域名A,得到ip地址3ip地址4,这种情况下,客户端访问域名A就没法得到正确的策略路由。

对应的方法很简单,只要指定RouterOS作为客户端的dns服务器就可以了。如果是有客户端想使用其他dns服务器绕过策略路由,可以使用dnat进行劫持,如果是使用dnscrypt之类的软件的话,似乎没什么好对策,毕竟就算是gfw也只能阻挡而不能污染或者劫持dnscrypt。

前阵子打算把手里的垃圾平板刷个RemixOS来玩玩,稍微研究了一下fastboot刷机的方法,在这里做一下记录。
首先想办法进入fastboot模式,详情咨询各Android设备的提供商,装好驱动,连接Android设备与电脑。

fastboot oem write_osip_header
fastboot flash /tmp/partition.tbl partition.tbl
fastboot oem partition /installer/partition.tbl
fastboot erase factory
fastboot erase cache
fastboot erase system
fastboot erase config
fastboot erase logs
fastboot erase misc
fastboot erase data
fastboot oem stop_partitioning
fastboot flash boot boot.img
fastboot flash recovery recovery.img
fastboot flash fastboot droidboot.img
fastboot oem start_partitioning
fastboot flash system system.img
fastboot continue

只有第一句不知道是干啥的,其他的命令都很明显了,其实这部分是我从一个脚本和其他的刷机log里面总结出来的,仔细研究了一下,把命令补全和修正了。

最近耍了一个RouterOS的x86版,自带kvm虚拟机,看起来碉堡了,但是使用了之后只能吐槽说各种bug,就连官方的建立img都会报个“failed to copy files to image(s)”,结果我还是用ultraiso建立了一个空的img文件才能用。openwrt的镜像倒是方便,把kernel也放出来了,启动参数也提供了,在routerOS中一填就OK,没什么大问题。至于安装其他的linux。。。。目前我只成功安装了CentOS7。

在目前的RouterOS版本(6.36.2)中,kvm虚拟机的vnc是用不了的,这让我安装windows的企图破灭了,没GUI玩个蛋蛋。剩下一种可行的链接方式就只有console,这让安装linux变得可能。

但是下载下来的iso镜像不能直接使用,因为很多发行版发布的镜像的grub是默认没有console输出的,这让我们需要重新打包iso镜像。

首先,找到grub的配置文件,视情况而定,有可能是grub.cfg、grub.conf、isolinux.cfg几种,ubuntu的配置文件更加复杂,详细去官方的wiki慢慢研究。

在grub的配置文件中全局的位置(大概是在那一堆label前)插入一句

serial 0 115200

就能够让grub输出到console,至于这时候有没有视频输出,我没试过。这时候routerOS就可以用过console看到grub的输出了。

然后就是kernel的参数,这让kernel启动之后输出到console,这段写在kernel的后面,像这样。

label linux
  menu label ^Install or upgrade an existing system
  menu default
  kernel vmlinuz console=ttyS0,115200
  append initrd=initrd.img

之后就像正常安装linux一样安装就行了,不过只能够用文本的安装向导,详细查询各大发行版。

之前自己做了ec的key做csr的时候,startcom跟我说密钥长度太短,不给我用,现在看来是支持了。

ec的证书制作方法参见这个,现在startcom支持一个证书5个域名,基本上一个证书可以搞定。不过部署之后在ssllab检测的时候发现很多平台不支持,不知道为何,还真要认真的修整一下才行。

handshake-simulationChrome居然不支持,真是太让我吃惊了,IE系列基本上全跪,Android4.4.2和Android5都支持反而到了Android6又有问题,真是奇怪。

听闻了除了RSA和DSA以外,出现了新的加密算法,ecc(椭圆曲线加密算法),于是打算来尝尝鲜。

openssl目前的版本已经支持ecc,可以直接升成ecc的密钥和签署ecc的证书。用法大概是这样:

root@vultr:/tmp# openssl ecparam help
unknown option help
ecparam [options] <infile >outfile
where options are
 -inform arg       input format - default PEM (DER or PEM)
 -outform arg      output format - default PEM
 -in  arg          input file  - default stdin
 -out arg          output file - default stdout
 -noout            do not print the ec parameter
 -text             print the ec parameters in text form
 -check            validate the ec parameters
 -C                print a 'C' function creating the parameters
 -name arg         use the ec parameters with 'short name' name
 -list_curves      prints a list of all currently available curve 'short names'
 -conv_form arg    specifies the point conversion form
                   possible values: compressed
                                    uncompressed (default)
                                    hybrid
 -param_enc arg    specifies the way the ec parameters are encoded
                   in the asn1 der encoding
                   possible values: named_curve (default)
                                    explicit
 -no_seed          if 'explicit' parameters are chosen do not use the seed
 -genkey           generate ec key
 -rand file        files to use for random number input
 -engine e         use engine e, possibly a hardware device

首先检查一下当前openssl支持的密钥长度

 root@vultr:/tmp# openssl ecparam -list_curves
 secp112r1 : SECG/WTLS curve over a 112 bit prime field
 secp112r2 : SECG curve over a 112 bit prime field
 secp128r1 : SECG curve over a 128 bit prime field
 secp128r2 : SECG curve over a 128 bit prime field
 secp160k1 : SECG curve over a 160 bit prime field
 secp160r1 : SECG curve over a 160 bit prime field
 secp160r2 : SECG/WTLS curve over a 160 bit prime field
 secp192k1 : SECG curve over a 192 bit prime field
 secp224k1 : SECG curve over a 224 bit prime field
 secp224r1 : NIST/SECG curve over a 224 bit prime field
 secp256k1 : SECG curve over a 256 bit prime field
 secp384r1 : NIST/SECG curve over a 384 bit prime field
 secp521r1 : NIST/SECG curve over a 521 bit prime field
 prime192v1: NIST/X9.62/SECG curve over a 192 bit prime field
 prime192v2: X9.62 curve over a 192 bit prime field
 prime192v3: X9.62 curve over a 192 bit prime field
 prime239v1: X9.62 curve over a 239 bit prime field
 prime239v2: X9.62 curve over a 239 bit prime field
 prime239v3: X9.62 curve over a 239 bit prime field
 prime256v1: X9.62/SECG curve over a 256 bit prime field
 sect113r1 : SECG curve over a 113 bit binary field
 sect113r2 : SECG curve over a 113 bit binary field
 sect131r1 : SECG/WTLS curve over a 131 bit binary field
 sect131r2 : SECG curve over a 131 bit binary field
 sect163k1 : NIST/SECG/WTLS curve over a 163 bit binary field
 sect163r1 : SECG curve over a 163 bit binary field
 sect163r2 : NIST/SECG curve over a 163 bit binary field
 sect193r1 : SECG curve over a 193 bit binary field
 sect193r2 : SECG curve over a 193 bit binary field
 sect233k1 : NIST/SECG/WTLS curve over a 233 bit binary field
 sect233r1 : NIST/SECG/WTLS curve over a 233 bit binary field
 sect239k1 : SECG curve over a 239 bit binary field
 sect283k1 : NIST/SECG curve over a 283 bit binary field
 sect283r1 : NIST/SECG curve over a 283 bit binary field
 sect409k1 : NIST/SECG curve over a 409 bit binary field
 sect409r1 : NIST/SECG curve over a 409 bit binary field
 sect571k1 : NIST/SECG curve over a 571 bit binary field
 sect571r1 : NIST/SECG curve over a 571 bit binary field
 c2pnb163v1: X9.62 curve over a 163 bit binary field
 c2pnb163v2: X9.62 curve over a 163 bit binary field
 c2pnb163v3: X9.62 curve over a 163 bit binary field
 c2pnb176v1: X9.62 curve over a 176 bit binary field
 c2tnb191v1: X9.62 curve over a 191 bit binary field
 c2tnb191v2: X9.62 curve over a 191 bit binary field
 c2tnb191v3: X9.62 curve over a 191 bit binary field
 c2pnb208w1: X9.62 curve over a 208 bit binary field
 c2tnb239v1: X9.62 curve over a 239 bit binary field
 c2tnb239v2: X9.62 curve over a 239 bit binary field
 c2tnb239v3: X9.62 curve over a 239 bit binary field
 c2pnb272w1: X9.62 curve over a 272 bit binary field
 c2pnb304w1: X9.62 curve over a 304 bit binary field
 c2tnb359v1: X9.62 curve over a 359 bit binary field
 c2pnb368w1: X9.62 curve over a 368 bit binary field
 c2tnb431r1: X9.62 curve over a 431 bit binary field
 wap-wsg-idm-ecid-wtls1: WTLS curve over a 113 bit binary field
 wap-wsg-idm-ecid-wtls3: NIST/SECG/WTLS curve over a 163 bit binary field
 wap-wsg-idm-ecid-wtls4: SECG curve over a 113 bit binary field
 wap-wsg-idm-ecid-wtls5: X9.62 curve over a 163 bit binary field
 wap-wsg-idm-ecid-wtls6: SECG/WTLS curve over a 112 bit prime field
 wap-wsg-idm-ecid-wtls7: SECG/WTLS curve over a 160 bit prime field
 wap-wsg-idm-ecid-wtls8: WTLS curve over a 112 bit prime field
 wap-wsg-idm-ecid-wtls9: WTLS curve over a 160 bit prime field
 wap-wsg-idm-ecid-wtls10: NIST/SECG/WTLS curve over a 233 bit binary field
 wap-wsg-idm-ecid-wtls11: NIST/SECG/WTLS curve over a 233 bit binary field
 wap-wsg-idm-ecid-wtls12: WTLS curvs over a 224 bit prime field
 Oakley-EC2N-3:
 IPSec/IKE/Oakley curve #3 over a 155 bit binary field.
 Not suitable for ECDSA.
 Questionable extension field!
 Oakley-EC2N-4:
 IPSec/IKE/Oakley curve #4 over a 185 bit binary field.
 Not suitable for ECDSA.
 Questionable extension field!

然后就挑其中一个来制作ecc密钥

 openssl ecparam -genkey -name prime256v1 -noout -out ecc.key

参数中的noout是指不输出ec参数,genkey是生成密钥。

ecc密钥生成之后,就可以按照老方法来生成证书了。先生成证书请求:

openssl req -new -key ecc.key -out ecc.csr

再对其进行签署,可以自签署,或者交给其他的CA进行签署,或者自己用自己的CA证书进行签署:
自签署:

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

自己用自己的CA证书进行签署:

 openssl ca -cert ca.crt -extensions server_cert -days 375 -notext -md sha256 -in ecc.csr -out ecc.crt

签署服务器证书用server_cert插件,签署客户端证书用usr_cert插件。

大功告成。

现在dns污染真的很烦人,总是会莫名其妙地遇到然后导致访问失败,折腾了相当久都没有什么好办法。dnsmasq上加上了chinalist,可以搞定国内的大部分域名,大部分CDN也能用,但是国外的地址解析一直都不是很稳定。

试过直接经梯子用国外的dns服务器,但是由于梯子本身的不稳定,上网的体验太差了,动不动就解析不了ip地址。然后经过一番搜索,得知了dnscrypt已经移植到了openwrt上,于是果断已看,还真有。

root@Belkin ~ # opkg list | grep dnscrypt
dnscrypt-proxy - 1.4.3-1 - dnscrypt-proxy provides local service which can be used directly as your local resolver or as a DNS forwarder, encrypting and authenticating requests using the DNSCrypt protocol and passing them to an upstream server. The DNSCrypt protocol uses high-speed high-security elliptic-curve cryptography and is very similar to DNSCurve, but focuses on securing communications between a client and its first-level resolver.

结果装上之后一试,哎呦,速度还可以,也比较稳定,没出现什么经常性的抽风。

安装的过程非常简单,opkg install dnscrypt-proxy之后修改/etc/config/dnscrypt-proxy,只需要取消注释一行就可以用了

config dnscrypt-proxy
    option address '127.0.0.1'
    option port '5353'
    option resolver 'cisco'
    # option resolvers_list '/usr/share/dnscrypt-proxy/dnscrypt-resolvers.csv'
    # option ephemeral_keys '1'

至于可以用的公用解析器,可以参考public DNSCrypt resolvers。

dig了一下,查询时间大概在200-ms,效果良好~

root@Belkin /etc/config # dig youtube.com -p 5353 127.0.0.1

; <<>> DiG 9.9.8-P3 <<>> youtube.com -p 5353 127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40410
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;youtube.com.                   IN      A

;; ANSWER SECTION:
youtube.com.            300     IN      A       216.58.203.14

;; Query time: 194 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Thu Jun 30 23:51:44 CST 2016
;; MSG SIZE  rcvd: 56

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6494
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;127.0.0.1.                     IN      A

;; AUTHORITY SECTION:
.                       2158    IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2016062901 1800 900 604800 86400

;; Query time: 188 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Thu Jun 30 23:51:44 CST 2016
;; MSG SIZE  rcvd: 113

然后配置dnsmasq,修改/etc/dnsmasq.conf,添加一行

conf-dir=/etc/dnsmasq.d

然后把https://raw.githubusercontent.com/felixonmars/dnsmasq-china-list/master/accelerated-domains.china.conf下载到/etc/dnsmasq.d/,再去修改dnsmasq的转发为127.0.0.1#5353

dnsmasq转发

或者直接修改/etc/config/dhcp

config dnsmasq
    option domainneeded '1'
    option boguspriv '1'
    option localise_queries '1'
    option local '/lan/'
    option domain 'lan'
    option expandhosts '1'
    option authoritative '1'
    option readethers '1'
    option leasefile '/tmp/dhcp.leases'
    option resolvfile '/tmp/resolv.conf.auto'
    option rebind_protection '0'
    list server '127.0.0.1#5353'