Papildu Mac VPN maršrutiem vajag īpašnieku, nevis pieteikšanās skriptu
Maršruts, kas pievienots vienu reizi pieteikšanās laikā, nav atkārtotas pieslēgšanās politika. Piešķiriet attālajiem prefiksiem īpašnieku un izlemiet, kā tie parādās, mainās un pazūd kopā ar šo savienojumu.
Sasniegt privātu prefiksu caur VPN ir prasība ar ilgumu: tā ir spēkā, kamēr savienojums ir lietojams, un tā beidzas, kad beidzas savienojums. Pieteikšanās skripts to nevar izteikt, jo pieteikšanās un tuneļa pacelšana ir dažādi mirkļi, un tunelis, kas pastāv pieteikšanās brīdī, var nebūt tas, kas pēc minūtes nes datplūsmu. Pirmais lēmums nav, kuru komandu izpildīt. Tas ir, kura komponente pārvalda prefiksu.
Prefiksam vajag īpašnieku, nevis mirkli
Sāciet ar prasības pierakstīšanu kā teikumu ar subjektu: sasniedziet 10.77.0.0/24 caur biroja VPN, kamēr šis savienojums ir pacelts. Šis teikums nosauc prefiksu, savienojumu un nosacījumu, un tas uzreiz izslēdz divus populārus aizstājējus: pieteikšanās āķi un saskarnes nosaukumu, piemēram, ppp0 vai utun2.
Saskarņu nosaukumi tiek piešķirti izpildlaikā un nav stabili starp atkārtotām pieslēgšanās reizēm. Āķis, kas atbilst pagājušajā nedēļā redzētajam nosaukumam, vai nu neiedarbosies, vai iedarbosies pret kāda cita saskarni. Abi iznākumi izskatās kā maršrutēšanas kļūda, nevis kā novecojis pieņēmums, kas tie ir. Tie paši iebildumi attiecas uz jebkuru skriptu, kas piesaistīts nosaukumam, kurš pastāv tikai tik ilgi, kamēr ir pacelts viens konkrēts tunelis.
Izmantojiet atbalstītu maršruta nodoma avotu
Vārteja, pārvaldīts profils vai īpašnieka klienta dokumentētais maršruta mehānisms ir īstā vieta, kad šis mehānisms spēj izteikt prasību. Kurš attiecas, atkarīgs no protokola un pakalpojumu sniedzēja, un atslēgas starp tiem nepārvietojas, tāpēc vērtība, kas konfigurē profilu OpenVPN neko nepasaka par vietējo L2TP vai IKEv2 klientu.
| Mechanism | Can carry extra prefixes | Who owns the lifetime |
|---|---|---|
| Gateway-pushed routes | Often, if the gateway is configured for it | The connection |
| Managed profile settings | Depends on the client and profile format | The profile |
| Provider tunnel settings | Yes, as included and excluded routes | The provider process |
| Manual command | Yes, once | Nobody |
Pakešu tuneļu izstrādātājiem Apple IPv4 tuneļa iestatījumi skaidri atklāj iekļautos un izslēgtos maršrutus, un IPv6 ir savs ekvivalents. Tie ir API, ko izmanto pakalpojumu sniedzējs, nevis pierādījums, ka katrs vietējais VPN panelis administratoram piedāvā patvaļīgu maršrutu sarakstu. Ja pašreizējā kombinācija nevar izteikt vajadzīgos prefiksus, nākamais solis ir atbalstīts operatora konfigurācijas ceļš, nevis cita lietotne, kas instalēta cerībā, ka tā uzvedīsies labāk.
Dzīves laiks ietver tīrīšanu
Dažkārt ārējs palīgs patiešām ir vajadzīgs, un tad «pievieno maršrutu» ir mazākā viņa darba daļa. Tam jāzina, kuram savienojumam tas kalpo un kuru saskarni šis savienojums izmanto, jāgaida, līdz attiecīgais tīkla stāvoklis nosēžas, jāpaliek idempotentam, kad tas tiek palaists divas reizes pēc kārtas, un nekas nav jātīra, ko tas pats nav instalējis.
Pēdējā klauzula ir tā, kas sāp. Palīgs, kas dzēš katru maršrutu, kas atbilst biroja prefiksam, agri vai vēlu dzēsīs maršrutu, ko tas nav pievienojis. Rezultātā radušos pārtraukumu novel uz VPN klientu, jo klients ir tā daļa, ko lietotājs redz. Izlemt, ko palīgs pārvalda, pirms to rakstīt, ir lētāk nekā pēc tam skaidrot, kāpēc vietējais apakštīkls pārstāja atbildēt.
Atkārtotas pieslēgšanās sacensība
Iedomājieties ātru atkārtotu pieslēgšanos. Sesija A nokrīt, sesija B paceļas un instalē savu maršrutu, un tad beidzot notiek A aizkavētā tīrīšana. Ja šī tīrīšana noņem maršrutus pēc prefiksa, tā paņem līdzi B derīgo stāvokli, un savienojums, kas darbojās pirms sekundes, tagad maršrutē uz nekurieni.
Tās ir īpašumtiesību sacensības, un miega pievienošana skriptam maina tikai to, kura puse tās uzvar. Risinājums ir padarīt tīrīšanu atkarīgu no identitātes: salīdziniet saskarni un sesiju, ko instalēja palīgs, ar tām, kas vēl ir spēkā, un noņemiet tikai tad, ja tās sakrīt.
Ko testēt un ko maršruts nevar
Pieņemšanai jāaptver četras pārejas: pirmais savienojums, atkārtota pieslēgšanās citai saskarnei, neizdevies savienojuma mēģinājums un galīgā atvienošanās. Pēc katras izlasiet maršrutu, ko sistēma faktiski izvēlējās adresei otrā pusē, nevis to, ko gaidījāt.
route -n get 10.77.0.5
netstat -rn -f inetIekļaujiet neērtos gadījumus tajā pašā piegājienā: IPv6 tur, kur tas vajadzīgs, vietējo prefiksu, kas pārklājas ar attālo, un maršrutu uz pašu publisko VPN galapunktu, kuram jāturpina darboties, kamēr tunelis ir pacelts. Pēc tam pierakstiet, kas maršruts nav. Tas atlasa paketes; tas nepiešķir atļauju otrā pusē un neveido atgriešanās ceļu, un tie paliek atsevišķas prasības ar atsevišķiem īpašniekiem.
Vēlamais rezultāts ir prefikss, kas katrā pārejā seko savam atbalstītajam savienojuma īpašniekam, nevis komanda, kas vienreiz nejauši izdevās tajā mašīnā, kur tā tika uzrakstīta.