Behold private ruter og dropp omdirigeringen: OpenVPN delt tunnel
En tunnel kun for private nettverk trenger to regler: private prefikser går gjennom den, vanlig surfing beholder sin lokale vei. Å slette en standardrute er ikke en policy.
Tunnelen kommer opp, programmet lastes, og så begynner alt annet på laptopen å oppføre seg merkelig. Det er den vanlige formen for en policy kun for private nettverk, implementert ved å slette én linje. Å fjerne en pushet standardrute endrer riktignok hvor trafikken går, men den sier ikke hvor trafikken skal gå i stedet, og den berører ikke navneoppslag i det hele tatt. En policy trenger to positive halvdeler før den kan testes.
Å slette omdirigeringen er bare halve endringen
En omdirigering av hele tunnelen og en policy kun for private nettverk skiller seg i hva de hevder om verden. Omdirigeringen gjør krav på hver destinasjon, mens den private policyen gjør krav på en liste og lar resten være i fred. Å slette kravet uten å skrive listen gir en klient som ikke når noe utenfor LAN-et, noe som ser ut som en rute feil snarere enn et hull i policyen. Skriv listen før du fjerner kravet, og rekkefølgen av de to trinnene slutter å bety noe.
Begge halvdelene er krav og ikke standardverdier. Private prefikser må inn i tunnelen, og vanlige destinasjoner må beholde veien de hadde før tilkoblingen.
Hvis en organisasjon pålegger full tunnel, gjelder ingenting av dette. Designet kun for private nettverk hører til utrullinger der delt ruting er godkjent.
pull-filter er et treff, ikke en bryter
Direktivet pull-filter fjerner pushede alternativer hvis navn samsvarer med et prefiks, og det er alt det gjør. Å ignorere omdirigeringen lar hvert annet pushet alternativ bli stående, noe som vanligvis er det du vil: ruter, DNS-innstillinger og verdien for rute-gateway kommer fortsatt frem. Det kan heller ikke fjerne et direktiv som er skrevet i den lokale profilen, fordi filtrering gjelder det serveren pusher.
Motstå fristelsen til å ignorere hvert alternativ som begynner med route. Det mønsteret kaster også de private rutene tilkoblingen trenger, og det kan miste gateway-informasjon som tunnelen er avhengig av.
route-nopull er en bredere beslutning enn den ser ut som. Den hindrer klienten i å godta pushede ruter og DHCP-lignende alternativer som en gruppe, noe som er en annen policy enn å filtrere bort ett alternativ.
Skriv rutilisten fra programmet og utover
Begynn med det brukeren faktisk åpner, og legg så til støttedelene. Et program på 10.60.20.15 innebærer subnettet 10.60.0.0/16, og et privat navn innebærer resolveren som svarer på det. En bruker som ba om ett program trenger derfor to destinasjoner og én DNS-beslutning. Alt utenfor den listen er utenfor omfanget av konstruksjon, og det er det som holder policyen gjennomgåelig.
På en samarbeidende server blir de to pushede ruter, og ingen av dem er en omdirigering. Behold tunnel-topologien og verdiene for rute-gateway som den eksisterende tjenesten leverer.
Når bare noen brukere trenger denne policyen, bruk den per klient eller per gruppe. Å endre rutingen til alle for å fikse kravet til ett team er måten en delt tunnel blir et avbrudd.
| 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 |
La DNS følge samme vei
En rute til resolveren er ikke en resolver-policy. På en systemd-resolved-klient er det semantiske resultatet et rutingsdomene for det private navnerommet som peker på den interne resolveren, og det er det som gjør at bare disse navnene bruker den. En Windows-klient trenger i stedet sin egen mekanisme for navneromspolicy. En DNS-serverlinje i profilen installerer ingen av delene av seg selv.
Kontroller hva operativsystemet valgte i stedet for hva profilen ba om. På Linux viser resolvectl status domenet og serveren per kobling; på Windows er navneromspolicy-tabellen det tilsvarende beviset.
Hold resolveren tilgjengelig gjennom tunnelen, ellers peker policyen på en adresse som ikke kan spørres. En resolveradresse som tunnelen ikke når, gjør en fungerende policy til en tidsavbrudd.
Verifiser begge halvdelene ved en gjentilkobling
Koble klienten til igjen etter endringen og undersøk den effektive ruten til en privat og til en offentlig adresse. Slå deretter opp et privat navn og et offentlig navn og bekreft at hver av dem brukte den tiltenkte resolveren. At et offentlig nettsted lastes, beviser bare den andre halvdelen, og det er den halvdelen som vanligvis virker ved et uhell.
Noter den ferdige policyen i én setning: disse prefiksene og navnene bruker denne tilkoblingen, alt annet følger den lokale veien. Hold den deretter i profilen i stedet for å reparere adapterinnstillinger etter hver pålogging.