Mac L2TP sadalītie maršruti: kāpēc resursdatora adrese nedarbojas

VPN savienojas, izvēļu josla to rāda, un iekšējais resursdators tomēr nokļūst līdz taimautam. Šādā situācijā ir trīs iespējami cēloņi, un tas, kurš attiecas, ir atkarīgs no tā, kā tika konfigurēts tunelis. Vai nu maršruta komanda izmantoja resursdatora adresi tur, kur bija vajadzīga tīkla adrese, vai pats profils instalē noklusējuma maršrutu, kas aprīj lēmumu, vai arī klients ir PPP tunelis, kuram vajag āķi, nevis profila atslēgu. Pārbaudiet tos šajā secībā, jo pirmo ir vislētāk izslēgt.

Galamērķis ir tīkla adrese, maska apraksta prefiksu

networksetup -setadditionalroutes ņem galamērķa, apakštīkla maskas un vārtejas trīskāršus. Izsaukums, kas sūta vienu iekšējo apakštīklu caur tuneli, izskatās šādi:

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

Pievērsiet uzmanību tam, kas ir galamērķis: tīkla adrese, nevis tā servera adrese, kuru mēģināt sasniegt. Gadījumā, kas radīja šo rakstu, identiskā komanda ar 192.168.1.20 tajā vietā neizdarīja neko lietderīgu, un tās aizstāšana ar 192.168.1.0 darbojās uzreiz. Tā pati maska, tā pati vārteja, viens cits skaitlis. Tas ir viss neveiksmes modelis mazumā.

Iemesls ir aritmētika, nevis politika. Resursdatora adrese kopā ar /24 masku neapraksta 192.168.1.0/24; tā apraksta kaut ko tādu, ko maršrutēšanas tabula nevar lietderīgi noturēt, tāpēc ieraksts tiek noraidīts vai ignorēts, un tunelis galu galā pārvadā mazāk, nekā bijāt iecerējis.

Ja vēlaties tieši vienu resursdatoru, izmantojiet resursdatora adresi ar masku 255.255.255.255. Tieši jauktie pāri ir vieta, kur tas sabojājas, nevis resursdatora adreses izmantošana kā tāda. /32, kas veidots no vienas adreses, ir likumīgs maršruts; /24, kas veidots no vienas adreses, ir kļūda.

Izsaukums aizstāj sarakstu, un nosaukums ir burtisks

Divi uzvedības modeļi pārsteidz pirmajā mēģinājumā. Komanda iestata visu papildu maršrutu sarakstu, nevis pievieno, tāpēc izsaukums, kas pievieno vienu prefiksu, klusi noņem pārējos, kas bija pirms tam. Veidojiet visu kopu vienā izsaukumā.

Arī servisa nosaukums nav jūsu izdomātais apzīmējums. Izlasiet to no rīka un nokopējiet precīzi, ieskaitot tipa piedēkli:

networksetup -listallnetworkservices

Nosaukums, kas atšķiras ar vienu rakstzīmi, nesniedz ne lasīšanas vērtu kļūdu, ne maršrutu. Šeit pareizā tehnika ir kopēt un ielīmēt, nevis pārrakstīt no atmiņas.

Kad profils pieprasa noklusējuma maršrutu

Sadalītie maršruti zaudē noklusējuma maršrutam katram galamērķim, ko tie nepārklāj skaidri, un L2TP profils, kas konfigurēts pilnam tunelim, instalē tieši to. Ja profils saka, ka viss iet caur tuneli, papildu maršrutu saraksts mainās ļoti maz. Jūsu ieraksts nav nepareizs; tas vienkārši nav būtisks galamērķiem, kurus tas nekad nenosauc. Tā kontrolle parasti atrodas profila visu datu plūsmu sūtīšanas iestatījumā, nevis kādā maršruta komandā.

Izlemiet, kuru modeli jūs patiešām vēlaties, pirms rediģējat vairāk ierakstu. Pilns tunelis ar izņēmumiem ir cita konfigurācija nekā sadalīts tunelis ar konkrētiem prefiksiem, un abu sajaukšana rada tabulu, ko neviens nevar paredzēt.

Ja organizācija pieprasa pilnu tuneli, pārtrauciet mēģināt to sadalīt lokāli un aiznesiet prasību tam, kam pieder politika. Lokāli pievienots maršruts, kas tam pretrunā, tik un tā tiks noņemts nākamajā profila atjauninājumā.

PPP tuneļiem vajag āķi, nevis atslēgu

PPP balstītiem tuneļiem defaultroute ir profila atslēga, kas izveido noklusējuma maršrutu; noņemiet to, un klients pārstāj pieprasīt katru galamērķi. Pēc tam maršruti tiek pievienoti pēc saskarnes parādīšanās, parasti no /etc/ppp/ip-up:

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

Turiet skriptu root īpašumā un izpildāmu, un pievienojiet aizsargu saskarnes nosaukumam, ja iekārtā ir vairāk nekā viens tuneļa profils. Āķis, kas darbojas katram PPP savienojumam un pieņem vienu ierīces nosaukumu, ir maza kļūda ar garu mūžu.

Pārbaudiet sadalījumu ar trim pieprasījumiem

Uzņemiet tabulu, kamēr esat savienots, un atzīmējiet, kura saskarne apkalpo tuneli. Pēc tam pārbaudiet konkrēto galamērķi, nevis paļaujieties uz tās komandas, kas to izveidoja, iziešanas statusu. Iziešanas kods ziņo, vai rīks pieņēma argumentus, nevis vai datu plūsma iet iecerēto ceļu.

Pabeidziet ar trim pieprasījumiem, kas pierāda sadalījumu: viens iekšējais resursdators pēc adreses, viens iekšējais nosaukums caur iekšējo atrisinātāju un viena publiska vietne, kurai joprojām būtu jāizmanto vietējais savienojums. Ja publiskā vietne tagad arī iet caur tuneli, sadalījums nekad nenotika, lai ko arī maršrutu saraksts šķistu sakām.

Pieslēdzieties vēlreiz un atkārtojiet iekšējo pieprasījumu, jo ar roku pievienoti maršruti var pārdzīvot saskarni, kas tos padarīja derīgus un klusi pārvērst datu plūsmu melnajā caurumā pēc tuneļa kritiena.