Mac L2TP-delte ruter: hvorfor en vertsadresse ikke fungerer

VPN-et kobler til, menylinjen viser det, og en intern vert svarer fortsatt ikke. I den situasjonen er det tre mulige årsaker, og hvilken som gjelder avhenger av hvordan tunnelen ble konfigurert. Enten brukte rute-kommandoen en vertsadresse der en nettverksadresse var påkrevd, eller profilen selv installerer en standardrute som sluker avgjørelsen, eller klienten er en PPP-tunnel som trenger en hook i stedet for en profilsnøkkel. Sjekk dem i den rekkefølgen, fordi den første er billigst å utelukke.

Destinasjonen er en nettverksadresse, masken beskriver prefikset

networksetup -setadditionalroutes tar tripler av destinasjon, subnettmaske og gateway. Kallet som sender et 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 hva destinasjonen er: nettverksadressen, ikke adressen til serveren du prøver å nå. I tilfellet som ga opphav til denne artikkelen, gjorde den identiske kommandoen med 192.168.1.20 på den plassen ingenting nyttig, og å erstatte den med 192.168.1.0 virket umiddelbart. Samme maske, samme gateway, ett annet tall. Det er hele feilen i miniatyr.

Årsaken er aritmetikk, ikke policy. En vertsadresse sammen med en /24-maske beskriver ikke 192.168.1.0/24; den beskriver noe rutetabellen ikke kan holde nyttig, så oppføringen avvises eller ignoreres, og tunnelen bærer til slutt mindre enn du hadde tenkt.

Når du vil ha nøyaktig én vert, bruk vertsadressen med en maske på 255.255.255.255. Blandede par er der dette går galt, ikke bruken av en vertsadresse som sådan. En /32 bygget av én adresse er en legitim rute; en /24 bygget av én adresse er en feil.

Kallet erstatter listen, og navnet er bokstavelig

To atferder overrasker folk på første forsøk. Kommandoen setter hele listen over ekstra ruter i stedet for å legge til, så et kall som legger til ett prefiks fjerner stille de andre som var der før. Bygg hele settet i ett kall.

Tjenestenavnet er heller ikke etiketten du fant opp. Les det fra verktøyet og kopier det nøyaktig, inkludert type-suffikset:

networksetup -listallnetworkservices

Et navn som avviker med ett tegn gir ingen feil som er verdt å lese og ingen rute. Kopier og lim inn er riktig teknikk her, ikke å skrive på nytt fra hukommelsen.

Når profilen gjør krav på standardruten

Delte ruter taper mot en standardrute for enhver destinasjon de ikke dekker eksplisitt, og en L2TP-profil konfigurert for full tunnel installerer nettopp det. Hvis profilen sier at alt går gjennom tunnelen, endrer listen over ekstra ruter seg svært lite. Oppføringen din er ikke feil; den er rett og slett irrelevant for destinasjonene den aldri nevner. Kontrollen for dette sitter vanligvis i profilens innstilling for å sende all trafikk, ikke i noen rute-kommando.

Bestem hvilken modell du faktisk vil ha før du redigerer flere oppføringer. Full tunnel med unntak er en annen konfigurasjon enn delt tunnel med bestemte prefikser, og å blande de to gir en tabell ingen kan forutsi.

Hvis organisasjonen krever full tunnel, slutt å prøve å dele den lokalt og ta kravet til den som eier policyen. En lokalt lagt til rute som motsier det, blir uansett fjernet ved neste profiloppdatering.

PPP-tunneler trenger en hook i stedet for en nøkkel

For PPP-baserte tunneler er defaultroute profilsnøkkelen som lager en standardrute; fjern den, og klienten slutter å gjøre krav på hver destinasjon. Deretter legges ruter til etter at grensesnittet dukker opp, vanligvis fra /etc/ppp/ip-up:

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

Hold skriptet eid av root og kjørbart, og legg til en vakt på grensesnittnavnet når det finnes mer enn én tunnelprofil på maskinen. En hook som kjører for hver PPP-kobling og antar ett enhetsnavn, er en liten feil med et langt liv.

Verifiser delingen med tre forespørsler

Ta opp tabellen mens du er tilkoblet, og noter hvilket grensesnitt som betjener tunnelen. Sjekk deretter den konkrete destinasjonen i stedet for å stole på utgangsstatusen til kommandoen som opprettet den. En utgangskode forteller om verktøyet godtok argumentene, ikke om trafikken tar veien du hadde tenkt.

Avslutt med tre forespørsler som beviser delingen: én intern vert etter adresse, ett internt navn via den interne resolvertjenesten og ett offentlig nettsted som fortsatt skal bruke den lokale tilkoblingen. Hvis det offentlige nettstedet nå også går gjennom tunnelen, skjedde delingen aldri, uansett hva rutelisten ser ut til å si.

Koble til på nytt en gang til og gjenta den interne forespørselen, fordi ruter som legges til manuelt kan overleve grensesnittet som gjorde dem gyldige og stille gjøre trafikken til et svart hull etter at tunnelen faller.