blog: +ipv6 vpn dns
This commit is contained in:
Nico Schottelius
parent
e7e399a67d
commit
afd8fa769e
1 changed files with 198 additions and 0 deletions
198
content/u/blog/ipv6-success-story-vpn-dns-names/contents.lr
Normal file
198
content/u/blog/ipv6-success-story-vpn-dns-names/contents.lr
Normal file
|
|
@ -0,0 +1,198 @@
|
|||
title: IPv6, VPN and DNS entries
|
||||
---
|
||||
pub_date: 2021-10-13
|
||||
---
|
||||
author: Nico Schottelius
|
||||
---
|
||||
twitter_handle: NicoSchottelius
|
||||
---
|
||||
_hidden: no
|
||||
---
|
||||
_discoverable: yes
|
||||
---
|
||||
abstract:
|
||||
Looking at how the patterns of VPN and DNS names changes with IPv6
|
||||
---
|
||||
body:
|
||||
|
||||
## TL; DR
|
||||
|
||||
With IPv6, DNS management of protected networks can be
|
||||
simplified. IPv6 VPNs can use simplified DNS configurations to
|
||||
simplify the network configurations by just using public, restricted
|
||||
DNS entries.
|
||||
|
||||
## VPN and DNS in the IPv4 world
|
||||
|
||||
VPNs in the IPv4 world are often used to create site-to-site tunnels,
|
||||
allowing different networks to talk to each other. A typical case is
|
||||
that organisation A needs to access protected resources of
|
||||
organisation B and maybe even vice-versa. So a typical VPN looks like
|
||||
this:
|
||||
|
||||
```
|
||||
Organisation A
|
||||
--------------
|
||||
|
||||
Protected Host A ---------- Router/VPN gateway
|
||||
(10.0.0.42/24) |
|
||||
|
|
||||
|
|
||||
Organisation B (Internet)
|
||||
-------------- |
|
||||
|
|
||||
|
|
||||
Protected Host B ---------- Router/VPN gateway
|
||||
(10.20.0.42/24)
|
||||
Host name: lakeside.int.org-b.example.com
|
||||
```
|
||||
|
||||
Now if the Protected Host A and Protected Host B want to communicate
|
||||
with each other on IP basis, this is no problem (I am not elaborating
|
||||
on the problems of IP collisions in this article, a follow up article
|
||||
will follow soon).
|
||||
|
||||
However if Protected Host A wants to reach the Protected Host B via
|
||||
its internal DNS name **lakeside.int.org-b.example.com**, this is
|
||||
usually a problem, for multiple reasons:
|
||||
|
||||
* Protected Host A might not know the right internal DNS server to
|
||||
query for int.org-b.example.com.
|
||||
* Protected Host A might know the right internal DNS server to
|
||||
query for int.org-b.example.com, but might not have access to it via
|
||||
the VPN
|
||||
* The DNS records for int.org-b.example.com often are intentionally
|
||||
not published to public DNS for multiple reasons: privacy related or
|
||||
because administrators don't like to publish RFC1918 records into
|
||||
public DNS records
|
||||
|
||||
|
||||
## VPN and DNS in the IPv6 world
|
||||
|
||||
There are multiple ways of how VPNs can be built in the IPv6 world,
|
||||
including usage of the private IPv4 addresses equivalent named Unique
|
||||
Local Address (ULA). However instead of using ULA, I will today show
|
||||
an approach that is more "IPv6 native", using Global Unique Addresses
|
||||
(GUA), or what is simply known as "public IPv6 address".
|
||||
|
||||
While you might have heard it, I will repeat nonetheless: there are
|
||||
enough IPv6 addresses for every practical use case that we imagine at
|
||||
the moment. This is important, because we can use **globally unique
|
||||
IPv6 addresses** inside the VPN.
|
||||
|
||||
Isn't that a problem? Publicly reachable IPv6 addresses inside a VPN?
|
||||
It would, if the addresses were **globally reachable**. In the IPv6
|
||||
world nothing speaks against having **globally unique, but non-routed
|
||||
IPv6 addresses**. This is actually a perfect match and much better
|
||||
than we can do in the IPv4 world:
|
||||
|
||||
* Both organisations A and B can acquire globally unique
|
||||
addresses. Let's say they organisation A acquires 2001:db8:0::/48 and
|
||||
organisation B acquires 2001:db8:1::/48.
|
||||
* Both organisations have two options: they can announce their IPv6
|
||||
range to the Internet and block access to their internal network or
|
||||
* both they can even consider not to announce their network at all
|
||||
(there is not route in the Internet for it)
|
||||
|
||||
In either case, both organisations will usually select a sub network
|
||||
of size /64 for the resources they want to expose via the VPN. Let's
|
||||
say organisation A chooses 2001:db8:0:cafe::/64 and organisation B
|
||||
chooses 2001:db8:1:7ea::/64. Putting this in context, their VPN now
|
||||
looks like this:
|
||||
|
||||
```
|
||||
Organisation A
|
||||
--------------
|
||||
|
||||
Protected Host A ---------- Router/VPN gateway
|
||||
(2001:db8:0:cafe::42/64) |
|
||||
|
|
||||
|
|
||||
Organisation B (Internet)
|
||||
-------------- |
|
||||
|
|
||||
|
|
||||
Protected Host B ---------- Router/VPN gateway
|
||||
(2001:db8:1:7ea::42/64) |
|
||||
Host name: lakeside.int.org-b.example.com
|
||||
```
|
||||
|
||||
Now, how does this change the DNS server situation? Because we are
|
||||
using IPv6, we have many more options:
|
||||
|
||||
* a) We can publish the DNS records of the domain
|
||||
int.org-b.example.com globally. While access to the network
|
||||
2001:db8:1:7ea::/64 is only possible via VPN, nothing speaks against
|
||||
having the records in a public DNS server. However, some
|
||||
administrators advocate to not publish them publicly for privacy
|
||||
reasons. That is the same logic as publishing or not publish the
|
||||
RFC1918 (10.x.y.z) addresses in the IPv4 world.
|
||||
* b) We can publicly/globally delegate the domain
|
||||
int.org-b.example.com to a nameserver that is only reachable via the
|
||||
VPN.
|
||||
* c) We can proceed the same as in the IPv4 world and have a
|
||||
disconnect, internal DNS server that is responsible for
|
||||
int.org-b.example.com.
|
||||
|
||||
Option (a) is often seen as a security risk and it can be debated
|
||||
whether someone who can already guess the correct hostname and
|
||||
retrieve it's IP address is really a significant higher security
|
||||
thread than anybody just guessing IP addresses.
|
||||
|
||||
Option (c) is the typical case for IPv4 based VPNs and is causing
|
||||
above illustrated issues.
|
||||
|
||||
Option (b) is the one that makes IPv6 VPNs much more interesting than
|
||||
IPv4 based VPNs:
|
||||
|
||||
* The world can know that there is an internal domain
|
||||
**int.org-b.example.com** and find out which DNS servers are
|
||||
responsible for it.
|
||||
* However an attacker easily guesses that internal networks exist
|
||||
anyway.
|
||||
|
||||
Let's have a look at sample nameserver entries in detail:
|
||||
|
||||
```
|
||||
int.org-b.example.com. NS ns-int1.org-b.example.com.
|
||||
int.org-b.example.com. NS ns-int2.org-b.example.com.
|
||||
```
|
||||
|
||||
What does that mean? Anyone in the world can retrieve the information
|
||||
that int.org-b.example.com has two DNS servers. However the DNS
|
||||
servers responsible for org-b.example.com can hide the IP addresses of
|
||||
ns-int1.org-b.example.com and ns-int2.org-b.example.com for everyone,
|
||||
but hosts coming from organisation A. Or even if the IP addressses of
|
||||
ns-int1.org-b.example.com and ns-int2.org-b.example.com are world
|
||||
known, access to them can easily be prevented.
|
||||
|
||||
The measures for this can for instance be DNS views or firewall
|
||||
entries. In practice this means for VPNs in the IPv6 world:
|
||||
|
||||
|
||||
```
|
||||
Organisation A
|
||||
--------------
|
||||
|
||||
Protected Host A: what is the IP address of lakeside.int.org-b.example.com?
|
||||
DNS Server of Organisation B: 2001:db8:1:7ea::42
|
||||
|
||||
|
||||
Outside party
|
||||
-------------
|
||||
Outside Hosts: what is the IP address of lakeside.int.org-b.example.com?
|
||||
|
||||
a) DNS Server of Organisation B: there is no domain
|
||||
int.org-b.example.com (DNS view restriction)
|
||||
b) DNS Server of Organisation B: these are the nameserver for
|
||||
int.org-b.example.com, but you cannot reach them (firewall protection)
|
||||
```
|
||||
|
||||
## Summary
|
||||
|
||||
For IPv6 based VPNs you can get away without reconfiguring your source
|
||||
networks for DNS servers of the destination party. The target party
|
||||
always needs to ensure proper access control to internal resources, so
|
||||
there is no additional overhead.
|
||||
|
||||
DNS, correctly designed in the IPv6 VPN world, just works.
|
||||
Loading…
Reference in a new issue