Opdelte L2TP-ruter på Mac: hvorfor en værtsadresse ikke virker

VPN'et forbinder, menulinjen viser det, og en intern vært svarer stadig ikke. I den situation er der tre mulige årsager, og hvilken der gælder afhænger af, hvordan tunnelen blev konfigureret. Enten brugte rute-kommandoen en værtsadresse, hvor en netværksadresse var påkrævet, eller profilen selv installerer en standardrute, der sluger beslutningen, eller klienten er en PPP-tunnel, der har brug for et hook i stedet for en profilenøgle. Tjek dem i den rækkefølge, fordi den første er billigst at udelukke.

Destinationen er en netværksadresse, masken beskriver præfikset

networksetup -setadditionalroutes tager tripler af destination, subnettmaske og gateway. Det kald, der sender et internt subnet gennem tunnelen, ser sådan ud:

sudo networksetup -setadditionalroutes "VPN (L2TP)" 192.168.1.0 255.255.255.0 10.2.0.0

Læg mærke til, hvad destinationen er: netværksadressen, ikke adressen på den server, du prøver at nå. I det tilfælde, der gav anledning til denne artikel, gjorde den identiske kommando med 192.168.1.20 på den plads intet nyttigt, og at erstatte den med 192.168.1.0 virkede med det samme. Samme maske, samme gateway, ét anderledes tal. Det er hele fejlen i miniature.

Årsagen er aritmetik, ikke politik. En værtsadresse parret med en /24-maske beskriver ikke 192.168.1.0/24; den beskriver noget, som rutetabellen ikke kan holde nyttigt, så posten afvises eller ignoreres, og tunnelen ender med at bære mindre, end du havde tænkt.

Når du vil have præcis én vært, skal du bruge værtsadressen med en maske på 255.255.255.255. Blandede par er, hvor det går galt, ikke brugen af en værtsadresse som sådan. En /32 bygget af én adresse er en legitim rute; en /24 bygget af én adresse er en fejl.

Kaldet erstatter listen, og navnet er bogstaveligt

To adfærdsmønstre overrasker folk første gang. Kommandoen sætter hele listen over ekstra ruter i stedet for at tilføje, så et kald, der tilføjer ét præfiks, fjerner stille de andre, der var der før. Byg hele sættet i ét kald.

Tjenestenavnet er heller ikke den etiket, du opfandt. Læs det fra værktøjet, og kopiér det præcist, inklusive type-suffikset:

networksetup -listallnetworkservices

Et navn, der afviger med ét tegn, giver ingen fejl, der er værd at læse, og ingen rute. Kopier og indsæt er den rigtige teknik her, ikke at skrive igen fra hukommelsen.

Når profilen gør krav på standardruten

Opdelte ruter taber til en standardrute for enhver destination, de ikke udtrykkeligt dækker, og en L2TP-profil konfigureret til fuld tunnel installerer præcis det. Hvis profilen siger, at alt går gennem tunnelen, ændrer listen over ekstra ruter sig meget lidt. Din post er ikke forkert; den er simpelthen irrelevant for de destinationer, den aldrig nævner. Kontrollen for dette sidder normalt i profilens indstilling for at sende al trafik snarere end i nogen rute-kommando.

Beslut, hvilken model du faktisk vil have, før du redigerer flere poster. Fuld tunnel med undtagelser er en anden konfiguration end opdelt tunnel med bestemte præfikser, og blander man de to, får man en tabel, som ingen kan forudsige.

Hvis organisationen kræver fuld tunnel, så stop med at prøve at opdele den lokalt og tag kravet til den, der ejer politikken. En lokalt tilføjet rute, der modsiger det, bliver alligevel fjernet ved den næste profilopdatering.

PPP-tunneler har brug for et hook i stedet for en nøgle

For PPP-baserede tunneler er defaultroute den profilenøgle, der opretter en standardrute; fjern den, og klienten holder op med at gøre krav på hver destination. Ruter tilføjes derefter, når grænsefladen dukker op, typisk fra /etc/ppp/ip-up:

#!/bin/sh
/sbin/route add -net 192.168.1.0 -interface ppp0

Hold scriptet ejet af root og eksekverbart, og tilføj en vagt på grænsefladenavnet, når der findes mere end én tunnelprofil på maskinen. Et hook, der kører for hvert PPP-link og antager ét enhedsnavn, er en lille fejl med et langt liv.

Verificér opdelingen med tre forespørgsler

Tag tabellen, mens du er forbundet, og notér, hvilken grænseflade der betjener tunnelen. Tjek derefter den konkrete destination i stedet for at stole på exit-status for den kommando, der oprettede den. En exitkode fortæller, om værktøjet accepterede argumenterne, ikke om trafikken tager den vej, du havde tænkt.

Slut af med tre forespørgsler, der beviser opdelingen: én intern vært via adresse, ét internt navn via den interne resolver og ét offentligt websted, der stadig skal bruge den lokale forbindelse. Hvis det offentlige websted nu også rejser gennem tunnelen, skete opdelingen aldrig, uanset hvad rutelisten ser ud til at sige.

Genopret forbindelsen endnu en gang, og gentag den interne forespørgsel, fordi ruter, der tilføjes manuelt, kan overleve den grænseflade, der gjorde dem gyldige og stille gøre trafikken til et sort hul, efter at tunnelen falder.