Divi VPN lēcieni vienā Pi: kurš maršruts nes kuru partneri

Divas tuneļa adreses vienā mazā platē izskatās kā kļūda, un reflekss ir dzēst vienu. Šis reflekss salauž to, ko tam vajadzēja sakārtot. Resursdators, kas nes divus lēcienus, tur vienu adresi katram savienojumam, un katru adresi izvēlas cits maršruts. Jautājums, ko ir vērts uzdot, ir kurš maršruts izvēlas kuru nesēju kuram galamērķim, nevis cik adrešu pastāv.

Trīs galamērķi, kuriem vajadzīgi dažādi nesēji

Divu lēcienu ķēde ir trīs sakrautanas galamērķu klases, un katru nes cits savienojums. Ārējais partneris jāsasniedz pa fizisko saiti. Iekšējais partneris jāsasniedz pa ārējo tuneli. Pārklātās lietotnes galamērķis jāsasniedz pa iekšējo tuneli, kura paša transportu nes ārējais.

Pirms aiztikt maršrutu, aizpildiet rindas ar lasītāja īstajām adresēm, jo tabula ir noderīga tikai tad, kad tā ir konkrēta. Strādājoša ķēde vienlaikus apmierina visas četras rindas, un daļēji strādājoša ķēde parasti apmierina vienu no tām ar nepareizo nesēju. Tieši nepareizās rindas lasīšana kā bojājuma pārvērš maršrutēšanas problēmu veselā pēcpusdienā ar labojumiem.

Adresēm ir lomas, nevis skaits

Linux atļauj vairākas adreses vienā saskarnē un vairākus tuneļus vienā resursdatorā, tāpēc skaits neko neizsaka par pareizību. Svarīgi ir tas, kura adrese pieder kuram savienojumam, un vai maršruts konkrētam partnerim izvēlas to savienojumu, ko jūs domājāt. Trīs skati atbild uz to no trim virzieniem, un tos ir vērts lasīt vienā un tajā pašā secībā katru reizi.

Adrešu uzskaite parāda, kas pastāv un kurš savienojums to pārvalda. Maršrutu tabula atbild uz nesēja jautājumu parastajai galamērķu plūsmai. Politikas skats atbild uz to vēlreiz plūsmai, kas atlasīta pēc avota vai atzīmes, un tā ir parastā kārtība, kad divi klienti dala vienu resursdatoru.

ip -4 addr show
ip -4 route show table all
ip rule show

Adreses dzēšana tāpēc, ka saraksts izskatās garš, var noņemt daļu ceļa, un maršruta dzēšana tāpēc, ka tas izskatās lieks, dara to pašu klusāk. Neviens no tiem neizraisa kļūdu; partneris vienkārši pārstāj atbildēt tajā ceļā, ko jūs domājāt, bet paliek sasniedzams pa citu. Lietotne, kas ziņo iekšējā partnera izejas adresi, nepierāda, ka plūsma šķērsoja ārējo tuneli, jo tieša piekļuve sniedz to pašu novērojumu. Tieši šī plaisa starp novērojumu un pierādījumu ir iemesls, kāpēc nesējs tiek pārbaudīts maršrutēšanas slānī.

Aktivizācijas secība pārspēj fiksētu gaidīšanu

Ja iekšējais klients ir atkarīgs no adreses vai maršruta, ko nodrošina ārējais klients, aktivizācijai jāgaida uz šo resursu, nevis uz aizkavēšanos. Gaidīšana darbojas līdz dienai, kad ārējais tunelis ir lēns, un tad tā periodiski neizdodas tā, ka neviens to nevar atkārtot. Secība, kas balstīta uz atkarībām, novērš minējumus un neizmaksā neko, izņemot atkarības aprakstīšanu vienu reizi. Arī saskarņu nosaukumi nav secības mehānisms.

Kodols piešķir nosaukumus, piemēram, tun0 un tun1, izveides secībā, un šī secība var mainīties starp pārstartēšanām vai atkārtotām savienošanām. Saistiet konfigurāciju ar identitāti, ko nodrošina rīks, vai ar nosaukumu, ko apzināti piešķirat. Nosaukums, ko izvēlaties jūs, ir līgums; nosaukums, ko izvēlas kodols, ir nejaušība.

Turiet katra klienta transportu ārpus otra lietotnes maršruta, un esiet precīzs par to, ko OpenVPN 2.6 maršrutēšanas opcijas patiešām sola. Dokumentētais noklusējuma pārvirzīšanas mehānisms uztur klientu spējīgu sasniegt savu attālo partneri pa vārteju, kas jau pastāvēja, un tas pārtrauc vienu konkrētu rekursijas cilpu. Tas nepārvērš vienu klientu otra klienta nesējā, tāpēc pārējā ķēde paliek jūsu dizains. Kur ķēdei vajadzīga politika, nevis maršruts, uzrakstiet skaidru avota vai atzīmes noteikumu un pārbaudiet to ar plūsmu, kurai tam jāatbilst.

Kas notiek, kad ārējais lēciens mirst

Pirms ķēde tiek uzskatīta par pabeigtu, izlemiet, kas notiek, kad ārējais lēciens pazūd. Iekšējā klienta transports mirst kopā ar to, un nākamais solis ir politikas, nevis tehnikas jautājums: ciest neveiksmi, mēģināt vēlreiz vai tieši atkārtoti savienoties pa fizisko saiti. Tieši trešais iznākums ir tas, par ko ir vērts domāt. Tas klusi pārvērš divu lēcienu dizainu viena lēciena dizainā tajā brīdī, kad lietotājs tic, ka pārklājums joprojām ir neskarts.

Ja divi lēcieni ir obligāti, iekšējais klients nedrīkst spēt izveidot tiešu ceļu, kad ārējais ir pazudis, un veids, kā to noskaidrot, ir salauzt ārējo lēcienu un novērot, ko dara iekšējais. Apstiprināts rezerves variants ir likumīga atbilde, bet tas ir jāpieraksta, jāpārbauda un jāpaziņo. Rezerves variants, ko neviens nav dokumentējis, incidenta izskatīšanā nav atšķirams no noplūdes.

DNS un otra adrešu saime pieder pie tā paša lēmuma. Lokāli ģenerēts vaicājums seko paša resursdatora politikai, nevis pārsūtīta klienta politikai, tāpēc atrisinātājs, kas darbojas pārsūtītai plūsmai, var nebūt tas, ko izmanto pats resursdators.

Pieņemiet katru slāni tādā secībā, kādā to būvējāt

Pārbaudiet tādā secībā, kādā ķēde tika būvēta: vispirms ārējais tunelis viens pats, tad iekšējā klienta transports pa ārējo tuneli, tad lietotne pa iekšējo tuneli. Katram pieņemšanas gadījumam jābūt jaunam savienojumam, nevis jau atvērtai lapai. Tad atsevišķi salauziet un atjaunojiet katru slāni un novērojiet, ko dara nākamais.

Rezerves varianta rezultāts šeit ir vērtīgākais novērojums, un tas, ko publiskās IP lapa nekad neparāda. Saglabājiet partneru ceļus, viņu izmantotās adreses un šo rezultātu blakus konfigurācijai, jo laimīgais ceļš nav tā daļa, kas vēlāk tiek apšaubīta.