分类目录归档:linux

openvz virtualization技术的 OVZ VPS使用nmap

之前在OVZ的nmap上开nmap结果都是有个 就是提示主机没有一个up的

例如以下

[root@ramnode ~]# nmap qq.com
Starting Nmap 5.51 ( http://nmap.org ) at 2017-03-07 01:30 EST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 0.47 seconds

google了一下 要加个–unprivileged的参数

[root@ramnode ~]# nmap -Pn qq.com --unprivileged
Starting Nmap 5.51 ( http://nmap.org ) at 2017-03-07 01:36 EST
Nmap scan report for qq.com (125.39.240.113)
Host is up (0.27s latency).
Other addresses for qq.com (not scanned): 61.135.157.156
rDNS record for 125.39.240.113: no-data
Not shown: 997 filtered ports
PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  https
843/tcp open  unknown
Nmap done: 1 IP address (1 host up) scanned in 15.81 seconds

这个问题解决了 但是不知道python-nmap调用这个怎么设置,还要研究下

linux上临时添加路由和永久添加路由

添加临时路由

[root@fuck ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.18.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.11.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1003   0        0 eth1
0.0.0.0         192.168.18.2    0.0.0.0         UG    0      0        0 eth0
[root@fuck ~]# route add -host 8.8.8.8 gw 192.168.11.1
[root@fuck ~]# route add -host 114.114.114.114 gw 192.168.18.2
[root@fuck ~]# route add -net 172.16.0.0/16 gw 192.168.18.2
[root@fuck ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
114.114.114.114 192.168.18.2    255.255.255.255 UGH   0      0        0 eth0
8.8.8.8         192.168.11.1    255.255.255.255 UGH   0      0        0 eth1
192.168.18.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.11.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
172.16.0.0      192.168.18.2    255.255.0.0     UG    0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1003   0        0 eth1
0.0.0.0         192.168.18.2    0.0.0.0         UG    0      0        0 eth0

删除临时路由

[root@fuck ~]# route del -host 8.8.8.8
[root@fuck ~]# route del -host 114.114.114.114
[root@fuck ~]# route del -net 172.16.0.0/16
[root@fuck ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.18.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.11.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1003   0        0 eth1
0.0.0.0         192.168.18.2    0.0.0.0         UG    0      0        0 eth0

如果需求永久添加路由,就需要增加配置文件,最后的eth0代表对应网卡

vim /etc/sysconfig/network-scripts/route-eth0

添加如下信息

114.114.114.114/32 via 192.168.1.1
8.8.8.8/32 via 192.168.1.1

保存 重启network

 

redhat 7 eth 网卡命名规则

其实大家都知道传统的命名方式有问题,这个问题不仅仅是在linux上有,在VMware这种上也有,之前经常看着搞系统的人给ESXI主机加网卡,加完了就各种不同了,原有都是VINC0之类,加完网卡后就各种混乱了,导致原有的规划和实际不符合,虽然通过重组或重新排序可以解决,但是在实际生产环境是不方便操作的。

redhat也意识到这个问题,在redhat 7里面就重新设定了命令规则,命令规则和网卡插槽位置相关这种是比较科学比较贴近人类的。在过去运维中,系统的网卡还要跟实际网卡插槽或者板载网卡需要维护一个对应关系表,如果设备硬件完全一致还可以记下来,如果设备硬件有太多型号,每次都要去查表才知道系统里面的eth0对应外面那个接口。

这个功能在路由器上其实一直都是实现的很好,是几槽几卡的什么类型接口,配置就可以看出来,例如interface TenG 5/1/1就知道是五槽第一块卡的第一个接口,万兆接口。

以下来自红帽官网:

     Red Hat Enterprise Linux 7 provides methods for consistent and predictable network device naming for network interfaces. These features change the name of network interfaces on a system in order to make locating and differentiating the interfaces easier.

    Traditionally, network interfaces in Linux are enumerated as eth[0123…], but these names do not necessarily correspond to actual labels on the chassis. Modern server platforms with multiple network adapters can encounter non-deterministic and counter-intuitive naming of these interfaces. This affects both network adapters embedded on the motherboard (Lan-on-Motherboard, or LOM) and add-in (single and multiport) adapters.

    In Red Hat Enterprise Linux 7, udev supports a number of different naming schemes. The default is to assign fixed names based on firmware, topology, and location information. This has the advantage that the names are fully automatic, fully predictable, that they stay fixed even if hardware is added or removed (no re-enumeration takes place), and that broken hardware can be replaced seamlessly. The disadvantage is that they are sometimes harder to read than the eth0 or wlan0 names traditionally used. For example: enp5s0.

以下是新的命名规则

By default, systemd will name interfaces using the following policy to apply the supported naming schemes:

  • Scheme 1: Names incorporating Firmware or BIOS provided index numbers for on-board devices (example: eno1), are applied if that information from the firmware or BIOS is applicable and available, else falling back to scheme 2.

  • Scheme 2: Names incorporating Firmware or BIOS provided PCI Express hotplug slot index numbers (example: ens1) are applied if that information from the firmware or BIOS is applicable and available, else falling back to scheme 3.

  • Scheme 3: Names incorporating physical location of the connector of the hardware (example: enp2s0), are applied if applicable, else falling directly back to scheme 5 in all other cases.

  • Scheme 4: Names incorporating interface's MAC address (example: enx78e7d1ea46da), is not used by default, but is available if the user chooses.

  • Scheme 5: The traditional unpredictable kernel naming scheme, is used if all other methods fail (example: eth0).

This policy, the procedure outlined above, is the default. If the system has biosdevname enabled, it will be used. Note that enabling biosdevname requires passing biosdevname=1 as a command-line parameter except in the case of a Dell system, where biosdevname will be used by default as long as it is installed. If the user has added udev rules which change the name of the kernel devices, those rules will take precedence.

Centos 6升级kernel至4.9 体验google黑科技TCP BBR算法

虽然不怎么认同BBR这个算法,但是在出口带宽大,到大陆连接质量差的美国机房开启这个玩意就相当于是量身定做的一个协议了

之前在hostus.us买了个kvm的,CN2半程直连,回程走chinanet直连,去程走CN2,质量非常好,上传可以跑满,但是下行就不行了,最开始开启了锐速,后来觉得这个软件不安全,转移至BBR这种开源技术。

需要升级4.9的kernel才行,升级不用想那么多,对一般的应用不会有什么影响,我这边升级完成后ss和anyconnect都正常。

第一步导入ELRepo GPG key

rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org

安装 ELRepo,我这里是CentOS 6

rpm -Uvh http://www.elrepo.org/elrepo-release-6-6.el6.elrepo.noarch.rpm

如果是7就安装这个

rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm

直接升级

yum --enablerepo=elrepo-kernel install kernel-ml

修改一下grub配置,默认没有把4.9设置为默认启动  吧default改为4.9的

vim /boot/grub/grub.conf

重启之后可以看到内核已经修改为4.9

[root@cn ~]# uname -r
4.9.9-1.el6.elrepo.x86_64

开启TCP BBR

[root@cn ~]# echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
[root@cn ~]#  echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
[root@cn ~]#  sysctl -p
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

确认是否正常

[root@cn ~]# sysctl net.ipv4.tcp_available_congestion_control
net.ipv4.tcp_available_congestion_control = bbr cubic reno
[root@cn ~]# sysctl -n net.ipv4.tcp_congestion_control
bbr
[root@cn ~]# lsmod | grep bbr
tcp_bbr                16384  6