Hvorfor route-nopull alene gør fileserveren utilgængelig
At ignorere pushede ruter er kun halvdelen af en split tunnel. Vælg ruteejeren, tilføj kontorets præfiks manuelt, og test tre flows, før du kalder det løst.
Fileserveren åbner fint, og videoopkaldet i næste vindue begynder at hakke. Intet er langsomt, og ingen MTU er forkert: din klient tog den ruteliste, serveren gav den, så hver pakke forlader nu kontorets firewall. Løsningen er ikke endnu et tuning-flag, men en beslutning om, hvem der ejer klientens rutetabel. Den beslutning hører til ét sted, og fejlmønstrene nedenfor fortæller dig, hvilket sted du faktisk valgte.
Beslut hvem der ejer rutetabellen
Tre ejere er mulige. Serveren kan pushe ruter og en standardgateway, og så installerer klienten, hvad den får at vide, og bliver en fuld tunnel. Klientprofilen kan overtage ejerskabet ved at kassere pushes og bære sine egne rutelinjer. En forbindelsesmanager på skrivebordet kan også eje beslutningen gennem sine egne rute- og standardruteegenskaber.
Hvert valg fejler på sin egen måde, og derfor er tabellen værd at læse, før du redigerer en profil. Den række, der passer til dit symptom, er den ejer, 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 |
Vælg én og skriv den ned. At blande to efterlader en vært, hvis standardsti modsiger sin egen dokumentation, og den næste ingeniør kan ikke se, hvilket lag der vandt. Slet taberen eksplicit.
route-nopull filtrerer pushes, det tilføjer ikke ruter
route-nopull hører til i klientprofilen, og dens rækkefølge i den fil er ligegyldig, fordi den kun kasserer værdier, der kommer fra serveren. Den kasserer pushede ruter, inklusive en pushet standardrute, mens tunnelen stadig kommer op normalt.
Den konsekvens, folk overser, er at pushede DHCP-indstillinger følger med. DNS-indstillinger sendt af serveren kasseres også, så interne navne holder op med at slå op, selv om tunnelen er sund, og serveren kan nås på adressen.
Det efterlader en tunnel uden sti til kontorets præfiks, medmindre du selv tilføjer en: route-nopull efterfulgt af route 10.30.0.0 255.255.0.0 i samme profil. Den linje bærer en adresse og en maske; den navngiver ikke et næste hop.
En alternativ form tilføjer et gateway-token, route 10.30.0.0 255.255.0.0 vpn_gateway, som peger posten mod tunnelen ved navn. Importører er forskellige med hensyn til, om de oversætter den variant, så undersøg den gemte forbindelse, hvis posten mangler i kernetabellen.
Verificer med ruteopslag, ikke med en ping
En ping fortæller dig, at noget svarede. Et ruteopslag fortæller dig, hvilken grænseflade kernen ville vælge, og det er det spørgsmål, du faktisk stillede. Fire korte kommandoer skiller en manglende rute fra en rute, der peger på den forkerte enhed.
Læs, hvad tunnelen installerede med ip route show dev tun0. Ingen output overhovedet betyder nul ruter, hvilket ikke er en split tunnel, der virker, og det er det sædvanlige resultat af at tilføje filteret uden den eksplicitte linje.
Tjek derefter en kontoradresse med ip route get 10.30.5.7, og en almindelig internetadresse med ip route get 1.1.1.1. Den anden skal navngive den fysiske grænseflade; hvis den navngiver tunnelen, blev pushet slet ikke filtreret.
Læs til sidst ip rule, fordi en politikregel efterladt af et tidligere forsøg kan tilsidesætte den tabel, du lige har rettet. En korrekt profil med en forældet regel ovenpå ser præcis ud som en ødelagt profil. Slet den regel, du tilføjede sidst, før du tilføjer en ny.
Overlappende subnets ser ud som en ødelagt tunnel
To private områder kan være identiske fra klientens synspunkt, og det er der, en split tunnel får skylden for noget, den ikke forårsagede. Hvis kontoret uddeler det samme præfiks, som din hjemmerouter bruger, dækker tunnelruten routeren, og hjemmenetværket ser ud til at forsvinde.
Sammenlign adressen på din egen grænseflade med den rute, profilen installerer, ved at bruge en almindelig adresseliste, før du ændrer noget. Overlapningen er reel, og ingen profilindstilling løser den. Det, du kan rette, er navngivningen, så den næste person ser to områder i stedet for ét.
De ærlige løsninger er at omnummerere den ene side eller oversætte adresser på kontoret. At fastgøre en enkelt værtsrute til routeren virker, indtil routeradressen ændres, og så bliver det et andet mysterium oven på det første.
Lad beslutningen overleve en genopkobling
Poster skrevet i hånden overlever ikke en genopkobling, og en forbindelsesmanager genopbygger tabellen, hver gang profilen starter. Læg beslutningen der, hvor forbindelsen oprettes, hvad enten det er profilen eller managerens gemte indstillinger. Genstart derefter forbindelsen én gang med vilje i stedet for at opdage adfærden under et opkald. En profil, der kun virker indtil næste genopkobling, er ikke færdig.
Prøv tre stier på én gang: en kontorvært på den bogstavelige adresse, samme vært på navn, og et almindeligt offentligt websted. Den midterste afhænger af den navnetjeneste, du konfigurerede, efter at du droppede de pushede DNS-indstillinger, og det er den, der stille fejler.