Sadalītā tuneļa saraksts sākas ar trim lietotnēm un beigās aptver lielāko daļu datora, un katra jauna rinda ir kāda izņēmums. Tajā brīdī saraksts klusi ir kļuvis par noklusējuma iestatījumu ar papildu soļiem. Pilns tunelis apgriež kārtību: viss nonāk tunelī, ja vien dokumentēts izņēmums nepasaka citādi. Vai tas ir vienkāršāk, ir atkarīgs no vārtejas un vietējiem pakalpojumiem, kurus jūs salauztu.

Sāciet ar to noteikumu skaitīšanu, kurus uzturat

Saskaitiet ierakstus, pēc tam saskaitiet, cik daudziem ir nosaukts īpašnieks un pēdējās pārbaudes datums. Svarīgs ir otrais skaitlis, jo izņēmumu, kam nav īpašnieka, nevar novērtēt, kad programmatūra, uz kuru tas attiecas, tiek pārdēvēta vai aizstāta. Noteikumi, kas piesaistīti izpildāmas datnes ceļam, pēc atjauninājuma klusi pārstāj darboties, un kļūme izskatās kā nestabils VPN, nevis kā novecojis noteikums. Pierakstiet sarakstu, pirms jums par to ir viedoklis.

Katram ierakstam būtu jāatbild uz trim jautājumiem: kas salūzt bez tā, kas to nolēma un kā jūs pamanītu, ka iemesls ir beidzies. Ieraksti, kas nevar atbildēt uz visiem trim, ir dzēšanas, nevis migrācijas kandidāti, un to dzēšana vispirms padara vēlāko salīdzinājumu godīgu.

Ja lielākā daļa ierakstu maršrutē lielu daļu trafika, jūs jau uzturat pilnu tuneli ar pievienotu uzturēšanas slogu. Tad lēmums ir par to, kur dzīvo noklusējuma iestatījums, nevis par to, vai tam jābūt.

Pārbaudiet, vai vārteja var izturēt noklusējuma iestatījumu

Pilns tunelis pārvieto katru paketi uz vienu ierīci, kas vienlaikus maina šīs ierīces procesora slodzi, conntrack tabulu, adrešu tulkošanu un augšupielādes joslas platuma prasību. Vārteja, kas ērti apkalpoja dažus iekšējos apakštīklus, varētu nebūt izmērīta visai lietotāja pārlūkošanai. Skatieties uz lielāko gaidāmo vienlaicīgo sesiju skaitu, nevis vidējo, jo vispirms lūzt maksimums.

ip -s link show dev tun0
conntrack -C
ss -s

Izmēriet to pašu darba slodzi pirms un pēc izmaiņām, nevis spriediet no specifikācijām. Viena parasta lietošanas pēcpusdiena vienā datorā parādīs, vai vārteja ir tuvu kādai robežai, un tas neizmaksā neko, salīdzinot ar tā atklāšanu pirmdienas rītā.

Pārbaudiet arī ceļa MTU no gala līdz galam, jo pilns noklusējuma iestatījums pakļauj katru lietotni tuneļa maksimālajam paketes izmēram. Lietotnes, kas darbojās ārpus tuneļa, tagad var būt atkarīgas no sadalīšanas uzvedības, par ko jums nekad nav bijis jādomā.

Apstipriniet, ka vietējie pakalpojumi un privātais DNS joprojām darbojas

Uzskaitiet, kam jāpaliek vietējam pēc protokola, nevis pēc lietotnes nosaukuma: atklāšanas protokoli printeriem un displejiem, viedās mājas tilts, maršrutētāja pārvaldības lapa, vietējais izstrādes serveris, kas sasniedzams ar vārdu, kurš atrisinās tikai LAN tīklā. Šīs lietas salūzt, kad noklusējuma maršruts sāk rādīt tunelī, un tās salūzt klusi, jo klientā nekas nefiksē kļūdu.

Privātais DNS ir otra atkarība. Ja iekšējie vārdi iepriekš tika atrisināti ar tuneļa atrisinātāju, nekas nemainās; ja tie tika atrisināti lokāli, pilnam noklusējuma iestatījumam tie jānogādā atrisinātājam, kas pārzina zonas. Pēc izmaiņām pārbaudiet vienu iekšēju un vienu publisku vārdu, nevis pieņemiet, ka atrisinātāju saraksts ir izdzīvojis.

Ierakstiet vietējos izņēmumus profilā, kuram tie pieder. Izņēmums, kas glabājas tikai kāda atmiņā, ir pirmā lieta, ko zaudē nākamā migrācija.

Migrējiet vienu profilu un pārbaudiet robežas

Mainiet profilu, izmantojot tā paša konfigurāciju, nevis uzklājiet jaunu noklusējuma iestatījumu virs manuāliem maršrutiem, ko atstājuši agrākie eksperimenti. Tie atlikušie maršruti ir parastais iemesls migrācijai, kas izskatās strādājam un dienu vēlāk uzvedas nekonsekventi. Turiet veco profilu pieejamu, lai atgriešanās būtu izvēle, nevis pārbūve.

Pēc tam pārbaudiet divas robežas atsevišķi: ka publiskie un privātie galamērķi strādā abi, un ka nevēlamais trafiks neiziet ārpus tuneļa. Veiksmīga lapas ielāde pierāda pirmo un neko nepasaka par otro.

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

Atkārtojiet pārbaudi pēc savienojuma atjaunošanas un pēc pārtraukuma, jo slēdzis, kas pārtraukuma laikā bloķē trafiku, ir cita īpašība nekā maršruts, kas pēc tam pareizi atjaunojas. Vienkāršākais dizains ir tas, kura faktisko pārklājumu jūs joprojām varat izskaidrot pēc tam, kad lietotne vai tīkls ir mainījies.

Saistītie raksti