Practical IT & network guides

1. Create the VLAN and give it a name.
2. Set each user port to access mode in that VLAN.
3. Allow the VLAN on the uplink trunk, and make sure the other end allows it too.
4. Verify with the show commands and test with a ping inside the VLAN.

vlan 20
 name Staff
!
interface gi1/0/10
 switchport mode access
 switchport access vlan 20
 spanning-tree portfast
!
interface gi1/0/48
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30
!
show vlan brief
show interfaces trunk

1. Physical layer: check cables, SFPs and interface error counters (CRC, drops, duplex mismatch).
2. Layer 2: look for loops or STP changes, MAC flapping and port-channel problems.
3. Layer 3: ping and traceroute to the gateway, the next hop and the destination; check the routing table.
4. Name resolution: test DNS separately from connectivity.
5. Load: find the top talkers on the firewall or switch and check for saturated links.
6. Wi-Fi: check channel overlap, signal strength and roaming behaviour.
7. Capture traffic with Wireshark when the cause is still unclear, and note what changed recently.

1. Phase 1: IKE version, encryption, authentication, DH group and pre-shared key must match on both firewalls.
2. Phase 2: the local and remote subnets (selectors) must mirror each other.
3. Add static routes to the remote subnet through the tunnel interface.
4. Add firewall policies in both directions, with NAT disabled for tunnel traffic.
5. If one side is behind NAT, keep NAT traversal enabled.
6. Check the tunnel state and debug the negotiation only when needed.

diagnose vpn ike gateway list
diagnose vpn tunnel list

# negotiation debug (turn off afterwards)
diagnose debug application ike -1
diagnose debug enable
diagnose debug disable

1. Check system health and resource usage.
2. Review the routing table and active sessions.
3. Capture packets for one host straight on the firewall, then stop with Ctrl+C.

get system status
get system performance status
diagnose sys top
get router info routing-table all

# sniffer: interface, filter, verbosity, count, time
diagnose sniffer packet any 'host 10.0.0.5' 4 0 l

1. Allow only what is needed (least privilege) and end with an explicit deny that logs.
2. Use address and service objects with clear names, and add a comment to every rule.
3. Keep specific rules above general ones and avoid overlapping rules.
4. Log the rules that matter and review hit counts to remove unused rules.
5. Control changes: record who changed what, why and when, and keep a rollback config.

1. Force an update on the client and read the result.
2. Check which GPOs were applied or denied for the user and computer.
3. Confirm the GPO is linked to the correct OU, enabled, and that security filtering includes the user or computer.
4. Check the client uses the domain controller for DNS and that its time is in sync.
5. Check domain controller replication if the policy exists on one DC but not another.

gpupdate /force
gpresult /r
gpresult /h report.html

dcdiag /v
repadmin /replsummary

1. Run the built-in diagnostics on each domain controller.
2. Check replication status and look for failures or large delays.
3. Confirm which servers hold the FSMO roles.
4. Verify DNS: the SRV records exist and every DC resolves the domain correctly.
5. Check SYSVOL and NETLOGON are shared and that the time source is correct.

dcdiag /v
repadmin /showrepl
netdom query fsmo
nltest /dsgetdc:yourdomain.local

1. Run a delta sync on the Entra Connect server and review the result.
2. Make sure the UPN suffix is a verified domain in Microsoft 365.
3. Look for duplicate attributes and invalid characters in synced objects.
4. Confirm password hash sync is enabled and healthy.
5. Check the user is inside an OU that is selected for synchronization.

Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta

1. Download a template for the OS you want from the storage template list.
2. Create the container with a fixed IP, an unprivileged setting and enough disk for the service.
3. Install the service, then take a snapshot before every big change.
4. Schedule backups and test a restore at least once.

pveam update
pveam available --section system
pveam download local debian-12-standard_12.7-1_amd64.tar.zst

# backup one container
vzdump 101 --storage local --mode snapshot

1. Snapshot before upgrades or config changes and delete old snapshots afterwards.
2. Schedule vzdump backups to a different disk or machine than the guests.
3. Keep a few daily and weekly copies, not only the latest one.
4. Test restoring a backup regularly; an untested backup is a guess.
5. Monitor free space on the backup storage.

1. Install cloudflared on the server that runs the service.
2. Log in, create a tunnel and route a hostname to it.
3. Point the ingress rule at the local service (for example http://localhost:80).
4. Run cloudflared as a system service so it starts after a reboot.
5. Optionally protect the hostname with Cloudflare Access.

cloudflared tunnel login
cloudflared tunnel create my-tunnel
cloudflared tunnel route dns my-tunnel app.example.com

# config.yml
tunnel: my-tunnel
ingress:
  - hostname: app.example.com
    service: http://localhost:80
  - service: http_status:404

sudo cloudflared service install

1. A record for the mail hostname (for example mail.example.com) pointing to the server IP.
2. MX record for the domain pointing to that hostname.
3. SPF TXT record listing the server as an allowed sender.
4. DKIM TXT record using the key generated in the Mailcow admin panel.
5. DMARC TXT record, starting with a monitoring policy.
6. Reverse DNS (PTR) for the server IP, set with the IP provider, matching the mail hostname.
7. Make sure the required mail ports are reachable, then test with a mail-testing tool.

example.com.        MX   10 mail.example.com.
example.com.        TXT  "v=spf1 mx -all"
_dmarc.example.com. TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

1. Add the Wazuh repository on the server.
2. Install the agent with the manager address set.
3. Enable and start the service.
4. Check the agent shows as active in the Wazuh dashboard and review its first alerts.

WAZUH_MANAGER="10.0.0.10" apt-get install wazuh-agent
systemctl daemon-reload
systemctl enable --now wazuh-agent

1. Use SSH keys, disable password login and disable direct root login.
2. Allow only the ports you need in the host firewall.
3. Install automatic security updates.
4. Use sudo with least privilege and remove unused accounts.
5. Add brute-force protection such as fail2ban.
6. Send logs and alerts to a monitoring system and review them.

# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no

ufw default deny incoming
ufw allow 22/tcp
ufw enable

1. Give the agent read-only access first and add write access only where needed.
2. Require human approval for sensitive or destructive actions.
3. Keep secrets in environment files or a vault, never inside prompts or code.
4. Log every action and send critical alerts to a channel you actually watch.
5. Add rate limits and clear stop conditions so a mistake cannot repeat endlessly.
6. Keep sensitive data inside your own network when you can, for example with a local model.

1. Get the exact symptom, who is affected, when it started and what changed.
2. Reproduce the problem or confirm it from logs.
3. Narrow the scope: one user, one location or everyone.
4. Test the simple causes first, then work toward the complex ones.
5. Change one thing at a time and note the result.
6. Confirm the fix with the user and document the cause and steps.
7. Escalate with evidence: what you tested, the results and the logs.

1. Summary: what happened in one or two sentences.
2. Impact: who and what was affected and for how long.
3. Timeline: key events with times.
4. Root cause: the underlying reason, not only the symptom.
5. Resolution: what restored service.
6. Prevention: the follow-up actions with owners and dates.