Allow ssh to access a remote linux system

 in the machine where you like to access the remote system, generate a ssh key and certificate file, normally id_rsa and id_rsa.pub file. Then copy the content of id_rsa.pub file to the remote system ~/.ssh/authorized_keys file, then you should be able to access the system.

Istio ambient mesh ztunnel implementations

 

# The results come from ztunnel pod

# iptables -S -t nat

-P PREROUTING ACCEPT

-P INPUT ACCEPT

-P OUTPUT ACCEPT

-P POSTROUTING ACCEPT

-A PREROUTING -j LOG --log-prefix "nat pre [ztunnel-ntkqj] "

-A INPUT -j LOG --log-prefix "nat inp [ztunnel-ntkqj] "

-A OUTPUT -j LOG --log-prefix "nat out [ztunnel-ntkqj] "

-A OUTPUT -p tcp -m tcp --dport 15088 -j REDIRECT --to-ports 15008

-A POSTROUTING -j LOG --log-prefix "nat post [ztunnel-ntkqj] "

# iptables -S -t mangle

-P PREROUTING ACCEPT

-P INPUT ACCEPT

-P FORWARD ACCEPT

-P OUTPUT ACCEPT

-P POSTROUTING ACCEPT

-A PREROUTING -j LOG --log-prefix "mangle pre [ztunnel-ntkqj] "

-A PREROUTING -i pistioin -p tcp -m tcp --dport 15008 -j TPROXY --on-port 15008 --on-ip 127.0.0.1 --tproxy-mark 0x400/0xfff

-A PREROUTING -i pistioout -p tcp -j TPROXY --on-port 15001 --on-ip 127.0.0.1 --tproxy-mark 0x400/0xfff

-A PREROUTING -i pistioin -p tcp -j TPROXY --on-port 15006 --on-ip 127.0.0.1 --tproxy-mark 0x400/0xfff

-A PREROUTING ! -d 10.30.0.5/32 -i eth0 -p tcp -j MARK --set-xmark 0x4d3/0xfff

-A INPUT -j LOG --log-prefix "mangle inp [ztunnel-ntkqj] "

-A FORWARD -j LOG --log-prefix "mangle fw [ztunnel-ntkqj] "

-A OUTPUT -j LOG --log-prefix "mangle out [ztunnel-ntkqj] "

-A POSTROUTING -j LOG --log-prefix "mangle post [ztunnel-ntkqj] "

===

-A PREROUTING -i pistioin -p tcp -m tcp --dport 15008 -j TPROXY --on-port 15008 --on-ip 127.0.0.1 --tproxy-mark 0x400/0xfff

Note: take every tcp packet targeting port 15008, deliver to 127.0.0.1:15008 and mark packet with 0x400/0xfff

port 15008 is Istio HBONE mTLS tunnel port

-A PREROUTING -i pistioout -p tcp -j TPROXY --on-port 15001 --on-ip 127.0.0.1 --tproxy-mark 0x400/0xfff

Note: take every tcp packet, then deliver them to 127.0.0.1:15001 and also mark packet with 0x400/0xfff

port 15001 is envoy outbound port

-A PREROUTING -i pistioin -p tcp -j TPROXY --on-port 15006 --on-ip 127.0.0.1 --tproxy-mark 0x400/0xfff

Note: take every tcp packet, then deliver to 127.0.0.1:15006 and mark packet with 0x400/0xfff

port 15006 is envoy inbound port

FIB vs RIB

 

The forwarding information base (FIB) is the actual information that a routing/switching device uses to choose the interface that a given packet will use for egress. For example, the FIB might be programmed such that a packet bound to a destination in 192.168.1.0/24 should be sent out of physical port ethernet1/2. There may actually be multiple FIB's on a device for unicast forwarding vs multicast RPF checking, different protocols (ip vs mpls vs ipv6) but the basic function is the same - selection criteria (usually destination) mapping to output interface/encapsulation. Individual FIB's may also be partitioned to achieve concurrent independent forwarding tables (i.e. vrf's).

Each FIB is programmed by one or more routing information bases (RIB). The RIB is a selection of routing information learned via static definition or a dynamic routing protocol. The algorithms used within various RIB's will vary - so, for example, the means by which BGP or OSPF determines potential best paths vary quite a bit. The means by which multiple RIB's are programmed into a common (set) of FIB's in a box will vary by implementation but this is where concepts like administrative distance are used (e.g. identical paths are learned via eBGP and OSPF, the eBGP is usually preferred for FIB injection). Again, RIB's may also be potentially partitioned to allow for multiple vrf's, etc.

Allow two docker networks to communicate with each other

In some cases, it is useful to have containers running on two different docker bridge networks to communicate with each other. The easist thing is to remove the docker created isolation rules so that containers running on different bridged docker networks wont have their packets dropped by iptable rules. One other way is to add forward rules so that their packet will be accepted. Here is an example, assume there are two bridged docker networks b1 172.19.0.0/16 and b2 172.20.0.0/16. By default the containers running on these two separate networks are isolated (on purpose). With the following two Iptable rules, containers can communicate with each other. 

iptables -I FORWARD -s 172.19.0.0/16 -d 172.20.0.0/16 -j ACCEPT

iptables -I FORWARD -d 172.20.0.0/16 -s 172.19.0.0/16 -j ACCEPT 

How to solve the issue that VirtualBox cloned VMs have same dhcp IP address

In some cases, you may like to clone a VirtualBox VM for a test purposes. But after new VM gets created, you may find that the IP address assigned (using Host Only network) to the cloned VM is the same as the original VM. This of course causes issues. To resolve this problem, one way is to use static IP, but many times you are using DHCP, so in this case, you need to assign different MAC address for the cloned VM, then run the following commands,

sudo dhclient -r enp0s3

sudo dhclient enp0s3

Notice that enp0s3 is the interface card name of your VM, it can be something else such as eth0 or eth1.

Rust ownership, the shining new thing?

 

Ownership Rules

First, let’s take a look at the ownership rules. Keep these rules in mind as we work through the examples that illustrate them:

• Each value in Rust has an owner.
• There can only be one owner at a time.
• When the owner goes out of scope, the value will be dropped.