VPN-regler på routern: matcha källan och målet

Routershopping-sidor visar VPN-routing som en enda kryssruta, och den formuleringen döljer tre olika frågor. Matchar regeln enheten som skickar trafiken, servern som tar emot den, eller båda? Vad händer med trafik som inte matchar någon av dem? Och när två regler överlappar, vilken vinner? Att skriva svaret som ett par av källa och mål gör en vag funktionslista till en testbar design.

Funktionsnamnet döljer två ändar

En mediespelare som ska använda tunneln är en källmatchning. Ett privat kontorsprefix som ska vara nåbart genom tunneln är en målmatchning. En arbetsstation som bara ska använda tunneln för en tjänst är båda, och det snittet är fallet som de flesta konsumentfastvaror hanterar dåligt.

Skriv kravet som ett par innan du jämför produkter. Det paret är det du ska testa senare.

En produkt som erbjuder en enhetslista eller en global mållista uttrycker kanske inte ”bara den här enheten, bara de här målen”. Skillnaden är inte kosmetisk: en global målregel skickar all trafik från varje enhet till den webbplatsen genom tunneln, och en enhetsregel skickar all trafik från den enheten. Ingen av dem är kravet. Testa det fallet med två enheter innan du litar på skärmen.

Bygg regeln som ett snitt

En tabell håller designen ärlig. Sätt scenariot till vänster och namnge sedan avsändarmatchning och målmatchning var för sig:

Den tredje raden är den intressanta, eftersom den behöver båda halvorna samtidigt. Om firmware bara kan uttrycka en axel måste kravet delas i två regler eller flyttas till en enhet som kan det.

Håll källidentiteten stabil. En DHCP-reservation, ett dedikerat segment eller en enhetsidentitetsmekanism fungerar, men en adress som ändras när leasingavtalet löper ut gör det inte. Ta med IPv6, eftersom en IPv4-adress inte identifierar all trafik från en enhet.

Prioriteten avgör överlappningen

Överlappande regler är normalt. En bred enhetsregel och en smal målregel kan båda beskriva ett och samma flöde, och den dokumenterade prioritetsordningen avgör vilken som vinner. En tilltalande inställningsskärm berättar inte den ordningen.

Läs handboken för ordningen och för fallet utan matchning, och testa sedan båda med trafik du kan observera:

ip rule show
ip route get 203.0.113.10

Om dokumentationen inte anger ordningen, anta att den smalare regeln kanske inte vinner och designa runt det. Två regler som inte kan hamna i konflikt är lättare att stödja än en enda smart regel med odokumenterad företräde.

Namn behöver en uppdateringspolicy

Ett mål som skrivs som en domän lägger till ett underhållsproblem. Routern måste lösa upp det, uppdatera mappningen, hantera flera adresser och underdomäner och klara applikations-DNS som kringgår den förväntade resolvern.

Att kopiera ett sökresultat till en IP-regel är en ögonblicksbild, inte en domänpolicy.

Bestäm hur gammalt ett svar får vara innan regeln är fel, och vad routern gör när uppslagningen misslyckas. En regel som behåller den senast kända adressen kan överleva en tjänstemigrering; en regel som släpper posten kan tyst stoppa tunnlingen. Båda beteendena är acceptabla om de skrivs ned bredvid regeln.

Definiera det otillgängliga tillståndet

En routinginställning tvingar inte trafik att bara gå via VPN. När tunneln är nere kan routern blockera flödet, skicka det direkt eller använda en annan tunnel, och varje val har en annan felsignatur.

Bestäm vilken kravet behöver och verifiera det sedan genom att stoppa tunneln och följa flödet:

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10

Trafik som uppstår från routern själv är ett eget område. DNS-vidarebefordran, uppdateringskontroller och övervakning kan starta nya flöden från routern själv i stället för att ärva enhetens källmatchning. Ta uttryckligen hänsyn till dessa flöden, annars visas de som oförklarade läckor i loggarna.