Du VPN šuoliai viename Pi: kuris maršrutas neša kurį partnerį

Du tunelio adresai vienoje mažoje plokštėje atrodo kaip klaida, ir refleksas yra ištrinti vieną. Tas refleksas sulaužo tai, ką turėjo sutvarkyti. Hostas, nešantis du šuolius, laiko po vieną adresą kiekvienam prisijungimui, ir kiekvieną adresą parenka skirtingas maršrutas. Verta klausti, kuris maršrutas parenka kurį nešėją kuriai paskirties vietai, o ne kiek adresų egzistuoja.

Trys paskirties vietos, kurioms reikia skirtingų nešėjų

Dviejų šuolių grandinė yra trys sukrautos paskirties klasių grupės, ir kiekvieną neša skirtingas prisijungimas. Išorinis partneris turi būti pasiektas per fizinę jungtį. Vidinis partneris turi būti pasiektas per išorinį tunelį. Uždengtos programos paskirties vieta turi būti pasiekta per vidinį tunelį, kurio paties transportą neša išorinis.

Prieš liesdami maršrutą, užpildykite eilutes tikraisiais skaitytojo adresais, nes lentelė naudinga tik tada, kai ji konkreti. Veikianti grandinė vienu metu atitinka visas keturias eilutes, o pusiau veikianti grandinė paprastai atitinka vieną iš jų su netinkamu nešėju. Būtent neteisingos eilutės skaitymas kaip gedimo paverčia maršrutizavimo problemą visu popietės taisymu.

Adresai turi vaidmenis, o ne skaičių

Linux leidžia kelis adresus vienoje sąsajoje ir kelis tunelius viename hoste, todėl skaičius nieko nesako apie teisingumą. Svarbu tai, kuris adresas priklauso kuriam prisijungimui ir ar maršrutas konkrečiam partneriui parenka tą prisijungimą, kurį turėjote omenyje. Trys rodiniai atsako į tai iš trijų krypčių, ir verta juos skaityti ta pačia tvarka kiekvieną kartą.

Adresų inventorius parodo, kas egzistuoja ir kuris prisijungimas tai valdo. Maršrutų lentelė atsako į nešėjo klausimą įprastam paskirties srautui. Politikos rodinys atsako į jį dar kartą srautui, parinktam pagal šaltinį arba žymą, o tai įprasta tvarka, kai du klientai dalijasi vienu hostu.

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

Adreso ištrynimas todėl, kad sąrašas atrodo ilgas, gali pašalinti dalį kelio, o maršruto ištrynimas todėl, kad jis atrodo perteklinis, daro tą patį tyliau. Nė vienas nesukelia klaidos; partneris tiesiog nustoja atsakinėti tame kelyje, kurį turėjote omenyje, bet lieka pasiekiamas kitu. Programa, kuri praneša vidinio partnerio išėjimo adresą, neįrodo, kad srautas perėjo išorinį tunelį, nes tiesioginė prieiga duoda tą patį stebėjimą. Būtent šis atotrūkis tarp stebėjimo ir įrodymo yra priežastis, kodėl nešėjas tikrinamas maršrutizavimo sluoksnyje.

Aktyvavimo tvarka nugali fiksuotą laukimą

Jei vidinis klientas priklauso nuo adreso arba maršruto, kurį suteikia išorinis klientas, aktyvavimas turi laukti to resurso, o ne delsos. Laukimas veikia iki dienos, kai išorinis tunelis yra lėtas, o tada jis periodiškai sugenda taip, kad niekas negali to atkartoti. Tvarka, pagrįsta priklausomybėmis, pašalina spėjimą ir nekainuoja nieko, išskyrus priklausomybės aprašymą vieną kartą. Sąsajų pavadinimai taip pat nėra tvarkos mechanizmas.

Branduolys suteikia vardus, tokius kaip tun0 ir tun1, kūrimo tvarka, ir ši tvarka gali keistis tarp perkrovimų arba pakartotinių prisijungimų. Susiekite konfigūraciją su tapatybe, kurią suteikia įrankis, arba su vardu, kurį sąmoningai priskiriate. Vardas, kurį pasirenkate jūs, yra sutartis; vardas, kurį pasirenka branduolys, yra atsitiktinumas.

Laikykite kiekvieno kliento transportą už kito programos maršruto ribų ir būkite tikslūs dėl to, ką OpenVPN 2.6 maršrutizavimo parinktys iš tikrųjų žada. Dokumentuotas numatytojo peradresavimo mechanizmas palaiko klientą galintį pasiekti savo nuotolinį partnerį per jau egzistavusį tinklų sietuvą, o tai nutraukia vieną konkrečią rekursijos kilpą. Jis nepaverčia vieno kliento kito kliento nešėju, todėl likusi grandinės dalis lieka jūsų dizainu. Kai grandinėlės reikia politikos, o ne maršruto, parašykite aiškią šaltinio arba žymos taisyklę ir išbandykite ją su srautu, kurį ji turi atitikti.

Kas atsitinka, kai išorinis šuolis miršta

Prieš laikant grandinę užbaigta, nuspręskite, kas atsitinka, kai išorinis šuolis dingsta. Vidinio kliento transportas miršta kartu su juo, o kitas žingsnis yra politikos, o ne technikos klausimas: žlugti, bandyti dar kartą arba tiesiogiai prisijungti per fizinę jungtį. Būtent trečiasis rezultatas yra tas, apie kurį verta pagalvoti. Jis tyliai paverčia dviejų šuolių dizainą vieno šuolio dizainu tuo momentu, kai vartotojas tiki, kad aprėptis dar nepažeista.

Jei du šuoliai yra privalomi, vidinis klientas neturi galėti sukurti tiesioginio kelio, kai išorinis dingęs, o būdas tai sužinoti yra nutraukti išorinį šuolį ir stebėti, ką daro vidinis. Patvirtintas atsarginis planas yra teisėtas atsakymas, bet jis turi būti užrašytas, išbandytas ir praneštas. Atsarginis planas, kurio niekas nedokumentavo, incidento peržiūroje nesiskiria nuo nuotėkio.

DNS ir kita adresų šeima priklauso tam pačiam sprendimui. Vietoje sugeneruota užklausa laikosi paties hosto politikos, o ne persiųsto kliento, todėl sprendėjas, kuris veikia persiųstam srautui, gali būti ne tas, kurį naudoja pats hostas.

Priimkite kiekvieną sluoksnį ta tvarka, kuria jį statėte

Bandykite ta tvarka, kuria grandinė buvo statoma: pirmiausia vien tik išorinis tunelis, tada vidinio kliento transportas per išorinį tunelį, tada programa per vidinį tunelį. Kiekvienas priėmimas turi būti naujas ryšys, o ne jau atidarytas puslapis. Tada atskirai nutraukite ir atkurkite kiekvieną sluoksnį ir stebėkite, ką daro kitas.

Atsarginio plano rezultatas čia yra vertingiausias stebėjimas ir tas, kurio viešo IP puslapis niekada nerodo. Išsaugokite partnerių kelius, jų naudojamus adresus ir tą rezultatą šalia konfigūracijos, nes laimingas kelias nėra ta dalis, kuri vėliau kvestionuojama.