Win10 – WSL 使用小贴士

此前多年以来我都是信仰级的Linux User,不过后来因为工作硬件支持的原因,级别掉到佛系user,有什么用什么。更因为Win10加入了WSL的功能后,开发环境已经足够使用。

对于WSL我几乎是第一批使用的用户,那时候才2015年。Win10 持续更新到现在(1809),WSL环境下总体已经没什么有影响体验的问题了,作为一般的开发环境绝对够用。这里分享下在较新的WSL下依然需要tune的细节。

终端

Windows下的终端一直都是弱项,这都8102年了,cmd都没有类似bash下.profile、.history之类的几十年以来都有的功能。不过WSL里面有bash,就没cmd.exe什么回事;然而,默认启动的wsl,似乎还是cmd.exe的窗体?

还好有第三方终端。有个比较出名的ConEmu,多年以前都是win下终端的首选替代品了,功能也很多,也支持了WSL。不过我不大喜欢,量级略重,启动慢,我日常使用的是wsltty

wsltty是两个小项目:mintty和wslbridge的捆绑发行版,加起来也是几百k的体积,使用时启动非常快,就像linux桌面下启动xterm。

功能也没花俏,就一个“终端该有的样子”。

工作原理上,wslbridge跑在WSL里面运行了shell,然后把stdin/stdout/stderr用管道传给win下的窗体程序mintty,所以比起在wsl内跑sshd,再用ssh客户端链接的方案要方便快捷很多。

Ubuntu

WSL内的发行版我现在是用Debian的,因为比起Ubuntu,默认安装上要更为“轻量”,更重要的是使用Debian unstable的发行有滚动更新,能跟上很多软件包的最新版本。

Ubuntu的重量级体现在其默认安装了很多“友好的工具”。大家应该不陌生在Ubuntu下敲了错误的命令、不存在命令时候,终端提示不是冷冰冰的command not found,而是友好地提示:这个命令没有安装呢,请安装xxx软件包,命令如下;又或者在xxx、yyy、zzz软件包有类似的命令……

但是在WSL Ubuntu下,这个体验就不大友好了,敲错命令了,终端会卡死几秒钟……然后才出现上述的提示。终究原因,还是因为WSL的磁盘IO性能比较差,而ubuntu提供这个提示功能的是有专门的程序在数据库里面搜索一通才完成的,而且这个程序是还Python写的。一个错误命令扯起一套环境读入、读库搜库,即使是SSD硬盘,都能卡上几秒……我宁愿要冷冰冰的command not found.

删掉Ubuntu的预装包就好了:

sudo apt remove python3-commandnotfound command-not-found command-not-found-data

而Debian默认是不会安装这类玩意的,轻量级的跑起来很快。甚至太轻量了,连查文档的man命令都是没有的:

sudo apt install man-db

服务

如今发行版都使用了systemd做服务管理,然而WSL下systemd是不可能跑起来的。当然现在社区都正在为支持WSL努力,不过在可用之前,似乎没什么好办法。

比如安装了mysql,想要启动起来,只能手工地在screen里开个终端运行mysqld。WSL目前对后台确实缺乏友好。

一个方法是把服务管理系统改回SysV之类,但总感觉是伤筋动骨了,目前我没什么好的办法。

微软的商店里上线了个叫做WLinux的发行版,也是基于Debian的,售价20刀。据说是专门给WSL环境优化的系统环境,完全没有systemd,理论上应该解决这个头痛的问题了。当然作为开源产品,付钱购买不是必须的。不过我还没实践过,可能需要用到这个可以安装任何发行版到WSLLxRunOffline

VSCode开发集成

WSL存在的价值就是开发环境,所以跟开发工具是离不开的。开箱可用的Visual Studio Code编辑器也成为近来最爱,不过在WSL的支持上,开发者们还在努力。

VSCode默认是支持git的,但是他用的是windows环境的git,WSL里面也有git,虽然都安装的话两套git也能完成代码管理,但是总有点突兀(主要是刷新状态上)。

有个叫wslgit的项目,直接把WSL里面的git“翻译”成原生git,只需要WSL里面配置一下就可以了。

{
    "git.path": "C:\\Users\\xxx\\bin\\wslgit.exe"
}

VSCode里面也集成了终端功能,运行代码时候不用跟终端程序切换的,按ctrl+`就可以,然而默认打开的是cmd.exe,顺便改一下。

{
    "git.path": "C:\\Users\\penti\\bin\\wslgit.exe",
    "terminal.integrated.shell.windows":
         "C:\\Windows\\System32\\bash.exe"
}

其他还有Python/Node这类环境都可以在VSC里面直接调用WSL里面的代码的,其实主要就是处理了Win下D:\Path到WSL内/mnt/d/Path这类的映射问题。更多WSL的增强辅助项目,可查看WSL-Awesome内列出的一堆项目。

 

OPENSSL/Tomcat Keytool命令小抄

OPENSSL自签证书一行流

#CN=Common Name,web服务器中所用的域名
#O=Organization,签名机构名称
#C=Country,国家地区
#days 3650,证书10年有效

openssl req -subj '/CN=domain.com/O=My Company Name LTD./C=CN' -new -newkey rsa:2048 -days 3650 -nodes -x509 -keyout server.key -out server.crt

OPENSSL查看信息

#PEM证书信息
openssl x509 -in server.crt -text -noout

#P12证书信息
openssl pkcs12 -info -in server.p12

OPENSSL对证书校验

#输出结果应完全一致
openssl x509 -noout -modulus -in server.crt | openssl md5
openssl rsa -noout -modulus -in server.key | openssl md5
openssl req -noout -modulus -in server.csr | openssl md5

Tomcat用的keystore格式跟pem转换

PEM 转 Keystore

#注意较新版本的tomcat要求直接用p12格式,省略转keystore一步。

#先转换为证密二合一的p12格式文件,注意密码要跟下一步一致,p12的name将成为ks的alias
openssl pkcs12 -export -inkey server.key -in server.crt -name root -out server.p12

#导入到keystore
keytool -importkeystore -srckeystore server.p12 -srcstoretype pkcs12 -destkeystore server.ks
TOMCAT 配置

修改tomcat/conf/server.xml

<!-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 -->
<Connector
           protocol="org.apache.coyote.http11.Http11NioProtocol"
           port="8443" maxThreads="200"
           scheme="https" secure="true" SSLEnabled="true"
           keystoreFile="path/to/server.ks" keystorePass="password"
           clientAuth="false" sslProtocol="TLS"/>

 


Keystore 转 PEM

#先查看keystore内的srcalias对应需要的证书,
keytool -list -v -keystore server.ks

#比如上命令看到 Alias name: root
#选择特定的证书(srcalias)转换成pkcs12格式
keytool -importkeystore -srckeystore server.ks -destkeystore serverks.p12 -srcalias root -srcstoretype jks -deststoretype pkcs12

#从p12提取出证书
openssl pkcs12 -in serverks.p12 -clcerts -nokeys -out serverks.crt

#从p12提取出私钥(必须设置私钥密码)
openssl pkcs12 -in serverks.p12 -nocerts -out serverks.key

#去除私钥文件的密码
openssl rsa -in serverks.key -out serverks_plain.key
#注意从p12转出的文件一般都带有Bag Attributes等一些信息行,可能在特定程序引起不兼容,注意需要手工编辑清理

标签: , , , , ,

本博客的网络结构

话说这个博客现在的网络结构是这样的。

 

其实这个博客除了写东西记录,另外就是我尝试部署技术的一个练习场。虽然之前内容上已经长草了多年,不过后台技术其实一直有变化的呢。

最近把博客后台结构折腾成上图那样了。内容服务器放墙内腾讯云,因为:

  • 廉价主机:此前腾讯云推广活动,300元撸了6年的主机,比起在墙外各处小机间不断迁移,固定到一个主机似乎更好选择。
  • 性价比高:腾讯云这个主机配置虽然不高,但是比起一众同价位的墙外VPS还是好不少,用来跑docker相当不错。

然而缺点显然也有:

  • 未备案站点不能在墙内服务,HTTP流量会被多重检查劫持。
  • 因为选了最大服务时长,腾讯云的带宽只开到最低的1M。

这样的配置一般来看就很鸡肋了,只能刷一个存在。不过正在国内各种云服务刷活动,费率都不低,人家Cloudflare的CDN可是全免费的!然而Cloudflare要做到缓存加速、内容优化,回源流量都需要走明文的HTTP,而墙内主机是不行的。

于是给几台爬墙用的海外VPS配置上了Wireguard做前端服务。Wireguard的实现非常优雅,在Linux上都不需要服务进程(倒是要内核模块)。腾讯云主机虽然有公网IP,但是他的网络结构是NAT进去的,之前想过使用IPv6 teredo等技术播一个V6 IP进去实现同样的功能,但是考虑到隧道只负责封装,不负责加密,可能还是会撞到国内运营商的重重流量墙,于是还是Wireguard方案了。

后端wordpress自然是跑PHP的,从当初的php-fpm+nginx,后来尝试过uwsgi-php + nginx,然后用caddy替换了nginx,HTTPS的证书问题很舒服。后面用docker就没拘泥这些细节了,直接部署了docker全家桶,配合cloudflare很是省心了。

以上。

在路由器iptables中匹配IPv6动态地址

家用宽带目前很多都部署了IPv6,家用路由器目前Padavan/Openwrt等系统都能较好地支持了IPv6。不过要充分利用IPv6链接设备,有些坑。

动态变化的IPv6地址

首先是IPv6地址,不同设备(操作系统)获取的IPv6地址有区别,较为通用的是【无状态EUI-64地址】,操作系统通过网卡的mac地址生成一个64位固定后缀,以及路由器下发的64位前缀,合成一个固定的IPv6地址。作为服务端,【无状态EUI-64地址】是较为适合的,Linux发行版很多组件(systemd-netword,dhcpcd等)默认都采用EUI-64地址。

另外还有通过DHCPv6下发的地址,这个就不大可控,跟DHCPv6服务器和终端客户有关,特点是生成的后缀较短。

此外,家用宽带ISP提供的IPv6前缀是不定期变化的。可见要访问家庭宽带内网的设备,光是地址就存在了蛮多的变化因素。

IPv6的【隐私扩展地址】

终端设备,比如手机、工作站版本Windows等设备,则使用【隐私扩展】的方式随机生成64位后缀,这样终端的地址每次链接时候都会随机改变,访问外部资源时候可避免被追踪。

如果要连接Windows远程桌面,安装的是工作站版本,系统默认已经启用【隐私扩展】,主机地址就是随机变化的,想要连接3389就很麻烦了,不过这个特性可以关闭。服务器版本的Windows默认不启用隐私扩展,而家庭版Windows不支持远程桌面[doge]。

管理员权限的CMD下执行

netsh interface ipv6 set global randomizeidentifiers=disabled store=active
netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent
netsh interface ipv6 set privacy state=disabled store=active
netsh interface ipv6 set privacy state=disabled store=persistent

IPv6防火墙ip6tables

要从外网通过IPv6访问家里路由器下的设备,最关键一点是路由器上的防火墙要允许这样的转发。

Padavan/Openwrt都是基于Linux – ip6tables的防火墙。默认情况下,ip6tables只允许了v6子网内的设备被ping,只允许特定类型的ICMPv6报文通过,其他通信报文一律丢弃了。所以虽然IPv6下每个设备都有公网地址,但是还不至于不安全到每个设备都可让人随便连。

动态匹配EUI-64后缀

考虑到前缀变化因素,要访问特定设备,就是让IPTABLES匹配特定设备的EUI-64后缀放通这个地址:

ip6tables -I FORWARD -d ::abcd:1234:5678:90ef/::ffff:ffff:ffff:ffff -j ACCEPT

可见iptables对v6地址的匹配掩码可以非常灵活,不像v4下只按前缀适配。坑的就是这个特征是没有文档的,目前文档中写的mask解释还是适配IPv4的内容,有人专门发邮件去netfilter列表问了才知道。IPv6地址中,双冒号::的写法代表是前/后均为0位,双冒号只能出现一次。

Openwrt中配置转发规则

Padavan中设置转发规则

其实padavan中的防火墙功能并没有配置地址匹配转发规则的功能界面,只能在自定义脚本中写原始的iptables命令。截图中使用的padavan是增加了QOS组件的老毛子版本。

padavan-ip6tables

以上。

标签: , , ,

Error: OID not increasing

调SNMP设备时候遇到了某厂家的奇葩输出,用命令行下的snmpwalk:

$ snmpwalk x.x.x.x -c "public" -v 2c 1.3.6.1.4.1.5105.80.6.2.1.47
SNMPv2-SMI::enterprises.5105.80.6.2.1.47.3589396343 = INTEGER: 8
SNMPv2-SMI::enterprises.5105.80.6.2.1.47.3589497833 = INTEGER: 8
SNMPv2-SMI::enterprises.5105.80.6.2.1.47.3589501999 = INTEGER: 8
SNMPv2-SMI::enterprises.5105.80.6.2.1.47.3589331126 = INTEGER: 8
Error: OID not increasing: SNMPv2-SMI::enterprises.5105.80.6.2.1.47.3589501999
 >= SNMPv2-SMI::enterprises.5105.80.6.2.1.47.3589331126

查了一下,常规SNMP OID是应该在GETNEXT请求下顺序输出的,每个值是之前一个的+1,为了避免出现数值循环,snmpwalk默认检查数字是否递增;

上面例子中,显然不是如此,这个snmp agent并不使用递增识别码。

这还是好解决的,snmpwalk有个-Cc参数:

-Cc    Do not check whether the returned OIDs are increasing. Some agents (LaserJets are an example) return OIDs out of order, but can complete the walk anyway. Other agents return OIDs that are out of order and can cause snmpwalk to loop indefinitely. By default, snmpwalk tries to detect this behavior and warns you when it hits an agent acting illegally. Use -Cc to turn off this check.

不过在PHP中坑就大了,首先最普通的snmp2_walk函数完全没有这些特性支持,wait,还有个snmp2_​real_​walk?难道之前那个是fake的?搞了半天原来real_walk返回的数组键值是全OID数值,没real那个的键值则仅仅是识别码。这命名还真是够PHP Style啊!

回到原点,把php-snmp模块的函数逐个都点过了,就没有关于OID increase的设置,看了stackoverflow上的某回答,自己实现了用snmp2_​getnext来遍历,好我也实现一个,结果没几下就被设备封IP了,原来snmpwalk用的是snmpbulkget 的请求,自己的getnext,则会被设备认为请求过多封了!

还是Google帮我找到了PHP下oid_increasing_check关键字,原来藏在SNMP class(5.4+),所以好好一个snmp2_walk函数就变成这样了:

    $snmp = new SNMP(SNMP::VERSION_2C, HOST, COMMUNITY);
    $snmp->oid_increasing_check = FALSE;
    $snmp->quick_print = TRUE;
    $snmp->valueretrieval = SNMP_VALUE_LIBRARY;
    $snmp->oid_output_format = SNMP_OID_OUTPUT_NUMERIC;
    $data = $snmp->walk($cmd, TRUE);

对了,walk()的那个TRUE参数,不TRUE就是以前的real_walk,TRUE了就是fake walk~~~~

RHEL/CentOS系系统的社区维护资源

Linux各个发行版的技术上虽然有差别,但一般不至于有很大鸿沟,实际上更复杂的其实是各个发行版的维护社区的工作方式和交流文化的差别,如果不了解去利用相应的社区资源,就会觉得维护这个发行版异常吃力,从而产生“XXX发行版不好用”的错觉。

因为工作原因最近我接触维护的系统多为CentOS,之前对CentOS的印象都是“又古老又难维护”,不过几个月的积累下来,发现RH系的社区资源并不比Debian/Ubuntu的少,只不过是国内的维护文化和他们的相去甚远,几乎无法兼容,以致很多人都缺乏了解,所以觉得需要撰文列举下这些资源。

以下很多第三方仓库都在Centos Wiki有介绍.

仓库列表

维护仓库的通常是一群维护者,有个论坛、邮件列表等,有什么需求,或者有什么BUG,可以直接去和维护者沟通。下面都是列出了主页的一些仓库,留意主页的链接可以找到交流方法了。

官方仓库

默认安装的CentOS的yum,/etc/yum.repos.d/CentOS-Base.repo是基本的源仓库;里面各个仓库名下mirrorlist是官方列表,yum的fastestmirror插件会从其中选择一个来更新;而如果注释了mirrorlist写baseurl,就只从这一个仓库更新了。可以参考163源的CentOS5-Base-163.repo

这些是CentOS/RedHat官方维护的,就是那些“老旧过时”而且“几乎什么都没”,只要不是出现严重漏洞都不会更新那些。

FedoraProject for EPEL

Fedora和Redhat的关系就不详述了,就是FedoraProject里有个“EPEL Special Interest Group”,为EPEL系维护的一个社区仓库,基本上加上这个仓库后就能丰富了整个EPEL生态了,在Debian系里面“理所当然源里就有”的那些软件就会有了,比如openvpn,htop,ipcalc,git … 虽然版本不会很新,但起码能用了。

用法:安装这些链接页面里面的.rpm。

RPM Fusion

这个仓库说提供的是FedoraProject跟RedHat都不想提供的程序,提供的分类就知道怎么回事了,基本都是Sound and VideoGames and EntertainmentHardware Support等等。首先是Linux平台下多媒体支持方面的版权问题非常复杂,ffmpeg/x264等通常都有一些争议行的授权,当然也有nvidia/ati等硬件的闭源驱动、Oracle的闭源版Virtualbox等,把他们独立出来避免争端。

另外这个仓库基本提供的更新都是for Fedora,EPEL5/6的几乎没更新。可以说RPMFusion是个“桌面仓库”,而且国内163源提供了RPMFusion的镜像

用法: 见Configuration

RepoForge

原叫RPMForge,和CentOS社区较紧密,提供的包也比较海量的,很难评价分什么方向,CentOS Wiki专门有页面提供安装指导,因为包的数量太海量了很难和“FedoraProject for EPEL”做比较。

用法: 见Usage

Remi

这个仓库依赖EPEL。

提供了php54 / mysql55 / firefox 等等的更新,选的软件比较符合Web开发者工作的需要,当然服务器最好也是维护相同版本。这个仓库使用了github来管理软件包的spec,可以直接看他提供了什么包。更新非常紧贴各个软件的官方发布。

用法: 安装主页相应的remi-release-XX.rpm

KBS-Extras

CentOS本来的维护团队,有趣的一点是这仓库基本全在-testing里面提供软件包。

FedoraHosted – SoftwareCollections

这是重点推荐的。这不是一个仓库,是很多个。里面的软件包和上述那些仓库不大一样,都是在/opt下建立一套专用的目录,避免在/usr里面打架的软件包;这里提供了php/python/ruby/perl/mysql/postgre/apache等常用“服务器生态”。

用法:各个Collection的repo链接。

FedoraHosted

上述的只是FedoraHosted内一个子仓库,FedoraHosted是类似Ubuntu的PPA社区的环境,维护者可以通过建立自己的帐号然后建立一些自选软件的仓库。里面应该还有很多有用的东西待发掘。

Fedora People Repositories

一样是类似Ubuntu的PPA,不过这里就多数偏向Fedora的更新,也有些有EPEL6。

Pramberger, pp

这个仓库主要提供EPEL 3/4/5等旧版本的一些包的更新,有php,python的第三方模块、qt、squid等的更新,大概还是偏向更新服务器环境的吧。

用法:保存http://devel.pramberger.at/getrepo?release=<version>/etc/yum.repos.d,注意替换release参数(3|4|5)。

ELRepo

偏内核的新硬件支持模块。

IUS Community Repo

提供PHP, Python, MySQL更新,不过感觉更新不够Remi紧密。

PS维护技巧

yum的仓库选择

/etc/yum.repos.d/下的文件记录着各个仓库的信息,上述很多仓库在安装之后会在这里生成一个.repo,但里面的仓库不一定被启用了,里面可能写了enabled=0

一般来说,为了避免系统升级时候和第三方的包出现冲突,第三方的仓库都应该enabled=0,在需要使用、查找其中软件时候,使用yum的参数:

yum --enablerepo=remi install firefox-langpack-fr

下载SRPM

一定需要定制编译特定软件时候,这些仓库都提供SRPM仓库的,但是默认可能没开启。(yumdownloader需要安装yum-utils

yumdownloader --enablerepo=epel-source --source php

Yum/Rpm常用命令

Rpm/dpkg、yum/apt-get对照

http://www.pixelbeat.org/docs/packaging.html

标签: , ,

CASIO卡西欧PX130电钢琴拆机略解

最近入手了一台二手电钢琴CASIO PX130。去年就买过一台二手电子琴但是半年里面已经被我弹到断键两次,就想这种存在机械活动部件的电器的二手还是容易出问题,但是始终抵不住价格,还是入了二手的电钢。

PX130是这两年才上市的琴,理论上应该不至于磨损严重,然后了解过电钢的琴键结构比电子琴复杂,有良好的泄力传动,似乎不会有CASIO CTK系列那种会疲劳断裂的软塑料键的坑爹设计,就去拼下RP。

PX130电钢琴

扛了回家才一个月,果然就有问题了,不过不是琴键,有一边喇叭会沙沙的声音,后来就几乎没声音了,接耳机也一样,经验判断是功放部分有问题,后来发现蹂躏一下音量旋钮会改善,基本确定是这里了,但是这近20KG的琴要扛去维修,可是N个不愿意,就拖着,这天终于忍不住,自己拆机。

上网查了一圈没找到任何拆机资料(甚至一张完整的外壳底部图都好难找),估计会拆琴的多数是店里的师傅了,只好自己观察。

拆机流程

1.侧边面板

底部有好几十个螺丝,但不需要都拧的,先开左右侧板。拧开3个螺丝后从前面稍微用力就可以拆开一层壳。左边的壳是连着电源和耳机接口线路,最好别让其悬空。

PX130拆开的侧边盖

拆开后可以看到内壳,还有5个螺丝。两边都分别松下,别忙着拆这个挡板,把琴身翻过来。

2.底部螺丝

上面板主要是由底部两排螺丝固定。

如图提示,拆底部上排螺丝,然后开中间一排小盖子,松开里面的螺丝。

PX130底部螺丝拆解

3.上面板

这时候琴身的上盖已经可以完全打开了,小心把琴身翻到正面,往后翻开上盖,小心几根排线。

可以看到里面的主要电路模块,电路最精密的一块逻辑板,音源、MIDI功能都是上面的CPU处理,原件粗重的一块是电源和功放,和一般的音响区别不大。

PX130翻开面盖的电路

另外音量电位器是独立了一块小电路板,估计也是易损件,独立出来方便维修。

我的琴明显电位器是维修过,但是手法非常不专业,把电路板原来的线路都弄坏了,最后用几根绝缘铜丝链接起电位器,非常粗糙,喇叭杂音的原因应该就是其中有些绝缘层破损,有短路了。我看焊的还算牢固,就不重新处理了,用透明胶纸把几根重叠的铜丝做了布线分层,插上电源测试没问题了,果断装回去,收工。

Update:

电位器因为使用损耗,装回去不久后依然有问题,决定拆出来拿去电子市场找个换上。

PX130的音量调节-方形5引脚A103双联电位器

音量电位器是这个方形5引脚A103双联电位器,这里顺便一提电位器型号意义:

  • A/B/C: 阻值递增规律,A是阻值对数递增,B是线性递增,C是指数递增;
  • 103:即10 x 10^3,也即10K欧。

A型电位器用在功放前端,因为功放是按倍数放大信号电流,对数调整输入电流才能获得比较平滑的音量调节效果;而B型电位器用在功放后端,可以直接线性调整输出的电流。

逛了一圈天河的赛格完全没有各种电位器,然后去中山六路的音响配件市场,几经艰难才找到个外形类似的B103,换上后只是调节音量时候效果很不“线性”,但起码不影响使用了。

其他

查了网上其他需要拆机修理的问题,有些如塌键,重锤臂异位,更换琴键等,拆开上面板也基本可以维修了。底部的其他几排螺丝不过是固定琴键组件和底盖的,一般无需拆开。

标签: , , ,

双线Ubuntu服务器来源路由策略全自动配置脚本

国内IDC常见的所说的双线,就是给了两个不同ISP的接入IP,有些服务周到些,在路由器处追踪处理来源IP会话,但一旦没有,或者是自己拉的两个ISP直接到服务器,情况就麻烦了。

服务器对任意一个IP发来请求,那返回的包应原路返回,链接才能建立;但默认情况下,系统只有一个路由表,只有一个默认路由,来源IP只能从默认路由的gateway出去,那这样另外一个IP就没法用了。

这个情况需要配置多路由表的来源略路由(source policy routing),让不同IP的返回包查找不同的路由表,再根据其中的默认路由返回数据包。

Linux Advanced Routing & Traffic Control HOWTO详述了原理和配置步骤,google一下也会找到很多人家写好的配置脚本,不过总觉得用起来不方便。首先需要在脚本上定义各个网卡的IP/网关/网络等地址,这些数据和系统配置完全重复,一旦修改又得两边同步;然后还需手动修改/etc/iproute2/rt_tables,步骤复杂;其次Debian/Ubuntu的启动脚本比较复杂,这个情况的脚本很难在找个开机的合适时候启动。

经过考虑,决定使用/etc/network/if-up.d下的hook,这里的脚本可以从环境变量获得每一个启动的网卡的各个参数,使用sed等工具处理一下,完全可以实现全自动配置。

脚本放在github:

https://github.com/pentie/ptcoding/blob/master/multi-ip-route

脚本使用了ifquery,ubuntu里面是和ifup/ifdown同一个包的工具,理论上debian也会有。所以只需要配置好/etc/network.d/interfaces,扔好这个脚本,重启网络,双线策略就完美解决了。经证实,在eth0:1 eth0:2那样绑定的单网卡多IP情况使用也完全正常。

标签: , , ,
Top