Hvorfor route-nopull alene gjør filserveren utilgjengelig
Å ignorere pushede ruter er bare halvparten av en delt tunnel. Velg ruteeieren, legg til kontorets prefiks manuelt, og test tre flyter før du kaller det løst.
Filserveren åpnes fint, og videoanropet i neste vindu begynner å hakke. Ingenting er tregt og ingen MTU er feil: klienten din tok imot rutenettverkslisten serveren ga den, så hver pakke går nå ut gjennom kontorets brannmur. Løsningen er ikke nok et justeringsflagg, men en beslutning om hvem som eier klientens rutetabell. Den beslutningen hører hjemme på ett sted, og feilmønstrene nedenfor forteller deg hvilket sted du faktisk valgte.
Bestem hvem som eier rutetabellen
Tre eiere er mulige. Serveren kan pushe ruter og en standard gateway, og da installerer klienten det den blir fortalt og blir en full tunnel. Klientprofilen kan ta eierskap ved å forkaste push og bære sine egne rutelinjer. En skrivebordstilkoblingsbehandler kan også eie beslutningen gjennom sine egne rute- og standardruteegenskaper.
Hvert valg feiler på sin egen måte, og derfor er det verdt å lese tabellen før du redigerer en profil. Raden som passer til symptomet ditt, er den eieren du faktisk har.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
Velg én og skriv den ned. Å blande to etterlater en vert der standardveien motsier sin egen dokumentasjon, og den neste ingeniøren kan ikke se hvilket lag som vant. Slett taperen eksplisitt.
route-nopull filtrerer push, det legger ikke til ruter
route-nopull hører hjemme i klientprofilen, og rekkefølgen i den filen er irrelevant fordi den bare forkaster verdier som kommer fra serveren. Den forkaster pushede ruter, inkludert en pushet standardrute, mens tunnelen fortsatt kommer opp normalt.
Konsekvensen folk overser, er at pushede DHCP-innstillinger blir med på lasset. DNS-innstillingene serveren sender, forkastes også, så interne navn slutter å slås opp selv om tunnelen er sunn og serveren er tilgjengelig på adressen.
Det etterlater en tunnel uten vei til kontorets prefiks med mindre du legger til en selv: route-nopull etterfulgt av route 10.30.0.0 255.255.0.0 i samme profil. Den linjen bærer en adresse og en maske; den navngir ikke et neste hopp.
En alternativ form legger til et gateway-token, route 10.30.0.0 255.255.0.0 vpn_gateway, som peker oppføringen mot tunnelen ved navn. Importører er ulike på om de oversetter den varianten, så undersøk den lagrede tilkoblingen hvis oppføringen mangler i kjernetabellen.
Verifiser med ruteoppslag, ikke med ping
En ping forteller deg at noe svarte. Et ruteoppslag forteller deg hvilket grensesnitt kjernen ville velge, og det er spørsmålet du faktisk stilte. Fire korte kommandoer skiller en manglende rute fra en rute som peker på feil enhet.
Les hva tunnelen installerte med ip route show dev tun0. Ingen utdata i det hele tatt betyr null ruter, som ikke er en delt tunnel som virker, og det er det vanlige resultatet av å legge til filteret uten den eksplisitte linjen.
Sjekk deretter én kontoradresse med ip route get 10.30.5.7, og én vanlig internettadresse med ip route get 1.1.1.1. Den andre skal navngi det fysiske grensesnittet; hvis den navngir tunnelen, ble pushet ikke filtrert i det hele tatt.
Til slutt, les ip rule, fordi en policyregel som en tidligere forsøk la igjen, kan overstyre tabellen du nettopp rettet. En korrekt profil med en utdatert regel på toppen ser nøyaktig ut som en ødelagt profil. Slett regelen du la til sist, før du legger til en ny.
Overlappende subnett ser ut som en ødelagt tunnel
To private områder kan være identiske fra klientens synspunkt, og det er der en delt tunnel får skylden for noe den ikke forårsaket. Hvis kontoret deler ut samme prefiks som hjemmeruteren din bruker, dekker tunnelruten ruteren, og hjemmenettverket ser ut til å forsvinne.
Sammenlign adressen på ditt eget grensesnitt med ruten profilen installerer, ved å bruke en vanlig adresseliste før du endrer noe. Overlappen er reell, og ingen profilinnstilling løser den. Det du kan rette, er navngivningen, slik at neste person ser to områder i stedet for ett.
De ærlige rettelsene er å omnummerere én side eller oversette adresser på kontoret. Å feste én enkelt vertsrute til ruteren virker til ruteradressen endres, og da blir det et andre mysterium oppå det første.
La beslutningen overleve en gjentilkobling
Oppføringer skrevet for hånd overlever ikke en gjentilkobling, og en tilkoblingsbehandler bygger tabellen på nytt hver gang profilen starter. Legg beslutningen der tilkoblingen opprettes, enten det er profilen eller behandlerens lagrede innstillinger. Start deretter tilkoblingen på nytt én gang med vilje i stedet for å oppdage atferden under en samtale. En profil som bare virker til neste gjentilkobling, er ikke ferdig.
Øv på tre veier samtidig: en kontorvert på den bokstavelige adressen, samme vert på navn, og et vanlig offentlig nettsted. Den midterste avhenger av navnetjenesten du konfigurerte etter at du droppet de pushede DNS-innstillingene, og det er den som stille feiler.