1、TPROXY是什么 你可能听说过TPROXY，它通常配合负载均衡软件HAPrxoy或者缓存软件Squid使用。 在所有"Proxy"类型的应用中都一个共同的问题，就是后端的目标服务器上看到的连接的Source IP都不再是用户原始的IP，而是前端的"Proxy"服务器的IP。 拿HAProxy举例来说，假设你有3台后端Web服务器提供服务，前端使用HAProxy作为负载均衡设备。所有用户的HTTP访问会先到达HAProxy，HAProxy作为代理，将这些请求按照指定的负载均衡规则分发到后边的3台Web服务器上。这个操作本身没有任何问题，因为HAProxy就应该是这么工作的。但是对于某些对于用户的访问IP有限制的敏感应用，问题来了: 后端服务器上的ACL无法限制哪些IP可以访问，因为在它看来，所有连接的SOURCE IP都是HAProxy的IP。 这就是为什么TPROXY产生的原因，最早TPROXY是作为Linux内核的一个patch，从2.6.28以后TPRXOY已经进入官方内核。TPRXOY允许你"模仿"用户的访问IP，就像负载均衡设备不存在一样，当HTTP请求到达后端的Web服务器时，在后端服务器上用netstat查看连接的时候，看到连接的SOURCE IP就是用户的真实IP，而不是haproxy的IP。TPROXY名字中的T表示的就是transparent(透明)。 TPROXY主要功能如下: 1.重定向一部分经过路由选择的流量到本地路由进程(类似NAT中的REDIRECT) 2.使用非本地IP作为SOURCE IP初始化连接 3.无需iptables参与，在非本地IP上起监听 如果想要了解TPROXY的具体工作原理，请参考作者本人写的PPT，介绍的比较详细了: http://people.netfilter.org/hidden/nfws/nfws-2008-tproxy_slides.pdf 2、Centos 7系统，iptables透明网桥实现 在2.6.28以后的内核中，TPROXY已经是官方内核的一部分了。CentOS 7 默认使用的是3.10内核，所以不需要额外添加。 在一切开始之前，需要安装两个包：bridge-utils，ebtables #yum install bridge-utils ebtables 首先建立网桥：(使用bridge) 示例 桥接eth0 与 eth1 网口 /sbin/modprobe bridge /usr/sbin/brctl addbr br0 /sbin/ifup eth0 /sbin/ifup eth1 /usr/sbin/brctl addif br0 eth0 /usr/sbin/brctl addif br0 eth1 /sbin/ip link set br0 up 在网桥上设置IP地址，示例 # ifconfig br0 192.168.10.90 netmask 255.255.255.0 这样就完成了网桥的配置工作。但这时配置没有保存下来，如果要重启有效，需要添加网桥的配置文件，可以添加如下文件： /etc/sysconfig/network-scripts/ifcfg-br0 DEVICE=br0 TYPE=Bridge BOOTPROTO=static ONBOOT=yes IPADDR=192.168.10.90 NETMASK=255.255.255.0 /etc/sysconfig/network-scripts/ifcfg-eth0 TYPE="Ethernet" BOOTPROTO="none" NAME="eth0" DEVICE="eth0" ONBOOT="yes" BRIDGE="br0" /etc/sysconfig/network-scripts/ifcfg-eth1 TYPE="Ethernet" BOOTPROTO="none" NAME="eth1" DEVICE="eth1" ONBOOT="yes" BRIDGE="br0" 这样，机器重启以后也会保留已配置好的网桥。 ...

0.接触Linux恐怕对SSH再熟悉不过了，还有scp，sftp各种方便的功能，一般的使用都需要ip:port（如果不是默认22的话），但有些情况比较特殊，就是想连接一台内网主机（比如公司内网，当然你肯定做不了Port Forwarding，除非你想在公司防火墙上拆个洞）。稍懂一点网络的童鞋会明白，Internet上去主动连接一台内网是不可能的，一般的解决方案分两种，一种是端口映射（Port Forwarding），将内网主机的某个端口Open出防火墙，相当于两个外网主机通信；另一种是内网主机主动连接到外网主机，又被称作反向连接（Reverse Connection），这样NAT路由/防火墙就会在内网主机和外网主机之间建立映射，自然可以相互通信了。但是，这种映射是NAT路由自动维持的，不会持续下去，如果连接断开或者网络不稳定都会导致通信失败，这时内网主机需要再次主动连接到外网主机，建立连接。 1.理论的介绍完了，下面实际操作： A要控制B A主机：外网，ip：123.123.123.123，sshd端口：2221 B主机：内网，sshd端口：2223 无论是外网主机A，还是内网主机B都需要跑ssh daemon 1.1.首先在B上执行 $ ssh -NfR 1234:localhost:2223 user1@123.123.123.123 -p2221 这句话的意思是将A主机的1234端口和B主机的2223端口绑定，相当于远程端口映射（Remote Port Forwarding）。 这里每次需要输入A主机user1的登陆密码，后面会讲到解决办法。 这个时候，B主机可以将端口转发到B主机内网可达的任意一个IP地址，只要将上面的localhost改成相应的IP地址即可。比如，B主机想将端口转发到内网的一个IP：192.168.1.100，port：3389，规则可以如下写： $ ssh -NfR 1234:192.168.1.100:3389 user1@123.123.123.123 -p2221 1.2.这时在A主机上sshd会listen本地1234端口 $ ss -ant State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 127.0.0.1:1234 *:* 1.3.像平时一样连接到A主机的1234端口就可以控制内网B主机了 $ ssh localhost -p1234 1.4.如上，这个时候只能在A主机的本地连接1234端口，因为监听在了127.0.0.1上，这个时候如果想在另外一台机器访问A主机而连接到B主机，一般有两种方法解决这个问题。 a)、使用iptables进行本地端口转发 b)、修改sshd.conf让ssh的远程端口转发可以监听在除127.0.0.1以外的IP上 这里我们采用第一种方法作示例： 首先执行： sysctl -w net.ipv4.conf.eth0.route_localnet=1 (用本地真实的网卡代替eth0) 默认情况下，该值为0，它指示内核不要路由到127.0.0.0/8的外部流量。这只是为了安全，因为这样的流量不正常。 然后添加iptables规则： iptables -t nat -I PREROUTING -p tcp -d 123.123.123.123 --dport 1234 -j DNAT --to-destination 127.0.0.1:1234 这样，只要访问123.123.123.123的1234端口就自动连接上B主机的2223端口了。 ...

最近在一台服务器上处理包过滤的程序，服务器上集成了6块 Intel 82574L 的千兆网卡，这块网卡出来的比较早，性能也比较均衡，很多服务器设备上也有集成。包过滤程序使用了pf_ring作为抓包的模块，操作系统使用的是CentOS 6.9，内核是2.6.32版本。在测试的时候发现几次很异常的情况，抓包一段时间以后（时长不定），被抓包的网卡上就再也没有流量上来了。使用ifconfig -a 查看 eth1 Link encap:Ethernet HWaddr 00:0C:29:F6:7F:E1 inet addr:192.168.2.192 Bcast:192.168.2.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fef6:7fe1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1738132 errors:0 dropped:6356865 overruns:0 frame:0 TX packets:1328354 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:840530707 (801.5 MiB) TX bytes:1706701844 (1.5 GiB) 发现RX dropped 非常的高，自没有流量上来以后，所有的包都被丢弃了。 再查看一下ethtool -S eth1 NIC statistics: rx_packets: 1740086 tx_packets: 327205 rx_bytes: 847640005 tx_bytes: 1652632934 rx_broadcast: 0 tx_broadcast: 0 rx_multicast: 0 tx_multicast: 0 rx_errors: 0 tx_errors: 0 tx_dropped: 0 multicast: 0 collisions: 0 rx_length_errors: 0 rx_over_errors: 0 rx_crc_errors: 0 rx_frame_errors: 0 rx_no_buffer_count: 0 rx_missed_errors: 6356865 tx_aborted_errors: 0 tx_carrier_errors: 0 tx_fifo_errors: 0 tx_heartbeat_errors: 0 tx_window_errors: 0 tx_abort_late_coll: 0 tx_deferred_ok: 0 tx_single_coll_ok: 0 tx_multi_coll_ok: 0 tx_timeout_count: 0 tx_restart_queue: 0 rx_long_length_errors: 0 rx_short_length_errors: 0 rx_align_errors: 0 tx_tcp_seg_good: 91453 tx_tcp_seg_failed: 0 rx_flow_control_xon: 0 rx_flow_control_xoff: 0 tx_flow_control_xon: 0 tx_flow_control_xoff: 0 rx_long_byte_count: 847640005 rx_csum_offload_good: 822676 rx_csum_offload_errors: 0 alloc_rx_buff_failed: 0 tx_smbus: 0 rx_smbus: 0 dropped_smbus: 0 里面的rx_missed_errors很高。 ...

最近把小主机升级到了ESXI6.5，debian 9也已经出来了。所以就配了个虚拟机装了最新的debian 9，安装一切无话。安装好以后配了nginx等相关服务。系统装好后测试一切正常，就放着不动了。 等第二天，发现博客首页上不去了，去ping debian 9的IP地址也ping不通了，去ESXI管理界面界面上一看，vCPU占用100%，感觉情况不妙。打开系统终端控制台，发现无论输入什么都没有反映，系统已经挂了的感觉，按crtl+alt+ins也没反应。最后只能强制重启了，当时以为是意外。遂没有管它。当再过了一天，又出现同样的情况了，就说明不是意外。查看了系统的相关日志，看不出有什么异常的地方，想起来装过vmware tools ，当即把它卸载了再观察。可是再过了一天，情况还是老样子，又死了。所以，应该和vmware tools没什么关系。 没有头绪，只能放狗去搜，找到一篇老外的讨论： VM becomes unresponsive, some vCPUs are 100% utilized 里面有讲到应该和网卡类型和 vmxnet3 有关 All of the VMs use the vmxnet3 vNIC. On one occasion, after resetting the VM, I looked at the kernel log and it displayed some vmxnet3 messages which led me to believe the problem may be caused by http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2005717. I moved some VMs to the host running ESXi v5.0 and the problem still occurred, so that theory was debunked. Also, this problem has happened quite a few times but those vmxnet3 kernel messages only showed up on one occasion. ...

centos5/redhat5 自带的GCC已经很低了，一般是4.1左右，但如果安装一些软件需求高版本的gcc就比较麻烦了。 除了下源码编译安装外，这里介绍通过YUM源来直接安装 wget http://people.centos.org/tru/devtools-2/devtools-2.repo -O /etc/yum.repos.d/devtools-2.repo yum install devtoolset-2-gcc devtoolset-2-binutils devtoolset-2-gcc-c++ ln -s /opt/rh/devtoolset-2/root/usr/bin/* /usr/local/bin/ hash -r gcc --version 大功告成！

The Software Collections ( SCL ) Repository 参考：https://wiki.centos.org/AdditionalResources/Repositories/SCL devtoolset-3 版本默认安装的是4.9.2，devtoolset-4 版本默认安装的是5.3版本，还可以往上类推。 CentOS 6/7 official support this. You don’t need third party repository. And gcc version is 4.9.2 in CentOS’s repo. yum install centos-release-scl-rh yum install devtoolset-3-gcc devtoolset-3-gcc-c++ To use the updated tools, start a new shell using the scl command: scl enable devtoolset-3 bash You may also need to reset your PATH environment variable, which might be set in ~/.bashrc or other profile file. If you need to change it, it should point to /opt/rh/devtoolset-3/root/usr/bin/:$PATH

version `GLIBC_2.14’ not found 解决方法. 一般出现类似次问题是当前运行系统Glibc版本低于编译环境Glibc版本造成Glibc版本兼容性造成的. 通常可以使用-static链接成静态程序即可解决. 不过经过google大神发现还有另外一种方法可以在使用动态库的环境下规避此类问题. 首先查看APP Glibc 兼容性.看当前app使用了哪些Glibc版本. # objdump -p app ... Version References: required from libc.so.6: 0x06969194 0x00 05 GLIBC_2.14 0x0d696913 0x00 04 GLIBC_2.3 0x0d696914 0x00 03 GLIBC_2.4 0x09691a75 0x00 02 GLIBC_2.2.5 然后查看当前app引用了GLIBC_2.14中哪些函数 # nm app |grep GLIBC_2.14 ... U memcpy@@GLIBC_2.14 ... 也可以使用 objdump 查看app动态引用符号表. # objdump -T app |grep GLIBC_2.14 ... 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.14 memcpy ... 上例显示app引用 2.14 版本中的memcpy函数. 下面将用到 gcc 的一个特性实际上是ld的特性.可以将引用符号绑定到一个特定版本.只需在.c文件中写入类似代码. asm(".symver original_foo,foo@VERS_1.1"); 即可. ...

在过去的十年间，大多数新型开源操作系统已从移动市场转向物联网市场。本文介绍了面向物联网的许多新型开源操作系统。我们之前的文章介绍了开源物联网框架，以及面向物联网和消费者智能家居设备的Linux和开源开发硬件。 除了介绍面向物联网的新型嵌入式Linux发行版外，我还介绍了OpenWrt等几款比较老的轻量级发行版，它们在这个领域迎来了新生。虽然Linux发行版主要针对网关和集线器，但是面向物联网的非Linux开源操作系统取得了同样迅猛的发展，它们可以在微控制器单元(MCU)上运行，通常面向物联网边缘设备。 请记住一点：如今几乎所有的操作系统都声称有一些物联网连接功能，所以本文这份名单有点随意。本文介绍的开源操作系统大多数符合下列属性：占用内存少、电源效率高、模块化可配置通信堆栈，对特定的无线和传感器技术提供强有力的支持。一些项目注重物联网安全，许多非Linux操作项目专注于实时确定性(real-time determinism)，这有时是工业物联网的一个要求。 我通常远离这类Linux发行版：被列入“轻量级”这一类，但是仍然主要针对桌面使用或便携式U盘实施， 而不是针对无外设设备。不过，像LXLE或Linux Lite这些轻量级Linux发行版可能是适合物联网的选择。 非Linux开源平台方面的选择来得比较困难。毕竟，大多数轻量级实时操作系统可用于物联网。我侧重于主要平台，或者是似乎为物联网带来最大希望的平台。其他潜在的候选对象可以在这个开源实时操作系统网站(http://www.osrtos.com)上找到。 本文未提到Windows 10 for IoT Core，它对创客来说是免费的，支持AllJoyn和IoTivity，但是并非完全开源。还有许多商用实时操作系统是物联网领域的大玩家，比如Micrium的μC/OS。 九大基于Linux的开源物联网发行版 1.Brillo ――在谷歌发布Brillo后的一年里，这款基于安卓的轻量级发行版日益受到嵌入式板卡的追捧，比如英特尔Edison和Dragonboard 410c，甚至得到一些模块上计算机的追捧。Brillo的未来与谷歌的Weave通信协议密切相关，它需要这种协议。Weave为Brillo带来了发现、配置和验证等功能，Brillo可以在只有32MB内存和128MB闪存的设备上运行。 相关链接：https://developers.google.com/brillo/ 2.华为LiteOS――别将华为的LiteOS与开源Unix变种混为一谈，据说它基于Linux，但确实是一种非常精简的实施方法。一年多前宣布的LiteOS声称可以作为只有10KB大小的内核来部署。LiteOS应用广泛，从基于MCU的设备，到与安卓兼容的应用程序处理系统，不一而足。这款可定制的操作系统拥有诸多功能，比如零配置、自动发现、自动联网、快速启动和实时操作，它提供广泛的无线支持，包括LTE和网状网络。LiteOS随华为的敏捷物联网解决方案交付，它驱动窄带物联网(NB-IoT)解决方案。 相关链接：http://www.huawei.com/minisite/iot/en/liteos.html 3.OpenWrt/LEDE/Linino/DD-Wrt――由于物联网热潮，久负盛名、专注网络的OpenWrt嵌入式Linux卷土重来。轻量级OpenWrt经常出现在路由器和基于MIPS的WiFi板卡上。早期的衍生版(比如DD-Wrt和面向Arduino的Linino)最近更是出现了分支版本。Linux嵌入式开发环境(LEDE)项目承诺治理会更透明、发布周期会更稳定。 相关链接：https://openwrt.org 4.Ostro Linux――今年8月，英特尔选择用于英特尔Joule模块(运行在最新的四核凌动T5700片上系统上)后，这款基于Yocto Project的发行版一举成名。Ostro Linux符合IoTivity，支持众多的无线技术，还提供一种传感器框架。它非常注重物联网安全，提供操作系统、设备、应用程序和数据等层面的保护，包括加密和MAC。该发行版包含在无外设版本和媒体(XT)版本中。 相关链接：https://ostroproject.org 5.Raspbian――还有另外一些面向Raspberry Pi的发行版，它们更专门面向物联网，不过迅速成熟的Raspbian仍是佼佼者。由于它是面向在最广泛使用的物联网平台上的DIY项目的最流行的发行版，开发人员可以向众多项目和教程寻求帮助。由于Raspbian支持面向Node-JS的可视化设计工具Node-RED，我们觉得没有太充分的理由选择专门针对RPi、面向物联网的Thingbox。 相关链接：https://www.raspbian.org 6.Snappy Ubuntu Core――Ubuntu Core的这个嵌入式版本又叫带Snaps的Ubuntu Core，它利用了Snap软件包机制――Canonical将其作为一种通用Linux软件包格式分拆出来，让单一的二进制软件包能够在“任何Linux桌面、服务器、云或设备上”运行。Snaps让Snappy Ubuntu Core能够提供事务回滚、安全更新、云支持和应用程序商店平台。Snappy只需要600MHz处理器和128MB内存，但还需要4GB闪存。它可以在Pi及其他的嵌入式板卡上运行，出现在众多设备上，包括Erle-Copter无人机、戴尔Edge网关、Nextcloud Box和LimeSDR。 相关链接：https://developer.ubuntu.com/en/snappy/ 7.Tizen――Linux基金会托管的这个嵌入式Linux堆栈主要得到了三星的支持，它在移动市场很少引起注意。它广泛用于三星的电视和智能手表中，包括新的Gear S3，它也零星地实施在三星的相机和消费级设备中。Tizen 甚至可以在Raspberry Pi上运行。三星已开始将Tizen与其SmartThings智能家居系统集成起来，以便能够通过三星电视来控制SmartThings。我们还可以预计它会与三星的Artik模块和Artik Cloud加强集成。Artik随带Fedora，但是Tizen 3.0最近连同Ubuntu Core一并移植。 相关链接：https://www.tizen.org/ko?langredirect=1： 8.uClinux――久负盛名的精简版uClinux是唯一可以在MCU上运行的Linux，可以在特定的Cortex-M3、M4和M7等型号上运行。uClinux需要MCU内置存储器控制器，可以使用外部DRAM芯片来满足内存要求。现在uClinux已被并入到主线Linux内核中，得益于Linux中广泛的无线支持。然而，Mbed等更新颖的面向MCU的操作系统在迅速填补无线方面的空白，配置起来更容易。EmCraft是MCU上uClinux的最大支持者之一，提供众多基于Cortex-M的模块。 相关链接：http://www.uclinux.org 9.Yocto Project――Linux基金会的Yocto Project不是一款Linux发行版，而是一个开源协作项目，为开发人员提供构建自定义嵌入式堆栈的模块、工具和方法。由于你可以用极小的开销来定制堆栈，它常常用于物联网。Yocto Project构成了大多数商用嵌入式Linux发行版的基础，也是Ostro Linux和Qt for Device Creation等项目的一部分。Qt正在为Qt 5.8准备一种Qt Lite技术，将为更小巧的物联网目标设备优化Device Creation。 相关链接：https://www.yoctoproject.org 九大非Linux开源物联网操作系统 1.Apache Mynewt――开源、支持无线的Apache Mynewt面向32位MCU，由Runtime开发，由Apache软件基金会托管。模块化的Apache Mynewt拥有无线支持、并发连接的准确可配置性、调试功能和细粒度的电源控制。5月份，Runtime和Arduino Srl宣布，将提供Apache Mynewt，面向Arduino Srl的Primo和STAR Otoo SBC。这款操作系统还支持Arduino LLC板卡，比如Arduino Zero。(最近，Arduino Srl和Arduino LLC达成了诉讼调解，宣布计划在Arduino控股公司和Arduino基金会下重新联手)。 ...

修改了sudoers文件里的一行内容，之后sudo命令就不能用了： ~$ sudo sudo： »> /etc/sudoers：syntax error 在行 21 附近«< sudo： /etc/sudoers 中第 21 行附近有解析错误 sudo： 没有找到有效的 sudoers 资源，退出 sudo： 无法初始化策略插件 ~$。 就是这个样子，然后sudoers文件又是只读的，所以没法改 然后su 禁止root登陆的，除了用recovery模式进入系统去修改外，还有一种方法： 首先sudo用不了了，无法提升gedit权限，起初我想用su - root ，但密码要先启用，还要用到sudo，PASS 于是想到新立得，他不是用sudo来提高权限的，于是找到/usr/bin/synaptic-pkexec是这样一条代码pkexec “/usr/sbin/synaptic” “$@"，于是在主目录新建一个文本，加入这样的代码pkexec “/usr/bin/gedit” “$@"，但虽然要密码，但打不开gedit PASS 这时。我打开/usr/sbin 发现了visudo 于是改为pkexec “/usr/bin/gedit” “$@” 于是就打开了visudo（在终端直接输visudo权限不够的）。 把错误行删掉，再ctrl+O 就写入sudoers了，注意.tmp不要删掉. pkexec是什么命令我不知道，貌似只能为sbin目录的程序加权。

审计开源加密软件TrueCrypt的Open Crypto Audit项目公布了完整的审计结果(PDF)。TrueCrypt是流行的加密软件，但从未进行过安全审计，在NSA大规模监控活动曝光之后安全研究人员发起了对TrueCrypt的完整安全审计。然而就在安全审计过程中，TrueCrypt背后的匿名开发者突然宣布终止项目，警告说使用TrueCrypt不安全。但发起者决定继续审计工作。 根据完整的审计结果，TrueCrypt是一款相对而言精心设计的加密软件，没 有发现故意植入后门的证据，也没有发现导致软件出现漏洞的严重设计缺陷。TrueCrypt终止开发之后有开发者发起了Fork，如CipherShed、veracrypt 。