Mac L2TP gesplitste routes: waarom een hostadres niet werkt

De VPN verbindt, de menubalk toont het, en een interne host loopt nog steeds vast. In die situatie zijn er drie mogelijke oorzaken, en welke geldt hangt af van hoe de tunnel is geconfigureerd. Ofwel gebruikte de routeopdracht een hostadres waar een netwerkadres nodig was, ofwel installeert het profiel zelf een standaardroute die de beslissing opslokt, ofwel is de client een PPP-tunnel die een hook nodig heeft in plaats van een profielsleutel. Controleer ze in die volgorde, want de eerste is het goedkoopst uit te sluiten.

De bestemming is een netwerkadres, het masker beschrijft het prefix

networksetup -setadditionalroutes neemt drietallen van bestemming, subnetmasker en gateway. De aanroep die één intern subnet door de tunnel stuurt, ziet er zo uit:

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

Let op wat de bestemming is: het netwerkadres, niet het adres van de server die u probeert te bereiken. In het geval dat dit artikel opleverde, deed de identieke opdracht met 192.168.1.20 op die plaats niets nuttigs, en het vervangen door 192.168.1.0 werkte meteen. Hetzelfde masker, dezelfde gateway, één ander nummer. Dat is de hele fout in het klein.

De reden is rekenwerk, geen beleid. Een hostadres met een /24-masker beschrijft niet 192.168.1.0/24; het beschrijft iets wat de routetabel niet nuttig kan vasthouden, dus de vermelding wordt geweigerd of genegeerd en de tunnel vervoert uiteindelijk minder dan u bedoelde.

Als u precies één host wilt, gebruikt u het hostadres met een masker van 255.255.255.255. Gemengde paren zijn waar dit misgaat, niet het gebruik van een hostadres als zodanig. Een /32 uit één adres is een legitieme route; een /24 uit één adres is een fout.

De aanroep vervangt de lijst, en de naam is letterlijk

Twee gedragingen verrassen mensen bij de eerste poging. De opdracht stelt de volledige lijst met extra routes in in plaats van aan te vullen, dus een aanroep die één prefix toevoegt, verwijdert stil de andere die er eerder stonden. Bouw de hele set in één aanroep.

De servicenaam is ook niet het label dat u hebt verzonnen. Lees hem uit het gereedschap en kopieer hem exact, inclusief het type-achtervoegsel:

networksetup -listallnetworkservices

Een naam die één teken verschilt levert geen fout op die het lezen waard is en geen route. Kopiëren en plakken is hier de juiste techniek, niet opnieuw typen uit het geheugen.

Wanneer het profiel de standaardroute opeist

Gesplitste routes verliezen van een standaardroute voor elke bestemming die ze niet expliciet dekken, en een L2TP-profiel dat voor volledige tunnel is geconfigureerd, installeert precies dat. Als het profiel zegt dat alles door de tunnel gaat, verandert de lijst met extra routes heel weinig. Uw vermelding is niet fout; hij is simpelweg irrelevant voor de bestemmingen die hij nooit noemt. De controle hiervoor zit meestal in de instelling van het profiel om al het verkeer te versturen, niet in een routeopdracht.

Bepaal welk model u echt wilt voordat u meer vermeldingen bewerkt. Volledige tunnel met uitzonderingen is een andere configuratie dan gesplitste tunnel met specifieke prefixen, en de twee mengen levert een tabel op die niemand kan voorspellen.

Als de organisatie een volledige tunnel vereist, stop dan met lokaal splitsen en breng de eis naar wie het beleid bezit. Een lokaal toegevoegde route die daarmee in strijd is, wordt toch bij de volgende profielupdate verwijderd.

PPP-tunnels hebben een hook nodig in plaats van een sleutel

Voor op PPP gebaseerde tunnels is defaultroute de profielsleutel die een standaardroute maakt; verwijder die en de client claimt niet langer elke bestemming. Daarna worden routes toegevoegd nadat de interface verschijnt, meestal vanuit /etc/ppp/ip-up:

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

Houd het script in eigendom van root en uitvoerbaar, en voeg een wacht toe op de interfacenaam wanneer er meer dan één tunnelprofiel op de machine staat. Een hook die voor elke PPP-verbinding draait en één apparaatnaam aanneemt, is een kleine fout met een lang leven.

Verifieer de splitsing met drie verzoeken

Leg de tabel vast terwijl u verbonden bent en noteer welke interface de tunnel bedient. Controleer daarna de specifieke bestemming in plaats van te vertrouwen op de exitstatus van de opdracht die hem aanmaakte. Een exitcode meldt of het gereedschap de argumenten accepteerde, niet of het verkeer de bedoelde weg neemt.

Sluit af met drie verzoeken die de splitsing bewijzen: één interne host op adres, één interne naam via de interne resolver en één openbare site die nog steeds de lokale verbinding zou moeten gebruiken. Als de openbare site nu ook door de tunnel gaat, heeft de splitsing nooit plaatsgevonden, wat de routelijst ook lijkt te zeggen.

Maak nog één keer verbinding en herhaal het interne verzoek, want routes die met de hand zijn toegevoegd kunnen de interface overleven die ze geldig maakte en het verkeer na het wegvallen van de tunnel stil in een zwart gat laten verdwijnen.