Delade L2TP-rutter på Mac: varför en värdadress inte fungerar

VPN ansluter, menyraden visar det, och en intern värd får fortfarande timeout. I den situationen finns tre möjliga orsaker, och vilken som gäller beror på hur tunneln konfigurerades. Antingen använde route-kommandot en värdadress där en nätverksadress krävdes, eller så installerar profilen själv en standardrutt som sväljer beslutet, eller så är klienten en PPP-tunnel som behöver en hook i stället för en profilnyckel. Kontrollera dem i den ordningen, eftersom den första är billigast att utesluta.

Destinationen är en nätverksadress, masken beskriver prefixet

networksetup -setadditionalroutes tar tripler av destination, subnätmask och gateway. Anropet som skickar ett internt subnät genom tunneln ser ut så här:

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

Lägg märke till vad destinationen är: nätverksadressen, inte adressen till servern du försöker nå. I fallet som gav upphov till den här artikeln gjorde det identiska kommandot med 192.168.1.20 på den platsen ingenting användbart, och att ersätta det med 192.168.1.0 fungerade omedelbart. Samma mask, samma gateway, ett annat nummer. Det är hela felet i miniatyr.

Orsaken är aritmetik, inte policy. En värdadress parad med en /24-mask beskriver inte 192.168.1.0/24; den beskriver något som routingtabellen inte kan hålla användbart, så posten avvisas eller ignoreras och tunneln bär till slut mindre än du tänkt.

När du vill ha exakt en värd använder du värdadressen med en mask på 255.255.255.255. Blandade par är där detta går fel, inte användningen av en värdadress som sådan. En /32 byggd av en adress är en legitim rutt; en /24 byggd av en adress är ett fel.

Anropet ersätter listan, och namnet är bokstavligt

Två beteenden överraskar folk vid första försöket. Kommandot ställer in hela listan med extra rutter i stället för att lägga till, så ett anrop som lägger till ett prefix tar tyst bort de andra som fanns där tidigare. Bygg hela uppsättningen i ett enda anrop.

Tjänstenamnet är inte heller etiketten du hittade på. Läs det från verktyget och kopiera det exakt, inklusive typ-suffixet:

networksetup -listallnetworkservices

Ett namn som skiljer sig med ett tecken ger inget fel som är värt att läsa och ingen rutt. Kopiera och klistra in är rätt teknik här, inte att skriva om från minnet.

När profilen gör anspråk på standardrutten

Delade rutter förlorar mot en standardrutt för varje destination de inte uttryckligen täcker, och en L2TP-profil konfigurerad för full tunnel installerar exakt det. Om profilen säger att allt går genom tunneln ändras listan med extra rutter väldigt lite. Din post är inte fel; den är helt enkelt irrelevant för de destinationer den aldrig namnger. Kontrollen för detta sitter vanligtvis i profilens inställning för att skicka all trafik, inte i något route-kommando.

Bestäm vilken modell du faktiskt vill ha innan du redigerar fler poster. Full tunnel med undantag är en annan konfiguration än delad tunnel med specifika prefix, och att blanda de två ger en tabell som ingen kan förutsäga.

Om organisationen kräver full tunnel, sluta försöka dela den lokalt och ta kravet till den som äger policyn. En lokalt tillagd rutt som motsäger det tas ändå bort vid nästa profiluppdatering.

PPP-tunnlar behöver en hook i stället för en nyckel

För PPP-baserade tunnlar är defaultroute profilnyckeln som skapar en standardrutt; ta bort den och klienten slutar göra anspråk på varje destination. Sedan läggs rutter till efter att gränssnittet dyker upp, vanligtvis från /etc/ppp/ip-up:

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

Håll skriptet ägt av root och körbart, och lägg till en vakt på gränssnittsnamnet när det finns mer än en tunnelprofil på maskinen. En hook som körs för varje PPP-länk och antar ett enda enhetsnamn är ett litet fel med ett långt liv.

Verifiera delningen med tre förfrågningar

Fånga tabellen medan du är ansluten och notera vilket gränssnitt som betjänar tunneln. Kontrollera sedan den specifika destinationen i stället för att lita på utgångsstatusen för kommandot som skapade den. En utgångskod talar om ifall verktyget accepterade argumenten, inte om trafiken tar den väg du avsåg.

Avsluta med tre förfrågningar som bevisar delningen: en intern värd via adress, ett internt namn via den interna resolvern och en offentlig webbplats som fortfarande bör använda den lokala anslutningen. Om den offentliga webbplatsen nu också går genom tunneln hände delningen aldrig, vad ruttlistan än verkar säga.

Anslut en gång till och upprepa den interna förfrågan, eftersom rutter som läggs till för hand kan överleva det gränssnitt som gjorde dem giltiga och tyst göra trafiken till ett svart hål efter att tunneln faller.