Ligzdotais VPN: kurš tunelis nes ārējo savienojumu?

Divi vienlaikus darbojošies VPN klienti nerada ligzdotu tuneli; tie rada divus tuneļus un strīdu par maršrutēšanu. Ligzdots tunelis pastāv, kad iekšējā klienta savienojumu ar savu serveri pats nes ārējais tunelis, un tā ir kārtība, ko veido apzināti. Ja viss ir pareizi, iekšējais serveris redz ārējā servera adresi; ja ne, viens klients klusi pārslēdzas ap otru. Trīs nosacījumi izšķir, vai ligzdojums ir īsts vai nejaušs.

Trīs nosacījumi izšķir ligzdojumu

Pirmais ir kuram galapunktam vajadzīgs kurš ceļš. Nosauciet iekšējā servera adresi, nosauciet ārējā servera adresi un skaidri norādiet, ka iekšējais serveris ir sasniedzams tikai caur ārējo tuneli. Viss pārējais izriet no šī teikuma, tostarp tas, kuri maršruti pieder kurai tabulai.

Otrais ir vai jūs redzat ceļu katrā slānī. Ja jūs nevarat pajautāt kodolam, kuru maršrutu izmantotu konkrēts galamērķis, jūs secināt ķēdi no galīgās izejas IP, un tas ir tieši tas pierādījums, kas nevar atšķirt ligzdojumu no nejaušības.

Trešais ir kas notiek, kad ārējais tunelis nokrīt. Iekšējais tunelis var apstāties kopā ar to, pārslēgties caur parasto tīklu vai palikt bloķēts, līdz ārējais ceļš atgriežas, un visi trīs ir aizstāvamas politikas. Tās nav viena un tā pati politika, un vairākuma klientu noklusējuma uzvedība ir otrā. Klients, kas pārslēdz savu galapunktu caur fizisko tīklu, vienlaikus rādot veselīgu savienojumu, ir visbiežākais veids, kā iecerētā ķēde klusi kļūst par diviem nesaistītiem tuneļiem.

Pirmais nosacījums: kuram galapunktam vajadzīgs kurš ceļš

ip route get 203.0.113.10 atbild uz šo jautājumu tieši: tā izdrukā maršrutu, avota adresi un saskarni, ko kodols šobrīd izmantotu šim galamērķim.

Palaidiet to iekšējam serverim pirms iekšējā klienta starta un vēlreiz pēc tam, tad salīdziniet. Ja atbilde mainās no fiziskās saskarnes uz ārējā tuneļa saskarni, ligzdojums tajā brīdī ir īsts. Ja tā nemainās, iekšējais klients savienojas tieši, lai ko teiktu panelis. Atkārtojiet ārējā servera adresei, kas joprojām jāatrisina caur fizisko saskarni, jo maršruts, kas rekursīvi pārņem abus galapunktus, ir kļūme, kas pilnībā atslēdz mašīnu no tīkla.

Otrais nosacījums: pārbaudiet ceļu katrā slānī

Maršruta izvēle modernā klientā ir vairāk nekā galvenā tabula. Politikas noteikumi var sūtīt atzīmētas paketes uz citu tabulu, klients var piesaistīt savu ligzdu saskarnei, un konteineram vai nosaukumvietai ir savas tabulas. ip rule un ip route show table all ir veids, kā noskaidrot, kurš no šiem mehānismiem ir spēkā.

Klients, kas savai ligzdai iestata SO_MARK vai ir konfigurēts piesaistīties konkrētai ierīcei, apiet noklusējuma maršrutu, kuru, kā jums šķita, jūs sakārtojāt. Tā ir funkcija, nevis kļūda, un tas nozīmē, ka vienīgā uzticamā pārbaude ir tā, kas darbojas tajā pašā nosaukumvietā kā klients. Ja klienti darbojas konteineros, veiciet pārbaudes tajos konteineros, nevis uz resursdatora.

Trešais nosacījums: kas notiek, kad ārējais tunelis nokrīt

Uzvedība kļūmes gadījumā prasa lēmumu, nevis noklusējuma vērtību. Pierakstiet, kam jānotiek ar iekšējo tuneli, kad ārējais pazūd, un pēc tam lieciet klientiem tā rīkoties.

Iespējas ir konkrētas. Iekšējā klienta apturēšana, kad pazūd ārējais ceļš, dod tīru ķēdi un acīmredzamu pārtraukumu. Ļaušana tam savienoties tieši dod pieejamību un klusi noņem īpašību, kuras dēļ ķēde tika būvēta. Bloķēšana līdz ārējā ceļa atgriešanās brīdim ir stingrākā un ekspluatācijā apgrūtinošākā iespēja, jo katra ārējā tuneļa svārstība kļūst par redzamu incidentu.

Pārbaudiet visus trīs ar nekaitīgu trafiku un tīšu ārējā tuneļa kļūmi, jo konfigurācijas lasīšana nepateiks, kura jums ir. Nogaliniet ārējo tuneli, vērojiet, ko dara iekšējais klients, un vēlreiz pārbaudiet maršrutu, kamēr tas ir nolaists. Pēc tam atgrieziet ārējo tuneli un apstipriniet, ka ķēde veidojas no jauna, nevis atstāj iekšējo klientu uz tiešā ceļa, ko tas tikmēr izvēlējās.

Ko ķēde nedod

Papildu slāņi pievieno galapunktus, atslēgas un kļūmju režīmus; tie nepievieno nekādu anonimitātes garantiju un neļauj ārējam operatoram neredzēt, ka tunelis pastāv. Jebkuram apgalvojumam par to, no kā ligzdojums aizsargā, jānosauc novērotājs, no kura tas aizsargā.

Rezultāts ir īss dokuments, nevis strādājošs savienojums: kurš galapunkts izmanto kuru ceļu, kas notiek ārējas kļūmes gadījumā un trīs komandas, kas parāda pašreizējo stāvokli. strongSwan dokumentācija par pārsūtīšanu ir noderīgs avots par to, kā tuneļa trafiks tiek pārsūtīts starp saskarnēm Linux resursdatorā. Pārbaudes atkārtojiet pēc katras klienta atjaunināšanas, jo noklusējuma vērtības, kas radīja jūsu ķēdi, nav līgums. Ligzdots tunelis, ko nevarat pārbaudīt, ir bauma ar statusa gaismiņu.