Mac L2TP-delte ruter: kvifor ei vertsadresse ikkje fungerer
setadditionalroutes vil ha nettverks- og maskepar, erstattar heile lista og krev det bokstavlege tenestenamnet. Sjekk tabellen før du gir gatewayen skulda.
VPN-et koplar til, menylinja viser det, og ein intern vert svarar framleis ikkje. I den situasjonen er det tre moglege årsaker, og kva for ei som gjeld kjem an på korleis tunnelen vart konfigurert. Anten brukte rute-kommandoen ei vertsadresse der ei nettverksadresse var påkravd, eller profilen sjølv installerer ei standardrute som slukar avgjerda, eller klienten er ein PPP-tunnel som treng ein hook i staden for ein profilnøkkel. Sjekk dei i den rekkjefølgja, fordi den første er billegast å utelukke.
Destinasjonen er ei nettverksadresse, maska skildrar prefikset
networksetup -setadditionalroutes tek triplar av destinasjon, subnettmaske og gateway. Kallet som sender eit internt subnett gjennom tunnelen ser slik ut:
sudo networksetup -setadditionalroutes "VPN (L2TP)" 192.168.1.0 255.255.255.0 10.2.0.0
Legg merke til kva destinasjonen er: nettverksadressa, ikkje adressa til tenaren du prøver å nå. I tilfellet som gav opphav til denne artikkelen, gjorde den identiske kommandoen med 192.168.1.20 på den plassen ingenting nyttig, og å byte han ut med 192.168.1.0 verka med det same. Same maske, same gateway, eitt anna tal. Det er heile feilen i miniatyr.
Årsaka er aritmetikk, ikkje policy. Ei vertsadresse saman med ei /24-maske skildrar ikkje 192.168.1.0/24; ho skildrar noko rutetabellen ikkje kan halde nyttig, så oppføringa blir avvist eller ignorert, og tunnelen ber til slutt mindre enn du hadde tenkt.
Når du vil ha nøyaktig éin vert, bruk vertsadressa med ei maske på 255.255.255.255. Blanda par er der dette går gale, ikkje bruken av ei vertsadresse som sådan. Ei /32 bygd av éi adresse er ei legitim rute; ei /24 bygd av éi adresse er ein feil.
Kallet erstattar lista, og namnet er bokstavleg
To åtferder overraskar folk på første forsøk. Kommandoen set heile lista over ekstra ruter i staden for å leggje til, så eit kall som legg til eitt prefiks fjernar stille dei andre som var der før. Bygg heile settet i eitt kall.
Tenestenamnet er heller ikkje etiketten du fann opp. Les det frå verktøyet og kopier det nøyaktig, inkludert type-suffikset:
networksetup -listallnetworkservices
Eit namn som avvik med eitt teikn gir ingen feil som er verdt å lese og inga rute. Kopier og lim inn er rett teknikk her, ikkje å skrive på nytt frå minnet.
Når profilen gjer krav på standardruta
Delte ruter taper mot ei standardrute for kvar destinasjon dei ikkje dekkjer eksplisitt, og ein L2TP-profil konfigurert for full tunnel installerere nettopp det. Viss profilen seier at alt går gjennom tunnelen, endrar lista over ekstra ruter seg svært lite. Oppføringa di er ikkje feil; ho er rett og slett irrelevant for destinasjonane ho aldri nemner. Kontrollen for dette sit vanlegvis i innstillinga til profilen for å sende all trafikk, ikkje i nokon rute-kommando.
Avgjer kva modell du faktisk vil ha før du redigerer fleire oppføringar. Full tunnel med unntak er ein annan konfigurasjon enn delt tunnel med bestemte prefiks, og å blande dei to gir ein tabell ingen kan føresjå.
Viss organisasjonen krev full tunnel, slutt å prøve å dele han lokalt og ta kravet til den som eig policyen. Ei lokalt lagd rute som motset det, blir uansett fjerna ved neste profiloppdatering.
PPP-tunnelar treng ein hook i staden for ein nøkkel
For PPP-baserte tunnelar er defaultroute profilnøkkelen som lagar ei standardrute; fjern han, og klienten sluttar å gjere krav på kvar destinasjon. Deretter blir ruter lagde til etter at grensesnittet dukkar opp, vanlegvis frå /etc/ppp/ip-up:
#!/bin/sh
/sbin/route add -net 192.168.1.0 -interface ppp0
Hald skriptet eigd av root og køyrbart, og legg til ei vakt på grensesnittnamnet når det finst meir enn éin tunnelprofil på maskina. Ein hook som køyrer for kvar PPP-kopling og tek for gjeve eitt einingnamn, er ein liten feil med eit langt liv.
Verifiser delinga med tre førespurnader
Ta opp tabellen medan du er tilkopla, og noter kva grensesnitt som tener tunnelen. Sjekk deretter den konkrete destinasjonen i staden for å stole på utgangsstatusen til kommandoen som oppretta han. Ein utgangskode fortel om verktøyet godtok argumenta, ikkje om trafikken tek vegen du hadde tenkt.
Avslutt med tre førespurnader som beviser delinga: éin intern vert etter adresse, eitt internt namn via den interne resolvertente og eitt offentleg nettstad som framleis skal bruke den lokale tilkoplinga. Viss det offentlege nettstaden no òg går gjennom tunnelen, skjedde delinga aldri, uansett kva rutelista ser ut til å seie.
Kopla til på nytt ein gong til og gjer den interne førespurnaden om att, fordi ruter som blir lagde til manuelt kan overleve grensesnittet som gjorde dei gyldige og stille gjere trafikken til eit svart hol etter at tunnelen fell.