Behåll privata rutter och släpp omdirigeringen: OpenVPN delad tunnel
En tunnel bara för privata nätverk kräver två regler: privata prefix går genom den, vanligt surfande behåller sin lokala väg. Att ta bort en standardrutt är inte en policy.
Tunneln kommer upp, programmet laddas och sedan börjar allt annat på laptopen bete sig underligt. Det är den vanliga formen av en policy bara för privata nätverk som genomförts genom att ta bort en rad. Att ta bort en pushad standardrutt ändrar visserligen vart trafiken går, men den säger inte vart trafiken borde gå i stället, och den rör inte namnmatchningen alls. En policy behöver två positiva halvor innan den kan testas.
Att ta bort omdirigeringen är bara halva ändringen
En omdirigering av hela tunneln och en policy bara för privata nätverk skiljer sig i vad de hävdar om världen. Omdirigeringen gör anspråk på varje destination, medan den privata policyn gör anspråk på en lista och lämnar resten ifred. Att ta bort anspråket utan att skriva listan ger en klient som inte når något utanför LAN-et, vilket ser ut som ett routingfel snarare än en lucka i policyn. Skriv listan innan du tar bort anspråket, och då spelar ordningen på de två stegen ingen roll längre.
Båda halvorna är krav och inte standardvärden. Privata prefix måste in i tunneln, och vanliga destinationer måste behålla den väg de hade före anslutningen.
Om en organisation kräver full tunnel gäller inget av detta. Designen bara för privata nätverk hör till driftsättningar där delad routing är godkänd.
pull-filter är en träff, inte en strömbrytare
Direktivet pull-filter tar bort pushade alternativ vars namn matchar ett prefix, och det är allt det gör. Att ignorera omdirigeringen låter varje annat pushat alternativ ligga kvar, vilket oftast är det du vill: rutter, DNS-inställningar och värdet för rutt-gateway kommer fortfarande fram. Det kan inte heller ta bort ett direktiv som står i den lokala profilen, eftersom filtreringen gäller det servern pushar.
Motstå frestelsen att ignorera varje alternativ som börjar med route. Det mönstret kastar också bort de privata rutter som anslutningen behöver, och det kan tappa gateway-information som tunneln är beroende av.
route-nopull är ett bredare beslut än det ser ut. Det hindrar klienten från att acceptera pushade rutter och DHCP-liknande alternativ som en grupp, vilket är en annan policy än att filtrera bort ett enskilt alternativ.
Skriv ruttlistan från programmet och utåt
Börja med det användaren faktiskt öppnar och lägg sedan till stöddelarna. Ett program på 10.60.20.15 innebär sitt subnät 10.60.0.0/16, och ett privat namn innebär den resolver som svarar på det. En användare som bad om ett program behöver därför två destinationer och ett DNS-beslut. Allt bortom den listan ligger utanför omfånget av konstruktion, och det är det som håller policyn granskningsbar.
På en samarbetande server blir de två pushade rutter, och ingen av dem är en omdirigering. Behåll tunnelns topologi och värdena för rutt-gateway som den befintliga tjänsten levererar.
När bara vissa användare behöver den här policyn, tillämpa den per klient eller per grupp. Att ändra allas routing för att fixa ett teams krav är sättet en delad tunnel blir ett avbrott.
| Destination | Intended path |
|---|---|
10.60.0.0/16 | Tunnel, for the approved application services |
10.61.0.53/32 | Tunnel, to reach the internal resolver |
corp.example queries | Internal resolver, selected per namespace |
| Everything else | Local path and local resolver |
Låt DNS följa samma väg
En rutt till resolvern är inte en resolverpolicy. På en systemd-resolved-klient är det semantiska resultatet en routingdomän för det privata namnutrymmet som pekar på den interna resolvern, och det är det som gör att bara de namnen använder den. En Windows-klient behöver i stället sin egen mekanism för namnutrymmespolicy. En DNS-serverrad i profilen installerar inget av detta av sig själv.
Kontrollera vad operativsystemet valde i stället för vad profilen bad om. På Linux visar resolvectl status domänen och servern per anslutning; på Windows är namnutrymmespolicytabellen det motsvarande beviset.
Håll resolvern nåbar genom tunneln, annars pekar policyn på en adress som inte kan frågas. En resolveradress som tunneln inte når gör en fungerande policy till en timeout.
Verifiera båda halvorna vid en återanslutning
Anslut klienten igen efter ändringen och granska den effektiva rutten till en privat och till en offentlig adress. Slå sedan upp ett privat namn och ett offentligt namn och bekräfta att var och en använde den avsedda resolvern. Att en offentlig webbplats laddas bevisar bara den andra halvan, och det är den halvan som oftast fungerar av en slump.
Anteckna den färdiga policyn i en mening: dessa prefix och namn använder den här anslutningen, allt annat följer den lokala vägen. Håll den sedan i profilen i stället för att reparera adapterinställningar efter varje inloggning.