VPN Provider with OpenVPN access – check your DNS settings to avoid DNS leaks!

Posted on by

You have bought a VPN account at one of the major VPN providers. You have done so, because you e.g. have a second residence in another country. You may even have a dual citizenship.
Let us assume that you are abroad and want to work with web services offered in your home country for its citizens.

You are abroad, but electronically you may need to operate as if you were located in your home country. There are a lot of services which check the geolocation of your IP and only serve you if you call from “inside” the country, i.e. if the IP is located there.

Continue reading →

NUMA node error for Nvidia cards on Linux PCs

Posted on by

You may have experienced it in various contexts: CUDA, Tensorflow, gaming applications or complex 3D graphics applications may warn you that your Nvidia card is associated with an unexpected negative NUMA value. The warning often refers to a value of “-1”. And the clever application replaces this value by a default value of “0”.

The problem is particularly annoying when dealing Machine Learning, e.g. in Jupyter notebooks. There warnings may repeatedly clatter the output of some cells – e.g. during the setup of the graphics card for some ML experiments.

Besides the question why the Nvidia drivers for Linux and/or CUDA drivers do not fix this problem by detecting just one NUMA node on the system and setting the value for the card to “0”, the question for us users is how we can get rid of the warnings.

A basic idea is that we set the right value by ourselves. I have described this simple measure in the sister blog, which unfortunately still is under construction. See:
Setting NUMA node to 0 for Nvidia cards on standard Linux PCs.

There I also briefly discuss what NUMA basically is thought for – and why it normally does not affect consumer PCs.

 

More fun with veth and Linux network namespaces – VII – two namespaces connected by a veth based VLAN

Posted on by

With the last one of the previous posts in this series

we started to look at VLANs based on veths and Linux bridges. I presented multiple options to configure a veth endpoint in a network namespace for enabling communication with other namespaces via tagged Ethernet packets.

We saw that we can potentially start splitting network traffic already from within a multi-homed namespace which is connected to different VLAN-segments. However, a veth endpoint with multiple interfaces also poses a basic ambiguity problem for the direction of both ARP and ICMP requests into the right one of the various attached (V)LAN-segments. From the results of previous experiments we would assume that the Linux kernel solves this problem by following routes.

In this post we will study the most simple VLAN configuration one can think of: We connect two network namespaces directly with a veth based VLAN line. I.e. we use a veth connection to transmit tagged packets along it. As this would be a lit boring, we add some pepper to the scenario by allowing for untagged packets, too.

To achieve this we reduce “option 4” discussed in the last post to a one-armed solution: We allow for only one VLAN interface per veth endpoint (see a sketch of the scenario below). We start a series of experiments with assigning an IP to the veth’s main interface, only. The setting for the source validation kernel parameter rp_filter will be relaxed.

In the experiments of this post we focus on

  • some claimed aspects regarding the role of the main trunk interface of a veth endpoint,
  • the potential impact of routes on the ARP communication.
  • the fact that working ARP does not mean working ICMP for a variety of different reasons.

Regarding the first point we will see that tagged packets just traverse the trunk interfaces on their way from and to the VLAN interface. Regarding route settings we will look at 36 possible variants. We will see that under the given conditions asymmetric route settings may or may not disable communication – already on the ARP level. But even if ARP works and even if we had symmetric routes in the namespaces, ICMP may not function. I will try to isolate the causes of positive and negative results for ARP and ICMP requests.

I recommend that readers who want to perform these experiments on their own to watch the system log in parallel.

Continue reading →