荷蘭情報機關準備對 IP 網路進行大規模監聽

Dutch secret service prepares for wiretapping of IP networks on a large scale!

News:
http://www.volkskrant.nl/vk/nl/2686/Binnenland/article/detail/3541591/2013/11/09/Nederland-bestelt-een-nog-verboden-spionagesysteem.dhtml

In Summary:

The Dutch AIVD (dutch NSA counterpart) has ordered equipment to wiretap IP links for €17 million. Doing "undirected" surveillance is currently only legal in the Netherlands for signals that are not carried over cables (eg broadcast signals). With this move, the agency is anticipating a law change, which will allow it to wiretap cables to do undirected (mass) surveillance.

<人腦翻譯>
荷蘭情報機關已經採購類似美國情報局的設備, 以便對於網路與電話進行監聽. 雖然目前該行為仍然為法令所禁止, 但是情報主管認為該法令已經過時.
</人腦翻譯>

So... finally, it comes...

RAID-1 (mirror) on FreeNAS boot disk

Although FreeNAS will mount boot disk in read-only but there could still be a chance that boot disk goes wrong. Traditional way to fix a broken boot disk is reinstall FreeNAS on a new boot disk and import backup config. However, this method may introduces longer downtime, and in worst case the backup config may not even up-to-date.

Using RAID-1 (mirror) on boot disk is a good choice to reduce such kind of impact, and usually can be done through hardware raid card. if there is no hardware raid card, software RAID is also a good choice. However, during or after installation, there is no option in the menu to create software RAID for boot disk.

Luckily, FreeNAS is based on FreeBSD that provides super easy way to setup a software RAID manually. Here comes steps,

Assume boot disk is SATA "/dev/ada0" and mirror disk is SATA "/dev/ada1". From the console, select 9 to launch a shell, then enter following commands.

# sysctl kern.geom.debugflags=16
# gmirror label -v -b round-robin gm0 /dev/ada0
# gmirror insert gm0 /dev/ada1

System will automatically rebuild the newly added disk, /dev/ada1, and the disk status will show DEGRADED. For example,

# gmirror status
      Name    Status  Components
mirror/gm0  DEGRADED  ada0
                      ada1 (64%)

After automatic rebuild, disk status will become COMPLETE. For example,

# gmirror status
      Name    Status  Components
mirror/gm0  COMPLETE  ada0 (ACTIVE)
                      ada1 (ACTIVE)

In case the boot disk (assume "/dev/ada0" is broken) and needs to be replaced, here comes procedures,

# gmirror forget gm0 /dev/ada0
[unplug /dev/ada0, and plug a new disk]
# gmirror insert gm0 /dev/ada0

The system will again automatically rebuild /dev/ada0. During the rebuilding, system can keep running without problem.

*Note*
FreeNAS loads geom_gmirror module by default, and uses geom_label in /etc/fstab rather than physical disk name. Hence there is no need to modify /boot/loader.conf and /etc/fstab.

Juniper/Cisco Switch L2 Spanning-tree inter-op (config on Juniper side)

RSTP is standard and supported on every other vendors switch platforms and mostly be the default spanning-tree protocol.

However, Cisco from certain OS version can no longer config RSTP. Instead, its proprietary Rapid PVST became default and no way to go back to RSTP. It shows how evil Cisco is.

Cisco also send VLAN-1 traffic on the trunking (802.1q) interface to be untagged by default even there is no explicit native VLAN id been configured on the interface. It is again another stupid Cisco design.

Following is a configuration sample on Juniper EX switch to make it inter-op with Cisco switch. RSTP on Juniper side and rspid-PVST on Cisco side.

interfaces {
    ge-0/0/15 {
        description "## Cisco-SW g0/23 ##";
        ether-options {
            speed {
                1g;
            }
            802.3ad ae3;
        }
    }
    ge-1/0/15 {
        description "## Cisco-SW g0/24 ##";
        ether-options {
            speed {
                1g;
            }
            802.3ad ae3;
        }
    }
    ae3 {
        aggregated-ether-options {
            no-flow-control;
            minimum-links 1;
            link-speed 1g;
            lacp {
                active;
            }
        }
        unit 0 {
            family ethernet-switching {
                port-mode trunk;
                vlan {
                    members [ VLAN-10 VLAN-20 ];
                }
                native-vlan-id 1;
            }
        }
    }
protocols {
    rstp;
}
vlans {
    VLAN-1 {
        description "## Native VLAN for Spanning-Tree ##";
        vlan-id 1;
    }
    VLAN-10 {
        vlan-id 10;
        l3-interface vlan.10;
    }
    VLAN-20 {
        vlan-id 20;
        l3-interface vlan.20;
    }
}

All I can say is we should dump Cisco and go for other vendors.

What is the difference between DHCPv6 and DHCPv4?

這是很久以前寫的東西, 印象中去年還是什麼時候有拿出來過一次, 剛剛在硬碟裡面找東西無意間看到, 稍微增補並翻譯成中文貼出來異地備援一下.


What is the difference between DHCP6 and DHCP4? (IPv6 的 DHCP6 跟 IPv4 的 DHCP4 有哪些不同?)

以下列出幾項值得注意的差異:

1. 這兩個是完全不同的協定 (protocol):

• DHCP4 是基於 BOOTP 這個古老的協定增修而來的

• DHCP6 是一個完全重新開發的協定, 他針對以往 DHCPv4 裡面一些效率比較差的行為做了加強.

2. Multicast:

• 與許多 IPv6 的協定一樣, DHCP6 使用 multicast 溝通以增進效率, 而不是 DHCPv4 所用的 broadcast.

3. Link-local 位址:

• 因為是使用 multicast, 所以就必須先有 IP 位置才能發送請求封包, 而不是如同 DHCPv4 一樣用 MAC 位址就可以. 所以 DHCP6 的 clients 就使用 IPv6 獨有的 link-local 位址來發送 DHCP6 的請求封包.

4. 單次訊息交換即可完成:

• Client 可以把所有介面的需求經由單一次的 DHCP6 請求發送給 DHCP6 Server. 而 Server 就可以一次把所有的介面需要的資料 (例如 IP 位址) 提供給 Client. 這樣做比多次請求來得有效率.

5. Stateful 或 Stateless:

• DHCP6 可以使用 Stateful 或是 Stateless 模式運作.

• 所謂的 Stateful 是 Client 經由 DHCP6 Server 取得 IPv6 位址以及其他資料, 這個模式幾乎等同於 DHCP4 的運作方式.

• Stateless 是 Client 使用其他方法 (例如 SLAAC) 取得 IPv6 位址, 而 DHCP6 只用來提供其他的資訊, 例如 DNS Server 的資料.

6. DHCP6 無法提供預設閘道 (default router 或 default gateway) 資訊

• DHCP6 其中一個非常為人詬病的問題就是 DHCPv6 無法提供預設閘道的資訊給 Client, 而必須要使用 RA (router advertisement).

NOTE:

• 因為 DHCP6 跟 RA 這種搭配, 以及 RA 設計上一些過度理想化的假設前提, 使得網路設計, 管理與除錯的時候要增加額外的步驟. 企業在導入 IPv6 時候必須要對用戶端網路相關的標準作業文件 (SOP) 進行大規模修訂, 而造成高昂的隱性成本.

• DHCP6 這個功能上的缺陷已經被檢討很久 (在 DHCPv6 剛出來就許多人提出質疑, 我也跑去放箭過 ^_^), 但正反兩派僵持不下使得修正仍在草案階段, 第一版修正在 2011 年被提出, 目前最新第五版修正是 2012 年 8 月提出, 但修正案還沒有通過. ( http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-05 )

以下是這次的小小題外話.

IPv6 已經十幾二十歲了, 當年他的許多優點到現在看起來, 大概都隨著 IPv4 相關協定的修正與研發而消失了. 以企業網路的角度來看, IPv6 真的對企業營運有幫助的好處也只有『IP 位址很多』而已. 其他原本的各種訴求, 大多可以在現有的環境上做到, 而且解法都已經相當的成熟與穩定. 除了 IP 數量以外其他做不到的事情, 說穿了也就是企業運作不需要 / 不重要的東西.

GRE keep-alive on Juniper J-/SRX ?

GRE itself is purely session-less stuff and there is no built-in mechanism to detect the tunnel status. Different vendor then create different method to check the GRE tunnel status.

For example, Cisco IOS can config "keep alive" on the GRE interface, and Juniper JUNOS can config "keep alive" under [edit protocol oam gre-tunnel interface-name] level.

Unfortunately, Juniper J-series and SRX do not support [protocol oam] at this moment. The unconditionally "up" status on GRE interface could potentially lead to black hole.

In my environment, I do have BGP peering over the GRE tunnel between devices on two ends. Fortunately I can use BFD on BGP peering session to detect the connectivity and able to react to network failure quicker.

It's very easy to config BFD on Juniper BGP protocol, as below

[edit protocol bgp group XXX] or
[edit protocol bgp group XXX neighbor YYY]
set bfd-liveness-detection minimum-interval 1000

Where the unit of internal is ms, hence 1000 means 1 second.

During the setup of BFD, original BGP session status is intact. It is safe to setup BFD on one side and then work on another side. Also "clear bfd adaptation" command is hitless.

It is always good to have OAM or BFD when running things over Metro-E or Tunnel.

Juniper SRX-100, GRE over IPsec and Bypass Session Table

Juniper made a very unwelcome decision to terminate packet-mode JUNOS on J-series router since 9.4 that indeed creates lots of concerns to some people, such as me, who uses J-series router as a "real" router.

Since that we need to worry about the factor of new session per second, as well as concurrent sessions when we deploy and operate the router. The new SRX firewall, according to some rumors I heard, maybe eventually retire J-series router. Juniper also advertises SRX as firewall and "security" router for branch offices.

The only reason I can image is there are some politics inside the company prevents product management team listen to customers and insist "security router" is a good selling point. However, Juniper must fully aware the burden from session table when deploy J-series and/or SRX as a pure router. Other wise the "packet-mode" and "selective packet-mode" functions will not be created.

Back in packet-mode JUNOS, it was a happy time to play with J-series router with ever capabilities, including IPsec VPN. With the flow-mode JUNOS when turning the router into packet-mode we no longer able to create IPsec VPN with remote sites, but running in flow-mode makes our NOC nervous, worrying about session table usage all the time.

According to the selective-packet-mode document, if we can establish GRE over IPsec to remote site, and put GRE interface and all down-link interface into packet-mode, we should able to bypass the session creation on those interfaces; turns out we should have very limited sessions that related to IPsec itself rather than huge amount of user sessions that travel through the box.

Since the requirement is to carry layer-3 IP traffics to remote site, rather then carry layer-2 packets. The TCP protocols should able to adjust MTU size by itself rather than rely on the fragmentation / reassembling mechanism when encapsulate user packets into GRE. So the involvement of IDP is not necessary (J- / SRX uses IDP module to reassemble GRE packet... another weird / bad decision.)

Following is the configuration and performance testing by using two SRX-100 to demo this idea.

/* == SRX-100 VPN Box @ LAB2 == */
interfaces {
    fe-0/0/0 {
        description "## PC under LAB2 ##";
        unit 0 {
            family inet {
                filter {
                    input packet-mode-ipv4;
                }
                address 10.2.0.254/24;
            }
        }
    }
    gr-0/0/0 {
        description "## GRE overhead 24 bytes ##";
        unit 1 {
            description "## GRE to HQ ##";
            tunnel {
                source 172.31.0.2;
                destination 172.31.0.1;
                path-mtu-discovery;
            }
            family inet {
                mtu 1400;
                filter {
                    input packet-mode-ipv4;
                }
                address 10.0.0.2/30;
            }
        }
    }
    fe-0/0/3 {
        description "## Internet Uplink ##";
        unit 0 {
            family inet {
                address 2.2.2.2/24;
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 10.0.2.253/32 {
                    primary;
                    preferred;
                }
                address 172.31.0.2/32;
            }
        }
    }
    st0 {
        description "## IPsec overhead (proposal std/std) 62 bytes ##";
        unit 1 {
            description "## ipsec to HQ ##";
            family inet {
                mtu 1438;
            }
        }
    }
}
routing-options {
    rib inet.0 {
        static {
            /* == default route to Internet == */
            route 0.0.0.0/0 next-hop 2.2.2.254;
            /* == HQ GRE End-Point == */
            route 172.31.0.1/32 next-hop st0.1;
            /* == HQ PC == */
            route 192.168.101.0/24 next-hop 10.0.0.1;
        }
    }
}
security {
    ike {
        policy ike_pol_hq {
            mode main;
            proposal-set standard;
            pre-shared-key ascii-text "MYKEY";
        }
        gateway gw_hq {
            ike-policy ike_pol_hq;
            address 1.1.1.1;
            local-identity inet 2.2.2.2;
            external-interface fe-0/0/3.0;
        }
    }
    ipsec {
        policy ipsec_pol_hq {
            perfect-forward-secrecy {
                keys group2;
            }
            proposal-set standard;
        }
        vpn hq {
            bind-interface st0.1;
            vpn-monitor;
            ike {
                gateway gw_hq;
                ipsec-policy ipsec_pol_hq;
            }
            establish-tunnels immediately;
        }
    }
    alg {
        dns disable;
        ftp disable;
        h323 disable;
        mgcp disable;
        msrpc disable;
        sunrpc disable;
        real disable;
        rsh disable;
        rtsp disable;
        sccp disable;
        sip disable;
        sql disable;
        talk disable;
        tftp disable;
        pptp disable;
    }
    flow {
        tcp-session {
            no-syn-check;
            no-syn-check-in-tunnel;
            no-sequence-check;
        }
    }
    policies {
        from-zone trust to-zone untrust {
            policy trust-to-untrust {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        from-zone untrust to-zone untrust {
            policy untrust-to-untrust {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        from-zone trust to-zone trust {
            policy trust-to-trust {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
    }
    zones {
        security-zone trust {
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                lo0.0;
                fe-0/0/0.0;
                gr-0/0/0.1;
                st0.1;
            }
        }
        security-zone untrust {
            screen untrust-screen;
            host-inbound-traffic {
                system-services {
                    ping;
                    ike;
                }
            }
            interfaces {
                fe-0/0/3.0;
            }
        }
    }
}
firewall {
    family inet {
        filter packet-mode-ipv4 {
            term all-packet-mode {
                then {
                    packet-mode;
                    accept;
                }
            }
        }
    }
}
/* == END of config on VPN Box @ LAB2 == */


/* =============================================== */


/* == SRX-100 VPN Box @ HQ == */
interfaces {
    fe-0/0/0 {
        description "## PC under HQ ##";
        unit 0 {
            family inet {
                filter {
                    input packet-mode-ipv4;
                }
                address 192.168.101.254/24;
            }
        }
    }
    gr-0/0/0 {
        description "## GRE overhead 24 bytes ##";
        unit 2 {
            description "## GRE to LAB2 ##";
            tunnel {
                source 172.31.0.1;
                destination 172.31.0.2;
                path-mtu-discovery;
            }
            family inet {
                mtu 1400;
                filter {
                    input packet-mode-ipv4;
                }
                address 10.0.0.1/30;
            }
        }
    }
    fe-0/0/3 {
        description "## Internet Uplink ##";
        unit 0 {
            family inet {
                address 1.1.1.1/24;
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 10.0.1.253/32 {
                    primary;
                    preferred;
                }
                address 172.31.0.1/32;
            }
        }
    }
    st0 {
        description "## IPsec overhead (proposal std/std) 62 bytes ##";
        unit 2 {
            description "## ipsec to lab2 ##";
            family inet {
                mtu 1438;
            }
        }
    }
}
routing-options {
    rib inet.0 {
        static {
            /* == default route to Internet == */
            route 0.0.0.0/0 next-hop 1.1.1.254;
            /* == LAB2 GRE End-Point == */
            route 172.31.0.2/32 next-hop st0.2;
            /* == LAB2 PC == */
            route 10.2.0.0/24 next-hop 10.0.0.2;
        }
    }
}
security {
    ike {
        policy ike_pol_lab2 {
            mode main;
            proposal-set standard;
            pre-shared-key ascii-text "MYKEY";
        }
        gateway gw_lab2 {
            ike-policy ike_pol_lab2;
            address 2.2.2.2;
            local-identity inet 1.1.1.1;
            external-interface fe-0/0/3.0;
        }
    }
    ipsec {
        policy ipsec_pol_lab2 {
            perfect-forward-secrecy {
                keys group2;
            }
            proposal-set standard;
        }
        vpn hq {
            bind-interface st0.2;
            vpn-monitor;
            ike {
                gateway gw_lab2;
                ipsec-policy ipsec_pol_lab2;
            }
            establish-tunnels immediately;
        }
    }
    alg {
        dns disable;
        ftp disable;
        h323 disable;
        mgcp disable;
        msrpc disable;
        sunrpc disable;
        real disable;
        rsh disable;
        rtsp disable;
        sccp disable;
        sip disable;
        sql disable;
        talk disable;
        tftp disable;
        pptp disable;
    }
    flow {
        tcp-session {
            no-syn-check;
            no-syn-check-in-tunnel;
            no-sequence-check;
        }
    }
    policies {
        from-zone trust to-zone untrust {
            policy trust-to-untrust {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        from-zone untrust to-zone untrust {
            policy untrust-to-untrust {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        from-zone trust to-zone trust {
            policy trust-to-trust {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
    }
    zones {
        security-zone trust {
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                lo0.0;
                fe-0/0/0.0;
                gr-0/0/0.2;
                st0.2;
            }
        }
        security-zone untrust {
            screen untrust-screen;
            host-inbound-traffic {
                system-services {
                    ping;
                    ike;
                }
            }
            interfaces {
                fe-0/0/3.0;
            }
        }
    }
}
firewall {
    family inet {
        filter packet-mode-ipv4 {
            term all-packet-mode {
                then {
                    packet-mode;
                    accept;
                }
            }
        }
    }
}
/* == END of config on VPN Box @ HQ == */

/* =============================================== */

/*== iperf tcp performance test from lab2 to hq == */

ylchang@lab2pc:~> iperf -mN -i 1 -w 1m -c 192.168.101.101
------------------------------------------------------------
Client connecting to 192.168.101.101, TCP port 5001
TCP window size: 1.00 MByte (WARNING: requested 1.00 MByte)
------------------------------------------------------------
[  3] local 10.2.0.202 port 52399 connected with 192.168.101.101 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec  5.88 MBytes  49.3 Mbits/sec
[  3]  1.0- 2.0 sec  4.88 MBytes  40.9 Mbits/sec
[  3]  2.0- 3.0 sec  5.00 MBytes  41.9 Mbits/sec
[  3]  3.0- 4.0 sec  5.00 MBytes  41.9 Mbits/sec
[  3]  4.0- 5.0 sec  5.12 MBytes  43.0 Mbits/sec
[  3]  5.0- 6.0 sec  5.12 MBytes  43.0 Mbits/sec
[  3]  6.0- 7.0 sec  5.00 MBytes  41.9 Mbits/sec
[  3]  7.0- 8.0 sec  5.12 MBytes  43.0 Mbits/sec
[  3]  8.0- 9.0 sec  5.12 MBytes  43.0 Mbits/sec
[  3]  9.0-10.0 sec  5.12 MBytes  43.0 Mbits/sec
[  3]  0.0-10.0 sec  51.5 MBytes  43.1 Mbits/sec
[  3] MSS size 1348 bytes (MTU 1388 bytes, unknown interface)
/*== End of iperf tcp performance test == */

With this configuration, we successfully bypass session creation when traffic travel through IPsec VPN between sites. The entire box has only 5 sessions (include the telnet session I used to login) even the user PCs creates tens of thousand connections across the sites.

壹電視機上盒

壹電視機上盒 (網樂通) 雖然不錯, 但是麻煩的是他使用 p2p 架構, 會瘋狂生 session 出來. 一般的狀況倒也是沒有太大問題, 但是碰到機車 ISP (很在意 p2p 的 ISP) 麻煩就大了.

最近買了 TP-LINK TL-WR1043ND 這個玩具, 當然順手刷上 DD-WRT 破解一下 增強功能, 然後再順手把機上盒的連線擋一下, 免得 AT&T來關切.

壹電視基本上只要開 ICMP (ping), DNS (tcp/udp 53), NTP (udp 123), HTTP/HTTPS (tcp 80/443) 就可以了. 以下是壹電視 server 網段列表:

63.221.156.0/24
80.77.6.0/24
203.69.108.0/23
203.192.135.0/24
203.208.204.0/24

以下是 DD-WRT 的 firewall rules (從 web 管理介面進去, administration --> commands, 然後在 command shell 輸入下面指令, 按 save firewall 即可)

iptables -I FORWARD 1 -i br0 -p icmp \
 -s [BOX-IP] -j ACCEPT
iptables -I FORWARD 2 -i br0 -p udp -m multiport \
 -s [BOX-IP] --dport 53,123 -j ACCEPT
iptables -I FORWARD 3 -i br0 -p tcp \
 -s [BOX-IP] --dport 53 -j ACCEPT
iptables -I FORWARD 4 -i br0 -p tcp -m multiport \
 -s [BOX-IP] -d 63.221.156.0/24 --dport 80,443 -j ACCEPT
iptables -I FORWARD 5 -i br0 -p tcp -m multiport \
 -s [BOX-IP] -d 80.77.6.0/24 --dport 80,443 -j ACCEPT
iptables -I FORWARD 6 -i br0 -p tcp -m multiport \
 -s [BOX-IP] -d 203.192.135.0/24 --dport 80,443 -j ACCEPT
iptables -I FORWARD 7 -i br0 -p tcp -m multiport \
 -s [BOX-IP] -d 203.208.204.0/24 --dport 80,443 -j ACCEPT
iptables -I FORWARD 8 -i br0 -p tcp -m multiport \
 -s [BOX-IP] -d 203.69.108.0/23 --dport 80,443 -j ACCEPT
iptables -I FORWARD 9 -i br0 -s [ETV-BOX-IP] -j REJECT

(有 \ 的跟前一行相連)

以上... 呵呵呵呵~~~

vmware workstation 7 的 bridget network 亂吃 ipv6 封包

最近不知道怎麼回事, 我 LAB 的 Vmware workstation bridge network 的 ipv6 出現時通時不通的現象, 後來惡化到完全不通. 搞了幾天搞不定. 剛剛福至心靈換成 virtual box 就好了...

Debug 的時候 wireshark 看封包看到眼睛快要脫窗... 明明封包都有打進去, 但是 guest OS 就是沒收到, vmware bridge network card 大概是肚子餓到荒, 亂吃封包!

結論: 好想丟手榴彈!

Sample PBR on ScreenOS

Following is a sample for Policy Based Routing (PBR) on Juniper ScreenOS (NetScreen & SSG)

set policy id 1

set vrouter "trust-vr"

  set access-list extended 1 dst-port \
    <PortRangeStart>-<PortRangeEnd> \
    protocol <TCP-or-UDP-or> entry 1

  set match-group name <Match-Group-Rule-Name>

  set match-group <Match-Group-Rule-Name> ext-acl 1 \
    match-entry 1

  set action-group name <Action-Group-Rule-Name>

  set action-group <Action-Group-Rule-Name> \
    next-interface <nexthop-interface> action-entry 1

  set pbr policy name <PBR-Policy-Name>

  set pbr policy <PBR-Policy-Name> match-group \
    <Match-Group-Rule-Name> action-group \
    <Action-Group-Rule-Name> 1

  set pbr <PBR-Policy-Name>

exit

set interface <Interface-of-Traffic-to-be-PBR> \
  pbr <PBR-Policy-Name>

(joint two lines break by \)

ipv6 nat (nat66) by Juniper ScreenOS

ScreenOS is the operation system in Juniper SSG & NS device (was NetScreen).

There is no clear document states ScreenOS could perform nat66 (at least Juniper does not use the term "nat66".) However, if one could follows ScreenOS release notes carefully, it became consequences.

set policy id 1 from "Trust" to "Untrust"  \
    "Any-IPv6" "Any-IPv6" "ANY" nat src permit 
set policy id 1

Where obviously, key word "nat" does the trick!

ipv6 nat (nat66) by FreeBSD pf

although nat66 is still under draft, but FreeBSD pf already support it for long time.
(edit the pf.conf and insert following codes)

v6_wan_if="your-v6-wan-interface-name"
v6_wan_ip="your-v6-wan-ip-address"

no nat on $v6_wan_if inet6 from $v6_wan_ip to any
nat on $v6_wan_if inet6 from any to any -> $v6_wan_ip    

You are all set!

Sync calendar/task/contact/notes between Google and MS-Outlook

這兩天搞 Outlook --> Google 的 Calendar Sync 想把兩邊的行事曆整合在一起.

不過 Google 自己的 sync 工具實在太陽春, 對於跨日的 event 會錯亂, 然後 Google Calendar 又很白癡, 只要一手動去修改就會亂發垃圾信出去... 對收到我垃圾信的朋友深感抱歉... Orz...

剛找到一個要錢的軟體 gSyncit 試用了一下看起來還不錯!

Sync 跨日的 Event 不會亂掉, 處理 timezone 資料也正確. 而且還可以選擇性的不要把參加者的資料送上去 Google, 這樣就算調整了東西, Google Calendar 也沒辦法亂發垃圾信, 讚!

gSyncit 要價 US$14.99, 先用一陣子看看要不要花錢買正式版 ^_^

gSyncit: http://www.daveswebsite.com/software/gsync/index.shtml

啟用 Iphone 4 內建 Tethering

參考: http://forums.macrumors.com/showthread.php?t=984943

會操作 UNIX 的人可以略加變化, 不需要動用 Cyberduck 或是其他 SFTP 軟體, 只要有一台連在網上的 ssh server 就可以了. 所有的備份也都可以直接上傳到那個 ssh server.

終於對 iphone 動心

最近高齡四歲的舊手機的電池越來越沒檔頭, 講電話一兩分鐘就乾掉, 上網收個 email 看看大約十來分鐘就乾掉. 變成名副其實的緊急專用電話, 非到必要關頭不願意拿出來用. 煩惱的是連阿嬤粽都已經買不到相容的電池了. 眼看只有換新手機一途.

看了許多手機的比較, 終於對 Iphone 4 動心了. 吸引我的不是他的各種 apps, 而是電池的續航力. 姑且不論不能自己換電池這個缺點, 這是個很嚴重的缺點, 嚴重到我過去幾年一直不把他列入考慮. 但是這陣子深深覺得, 能夠長時間連續講電話是一件很重要的事情, 電話講一半因為手機沒電掛點, 有時候會發生奇異的悲劇. Orz...

Iphone 4 電池續航力官方數據如下:

7 hrs 3G Talk / Internet browsing
12 hrs 2G Talk
10 hrs WiFi Internet browsing
40 hrs Music Playback
10 hrs Video Playback

先不看其他部分, 光是講電話這個數據就打趴一大堆競爭對手, 如果以 Smart Phone / PDA phone 來比的話, 大概全趴了...雖然很討厭 Apple 這公司, 尤其是他家的執行長真是霸道, 小心眼, 外加沒修養到極點, 但是他家的工程團隊真是了得, 可以在這麼小的機身裡面塞進這麼多功能跟這麼長壽的電池. 這點不拍手就真的是違背良心了!

現在還在預購階段要等到 6/24 才會正式出貨, 再來猶豫幾天吧~~~

從 Bloglines 跳槽到 Google Reader

話說 Bloglines 用了好幾年, 但是越用問題越多. 一來是搜尋不易, 再來是出現 server timeout 或是其他怪事的頻率越來越高. 這幾天更慘, 幾乎天天都遇到 server timeout.

前兩天從 Bloglines 跳槽到 Google Reade, 經過兩天的適應已經擺脫不熟悉的感覺. 用起來沒有太大的問題. 希望財大氣粗的 Google 沒有 server capacity 或是網路資源不足的問題.

這兩天的使用經驗是, Google Reader 明顯比  Bloglines 快非常多, 介面上稍為簡單清晰一點. 唯一不太適應的是 Google Reader 顯示的 RSS 抓取的時間, 而不是文章發布的時間. 這點論壇裡面也有人討論跟反映, 但是似乎一直沒有選項可以去改 (至少我還沒找到選項).

Pop Quiz: separate odd and even IP numbers

In Juniper JUNOS, ip/mask could be used to separate odd/even IP numbers. similar to wildcard in Cisco IOS.

[edit firewall family inet]
filter Separate-Numbers {
    /* match even IPs 10.10.10.{0,2,4,6,8,...} */
    term Even-Numbers {
        from {
            source-address {
                10.10.10.0/255.255.255.1;
            }
        }
        then {
            xxxxx;
        }
    }
    /* match odd IPs 10.10.10.{1,3,5,7,9,...} */
    term Odd-Numbers {
        from {
            source-address {
                10.10.10.1/255.255.255.1;
            }
        }
        then {
            xxxxx;
        }
    }
}

ICANN 開通非拉丁語系頂級域名 - 巴別塔的狂想

這不是太新的新聞了,不過這東西有他正反兩面的論述. 最簡單的來說, 在於可能發生的輸入問題. 以中文來說, 輸入中文比輸入英文的困難度大 (假設不考慮語言的使用問題, 比如說不懂英文不懂中文.)

另外就是中文有字體上面的問題, 舉例來說簡體字跟繁體字到底是代表同一個網站或是不同網站? 或是說俗體字跟正體字呢 (例如 台灣 跟 臺灣 到底是不是同一個網站/網域.) 相關的論述很多, 沒必要在這邊舊調重彈.

今天想到的是聖經的故事.

那時、天下人的口音言語、都是一樣。他們往東邊遷移的時候、在示拿地遇見一片平原、就住在那裏。他們彼此商量說、來吧、我們要作磚、把磚燒透了。他們就拿磚當石頭、又拿石漆當灰泥。他們說、來吧、我們要建造一座城、和一座塔、塔頂通天、為要傳揚我們的名、免得我們分散在全地上。耶和華降臨要看看世人所建造的城和塔。耶和華說、看哪、他們成為一樣的人民、都是一樣的言語、如今既作起這事來、以後他們所要作的事、就沒有不成就的了。我們下去、在那裏變亂他們的口音、使他們的言語、彼此不通。於是耶和華使他們從那裏分散在全地上。他們就停工、不造那城了。因為耶和華在那裏變亂天下人的言語、使眾人分散在全地上、所以那城名叫巴別。
    – 創世記 11:1-9（中文和合本）

網域名稱本來只能用英文, 某個程度來說是使用著相同的表達方式. 上帝警覺到了! 於是非拉丁語系的次網域開通了, 接下來頂級域名也開通了. 是不是巴別塔的重現?

神奇的 50Gbps 網路卡

顯然 Windows 7 已經瘋掉了... 我這種小電腦哪來的 50Gbps 能力...

Juniper J-series routers in packed-based mode

Star from JUNOS 9.4, the packet-mode (traditional) JUNOS for J-series is no longer exist; the only version is flow-mode J-series JUNOS (the ES version.) However, packet-based mode is quite handy if people simple need a small router without worry about those session-table, symmetric routing, and etc.

In JUNOS 9.6, a statement under [security] section could bring the J-series box back to pure packet-based mode. Actually that is a side effect of another statement, but it is a good side effect, from this point of view. Which is a statement that make MPLS family to be run under packet-mode, and the side effect is to bring inet family also into packet-mode.

Under this mode, all other security policy (under [security] section) is no longer available, but stateless firewall filter works well (under [firewall] section.)

The configuration is,

[edit]
delete security
set security forwarding-options family mpls mode packet-based

There do have other side effects that IPsec VPN is no longer avalible, because IPsec VPN in 9.6 is flow-based.

俗語說的好『xx改不了吃xx』

 大約 3/24 左右開始, facebook, youtube, 跟 twitter 就發現間歇性的被導到中國去. 從觀察看起來類似 DNS poison 的現象. 整件事情的源頭不意外是從中國來的. 下面的討論串有比較詳細的技術資料

  https://lists.dns-oarc.net/pipermail/dns-operations/2010-March/005260.html

然後今天有人拿出 GFW 的東西出來佐證. https://lists.dns-oarc.net/pipermail/dns-operations/2010-March/005323.html

這事情只能說『xx改不了吃xx』... 對中國任何事情都要小心防備.

1. BGP peer 要 filter 掉不該有的東西
2. 最好不要用任何中國的企業提供的服務

不要以為從中國 VPN 出來就很安全, 因為

1. 在當地只能用當地業者提供的線路跟服務
2. man in the middle 只要有心, 技術上都做的到


就算拉專線也不見得 100% 安全. 說到底, 能夠不要跟中國有往來是最好的... 當然這可能辦不到...