Lesson 4: Network Services and SOHO Design Lab

A network diagram that stops at the router is incomplete.

Users do not come to school or work because they enjoy having an IP address.

They need services: names to resolve, files to open, printers to print, accounts to authenticate, applications to respond, clocks to agree, mail to move, and remote users to connect safely.

Those services depend on the network, but they also depend on one another.

Today we build that dependency map.

Start with a fictional training center

The environment contains:

• 24 wireless student laptops;
• 4 wired staff desktops;
• a shared network printer;
• separate staff and guest networks;
• a local file share;
• centralized authentication, authorization, and accounting in the supplied scenario;
• a web application with a database behind it;
• centralized logging;
• time synchronization;
• mail protected by a spam gateway;
• remote staff VPN access.

Nothing here requires touching a real school network.

Use only the supplied or simulated system.

The user sees one service; the system may contain several

Suppose the user opens:

https://portal.training.test

A simplified dependency chain might be:

client IP configuration
        ↓
DNS resolves portal.training.test
        ↓
TCP/HTTPS path to web service
        ↓
web service
        ↓
authentication / authorization
        ↓
database query
        ↓
response to client

If the page fails, which layer is broken?

You do not know yet.

That is why a useful architecture shows dependencies instead of drawing one cloud labeled "server."

DNS gives names to services

Our fictional network needs several record types:

A     portal.training.test  → 192.0.2.40
AAAA  portal6.training.test → 2001:db8::40
CNAME files.training.test   → storage.training.test
MX    training.test         → mail.training.test
TXT   training.test         → supplied policy/verification text

The exact values are fictional.

The important part is choosing the record type that matches the relationship.

DHCP gives clients local configuration

The student network may use a scope such as:

subnet: 192.168.50.0/24
pool:   192.168.50.100-220
gateway: 192.168.50.1
DNS:    192.168.50.10

A network printer may receive a predictable address through reservation.

A few addresses may be excluded for managed infrastructure.

If the scope is exhausted, new clients can fail while existing leased clients continue working.

That symptom is much more specific than "Wi-Fi is random today."

File and print services sit above reachability

A file share depends on:

• reachable server;
• expected file-sharing service;
• valid name and path;
• authentication and permissions;
• storage availability.

A print server or shared queue depends on:

• printer path;
• queue or service state;
• driver configuration;
• permissions;
• network reachability.

A reachable server does not prove the share or queue works.

AAA separates identity decisions

AAA commonly stands for:

• authentication;
• authorization;
• accounting.

Authentication asks who the user or device is according to the system.

Authorization asks what that identity is allowed to do.

Accounting records activity or usage information according to the design.

A user can authenticate successfully and still be denied because authorization policy says no.

That is not an authentication failure.

NTP keeps clocks aligned enough for systems to agree about time

Network Time Protocol, or NTP, helps systems synchronize clocks.

Time affects:

• logs;
• authentication systems;
• certificates;
• troubleshooting timelines;
• scheduled tasks;
• distributed applications.

If one server is twelve minutes wrong, events from several systems may appear out of order even when the underlying actions happened normally.

Clock state is part of evidence quality.

Syslog centralizes event records

A syslog-style service can collect records from network and system devices.

Central logging helps technicians correlate events, but a log server does not create truth automatically.

You still need to know which device produced the record, which clock it used, whether the message reached the collector, and whether the relevant event was logged at all.

A missing log can mean "nothing happened" or "the logging path failed."

Those are very different explanations.

Web and database roles are separate

A web application may depend on a database server.

browser
  ↓ HTTPS
web server / application
  ↓ database connection
database server

If the web server responds with an application error because the database is unavailable, TCP/443 to the web server can still be perfectly healthy.

Lower-layer success does not prove the final service.

Mail and spam filtering add more dependencies

A mail environment can include:

internet / sender
      ↓
spam gateway
      ↓
mail server
      ↓
mailbox / client access

DNS MX records help identify mail destinations, while TXT records can carry policy or verification data used by SPF, DKIM, and DMARC-related workflows.

A mail problem can therefore involve DNS, gateway filtering, mail-server state, mailbox access, or client configuration.

Proxy, UTM, and load balancer change the visible path

Proxy

A proxy acts as an intermediary according to its design.

If one web path is blocked while general connectivity remains healthy, proxy configuration may become relevant.

UTM

A unified threat management appliance combines multiple network and security functions in one platform.

Do not let one physical box hide the logical functions it performs.

Load balancer

A load balancer distributes traffic across backend services according to configuration.

A client may reach the load balancer successfully while one backend is unhealthy.

The visible endpoint is not always the final server doing the work.

IoT and SCADA are categories, not permission slips

You should recognize IoT endpoints and SCADA or operational-system categories because technicians encounter them in real environments.

That does not mean you should probe them.

Operational and embedded systems can have strict availability and safety requirements.

In this course, use only the fictional architecture provided.

Build the architecture

Create a service map containing:

• DHCP;
• DNS;
• default gateway and NAT;
• staff VLAN;
• guest VLAN;
• VPN;
• file share;
• print server;
• mail server;
• spam gateway;
• syslog;
• web service;
• AAA;
• database;
• NTP;
• proxy;
• UTM;
• load balancer;
• one IoT endpoint;
• SCADA as a recognition-only external category.

Do not draw every device as an isolated box.

Draw the dependencies.

Fault injections

Use at least three:

DHCP scope exhausted

Existing clients work. New clients associate to Wi-Fi but fail to receive expected addresses.

Wrong DNS record

The portal server IP is reachable, but the hostname resolves to the wrong address.

NTP unavailable

Connectivity is healthy, but clocks drift and logs become difficult to correlate.

AP uplink disconnected

SSID is visible and signal is strong, but clients cannot reach DHCP or the gateway through that AP.

Proxy blocks one path

Other sites work, DNS works, and remote IP connectivity works, but a supplied proxy rule blocks one approved destination.

Build a service-dependency record

For three injected faults, document:

user-visible symptom
lower layers already proven
service / configuration involved
first failed or uncertain boundary
next evidence
correction
retest
what the retest does NOT prove

Fixing DNS does not prove the database is healthy. Restoring DHCP does not prove the VPN works. Reconnecting an AP uplink does not prove every application service is available.

Before you move on

A useful service map should let you answer:

Which dependency could fail while everything below it remains healthy?

Next we use that question against several users who all report some version of "the network is broken."