FOUR FREE NETWORKING FOUNDATIONS
Understand the path behind the connection.
Separate name lookup, routing, HTTPS and peer configuration before changing a VPN setting. Four short lessons, original diagrams and worked questions you can finish here.
Before you start.
You need a browser and the ability to read the examples. No purchase, account, installed VPN, terminal or live network experiment is required. Think through each answer before opening its explanation.
The examples are conceptual exercises. Completing them does not certify a network, prove a VPN’s security or make you ready to administer an internet-facing server. We do not record lesson completion or send answers anywhere.
LESSON 01 / 04
DNS: a name lookup is a separate step.
DNS helps translate a name such as example.com into network addressing information. The resolver you use and the path to that resolver are separate choices from the VPN’s internet exit.
- 01
Your browser
Needs an address for a name.
- 02
Configured resolver
Looks up or returns a cached answer.
- 03
DNS answer
Lets the connection attempt continue.
Original conceptual diagram; no connection or measurement is being performed.
Work through an example.
You enable a DNS filter and an advertising domain no longer resolves. That does not mean every request, application or network connection now uses a VPN. Conversely, starting a VPN does not tell you which resolver every browser or application is using.
Your small task.
Write down two separate questions: “Who receives this lookup?” and “Where does my application traffic go?” Check the app/browser’s documented DNS behavior rather than changing settings at random.
Check your understanding.
A DNS filtering service blocks a tracking domain. What has that established?
Read the answer and explanation
A filtering decision for that lookup. It has not established a full VPN tunnel, removal of every advert, or anonymity from a site you log into.
Keep the boundary: Encrypted DNS protects its transport to the chosen resolver; it does not hide the query from that resolver. A cached answer can also mean a new lookup is not sent for every page load.
Underlying guidance: MDN: DNS (opens in a new tab) · AdGuard: DNS filtering boundaries (opens in a new tab)
LESSON 02 / 04
Routing: decide which destination uses the tunnel.
A route chooses a path for a destination. A tunnel for a private subnet and a tunnel used as the internet’s default path solve different jobs. “Connected” does not describe the route by itself.
- 01
Destination
An authorized address you want to reach.
- 02
Route decision
Matches an installed route and policy.
- 03
Chosen path
VPN interface or another network path.
Original conceptual diagram; no connection or measurement is being performed.
Work through an example.
In a conceptual private-access setup, the operator assigns 10.44.0.0/24 to an internal network. The /24 describes addresses sharing the first 24 bits. With a route for that subnet, the device can send matching destinations toward the tunnel; this alone does not route unrelated internet destinations through it.
Your small task.
Ask the operator which destinations the profile is intended to carry. For a private NAS, check that NAS’s address and access permission. For a public exit, check the configured default-route intent. Do not copy either example route into a live profile without knowing its purpose.
Check your understanding.
Your private NAS works through a tunnel with only a 10.44.0.0/24 route. Does that prove all web traffic uses it?
Read the answer and explanation
No. That subnet route matches only its address range. Default routes, more specific routes and policy rules determine other traffic. IPv4 and IPv6 need separate consideration.
Keep the boundary: A route is not permission to access a system. The gateway still needs forwarding, firewall rules and the operator’s authorization. A default route by itself also does not prove failure blocking.
Underlying guidance: WireGuard: routing inferred from AllowedIPs by wg-quick (opens in a new tab) · RFC 1918: private address ranges (opens in a new tab)
LESSON 03 / 04
HTTPS: the browser connection has its own protection.
HTTPS uses TLS to protect the browser’s connection to the HTTPS endpoint. A VPN adds another tunnel to a VPN endpoint; it does not replace HTTPS, validate every website’s intentions or remove an account login.
- 01
Your device
Starts an HTTPS connection.
- 02
VPN endpoint
The outer tunnel ends here.
- 03
HTTPS endpoint
The HTTPS connection ends at its TLS endpoint.
Original conceptual diagram; no connection or measurement is being performed.
Work through an example.
On a shared network, you visit an HTTPS account page through a VPN. The local network and VPN provider have different visibility into the path, while the HTTPS endpoint still receives the request and your account identity. Adding a VPN does not make a fraudulent HTTPS login page honest.
Your small task.
Check the actual hostname before entering a password. Treat a certificate warning as a problem to investigate rather than an obstacle to dismiss. Keep browser and device updates separate from the VPN subscription decision.
Check your understanding.
Does an HTTPS page through a VPN stop the destination from recognizing the account you sign into?
Read the answer and explanation
No. The HTTPS endpoint must process the account request. The tunnel changes the network path; it does not erase your login, browser state or information you submit.
Keep the boundary: This simplified picture does not describe every proxy, enterprise TLS inspection arrangement or metadata channel. Neither an HTTPS indicator nor a VPN connection is a guarantee that the content or operator is trustworthy.
Underlying guidance: MDN: TLS protection and authentication (opens in a new tab) · Mozilla: HTTPS-only browsing (opens in a new tab)
LESSON 04 / 04
WireGuard: a peer needs more than an on switch.
WireGuard peers use public keys to identify one another. A working setup also needs a reachable endpoint, the right peer configuration and intended routes. Your own private key stays private.
- 01
Public-key peer
Identifies the authorized remote peer.
- 02
Endpoint
Says where packets can reach it.
- 03
AllowedIPs
Connects peer selection and permitted address scope.
Original conceptual diagram; no connection or measurement is being performed.
Work through an example.
You import a trusted device profile and activate it. If the remote gateway has not registered the device’s public key, an active local interface is not proof of a working peer. After generating permitted traffic, inspect the client’s available handshake/transfer information and try the actual destination.
Your small task.
Explain the difference between Endpoint, PublicKey and AllowedIPs without sharing any private key. If you need help, redact the profile before showing it. Then follow the illustrated guide for your actual operating system.
Check your understanding.
Which should stay private when you ask someone to help with a profile: the device private key or only the profile’s friendly name?
Read the answer and explanation
The device private key and any other credentials must stay private. A configuration file or QR code can contain them. If a key is exposed, ask the operator to revoke/replace it; deleting a public message does not revoke access.
Keep the boundary: A recent handshake is useful connection evidence. It does not by itself establish the intended DNS behavior, every route, failure blocking or anonymity. Open-source client software still needs an authorized endpoint and maintenance.
Underlying guidance: WireGuard: conceptual peer model (opens in a new tab) · WireGuard: configuration and keys (opens in a new tab)
AFTER THE FOUR LESSONS
Choose where to practise next.
You can explain which question belongs to DNS, which belongs to routing, what HTTPS protects and why a peer needs a valid configuration. Return to a worked answer whenever one of those distinctions is still unclear.
- Explain why DNS filtering does not establish a VPN tunnel.
- Distinguish a private-subnet route from a default internet route.
- Explain why an HTTPS account can still identify you through a VPN.
- Identify the configuration material that must stay private.
Keep going for free.
For setup, choose the picture guide matching your device. For command-line preparation, Crucible’s free arguments, quoting and expansion lesson (opens in a new tab) introduces shell argument boundaries; basic terminal familiarity helps. If you already program, its free HTTP, JSON and API sequence (opens in a new tab) practises application-level request handling. Those are different branches, not VPN security training.
Want structured terminal practice?
Boot.dev’s Learn Linux course adds guided work on commands, files, processes, input/output and permissions. The course starts with command-line foundations; later local-CLI exercises use your own machine and environment. Bring a willingness to use a terminal and check the current course setup requirements. It is additional Linux practice, not a WireGuard-server deployment course or a requirement for these lessons.
LINUX FOUNDATIONS
Explore Learn Linux on Boot.dev (opens in a new tab)WANT MORE? / GO HANDS-ON
Your own tunnel.
Your next skill.
Ready to get comfortable with the terminal? Start with the Linux foundations behind a self-hosted setup.
Explore Linux on Boot.dev (opens in a new tab)External learning platform · Paid membership available. Check course access and current pricing on Boot.dev. How learning links work.
Lesson source references checked 7 November 2026. Conceptual explanations and original diagrams; no independent connection/security test. External learning links currently have no affiliate tracking. Learning disclosure.