Rute L2TP separate pe Mac: de ce o adresă de gazdă nu funcționează

VPN-ul se conectează, bara de meniu arată asta, iar o gazdă internă tot expiră. În această situație există trei cauze posibile, iar care se aplică depinde de modul în care a fost configurat tunelul. Fie comanda de rută a folosit o adresă de gazdă acolo unde era necesară o adresă de rețea, fie profilul însuși instalează o rută implicită care înghite decizia, fie clientul este un tunel PPP care are nevoie de un hook în loc de o cheie de profil. Verificați-le în această ordine, pentru că prima este cea mai ieftină de exclus.

Destinația este o adresă de rețea, masca descrie prefixul

networksetup -setadditionalroutes ia triplete de destinație, mască de subrețea și gateway. Apelul care trimite o subrețea internă prin tunel arată astfel:

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

Observați ce este destinația: adresa de rețea, nu adresa serverului pe care încercați să îl atingeți. În cazul care a generat acest articol, comanda identică cu 192.168.1.20 în acea poziție nu a făcut nimic util, iar înlocuirea ei cu 192.168.1.0 a funcționat imediat. Aceeași mască, același gateway, un număr diferit. Aceasta este întreaga defecțiune în miniatură.

Motivul este aritmetic, nu politic. O adresă de gazdă asociată cu o mască /24 nu descrie 192.168.1.0/24; descrie ceva ce tabelul de rutare nu poate păstra în mod util, așa că intrarea este respinsă sau ignorată, iar tunelul ajunge să transporte mai puțin decât intenționați.

Când doriți exact o gazdă, folosiți adresa de gazdă cu o mască 255.255.255.255. Perechile mixte sunt locul unde acest lucru se strică, nu folosirea unei adrese de gazdă ca atare. Un /32 construit dintr-o adresă este o rută legitimă; un /24 construit dintr-o adresă este o greșeală.

Apelul înlocuiește lista, iar numele este literal

Două comportamente surprind oamenii la prima încercare. Comanda setează lista completă de rute suplimentare în loc să adauge, așa că un apel care adaugă un prefix le elimină în tăcere pe celelalte care erau acolo înainte. Construiți întregul set într-un singur apel.

Nici numele serviciului nu este eticheta pe care ați inventat-o. Citiți-l din instrument și copiați-l exact, inclusiv sufixul de tip:

networksetup -listallnetworkservices

Un nume care diferă printr-un caracter nu produce nicio eroare care merită citită și nicio rută. Copierea și lipirea este tehnica corectă aici, nu rescrierea din memorie.

Când profilul revendică ruta implicită

Rutele separate pierd în fața unei rute implicite pentru orice destinație pe care nu o acoperă explicit, iar un profil L2TP configurat pentru tunel complet instalează exact asta. Dacă profilul spune că totul trece prin tunel, lista de rute suplimentare se schimbă foarte puțin. Intrarea dumneavoastră nu este greșită; este pur și simplu irelevantă pentru destinațiile pe care nu le numește niciodată. Controlul acestui lucru stă de obicei în setarea profilului de a trimite tot traficul, nu într-o comandă de rută.

Decideți ce model doriți cu adevărat înainte de a edita mai multe intrări. Tunelul complet cu excepții este o configurație diferită de tunelul separat cu prefixe specifice, iar amestecarea celor două produce un tabel pe care nimeni nu îl poate prezice.

Dacă organizația cere tunel complet, opriți-vă din a încerca să îl separați local și duceți cerința la cel care deține politica. O rută adăugată local care o contrazice va fi eliminată oricum la următoarea actualizare a profilului.

Tunelurile PPP au nevoie de un hook în loc de o cheie

Pentru tunelurile bazate pe PPP, defaultroute este cheia de profil care creează o rută implicită; eliminați-o și clientul nu mai revendică fiecare destinație. Rutele sunt apoi adăugate după apariția interfeței, de obicei din /etc/ppp/ip-up:

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

Păstrați scriptul deținut de root și executabil, și adăugați o pază pe numele interfeței când există mai mult de un profil de tunel pe mașină. Un hook care rulează pentru fiecare legătură PPP și presupune un singur nume de dispozitiv este o eroare mică cu viață lungă.

Verificați separarea cu trei cereri

Capturați tabelul în timp ce sunteți conectat și notați ce interfață deservește tunelul. Apoi verificați destinația concretă în loc să vă bazați pe starea de ieșire a comenzii care a creat-o. Un cod de ieșire raportează dacă instrumentul a acceptat argumentele, nu dacă traficul urmează calea dorită.

Încheiați cu trei cereri care dovedesc separarea: o gazdă internă după adresă, un nume intern prin resolverul intern și un site public care ar trebui să folosească în continuare conexiunea locală. Dacă site-ul public trece acum și prin tunel, separarea nu a avut loc niciodată, orice ar părea să spună lista de rute.

Reconectați-vă încă o dată și repetați cererea internă, pentru că rutele adăugate manual pot supraviețui interfeței care le-a făcut valide și pot transforma în tăcere traficul într-o gaură neagră după ce tunelul cade.