Įdėtasis VPN: kuris tunelis neša išorinį ryšį?

Du vienu metu veikiantys VPN klientai nesukuria įdėtojo tunelio; jie sukuria du tunelius ir ginčą dėl maršrutizavimo. Įdėtasis tunelis egzistuoja, kai vidinio kliento ryšį su savo serveriu pats neša išorinis tunelis, ir tai yra sąranka, kuri sukuriama tyčia. Jei viskas teisinga, vidinis serveris mato išorinio serverio adresą; jei ne, vienas klientas tyliai persijungia aplink kitą. Trys sąlygos sprendžia, ar įdėjimas tikras, ar atsitiktinis.

Trys sąlygos sprendžia įdėjimą

Pirmoji yra kokio galinio taško kurio kelio reikia. Įvardykite vidinio serverio adresą, įvardykite išorinio serverio adresą ir aiškiai nurodykite, kad vidinis serveris pasiekiamas tik per išorinį tunelį. Visa kita išplaukia iš to sakinio, įskaitant tai, kurie maršrutai priklauso kuriai lentelei.

Antroji yra ar matote kelią kiekviename sluoksnyje. Jei negalite paklausti branduolio, kokį maršrutą naudotų konkretus tikslas, grandinę darote iš galutinio išėjimo IP, ir tai yra būtent tas įrodymas, kuris negali atskirti įdėjimo nuo atsitiktinumo.

Trečioji yra kas atsitinka, kai išorinis tunelis nukrenta. Vidinis tunelis gali sustoti kartu su juo, persijungti per įprastą tinklą arba likti užblokuotas, kol išorinis kelias grįš, ir visi trys variantai yra apginamos politikos. Tai ne ta pati politika, o daugumos klientų numatytasis elgesys yra antrasis. Klientas, kuris persijungia savo galinį tašką per fizinį tinklą, rodydamas sveiką ryšį, yra dažniausias būdas, kuriuo sumanyta grandinė tyliai tampa dviem nesusietais tuneliais.

Pirmoji sąlyga: kokio galinio taško kurio kelio reikia

ip route get 203.0.113.10 atsako į šį klausimą tiesiogiai: atspausdina maršrutą, šaltinio adresą ir sąsają, kurią branduolys naudotų tam tikslui dabar.

Paleiskite ją vidiniam serveriui prieš pradedant vidinį klientą ir dar kartą po to, tada palyginkite. Jei atsakymas pasikeičia iš fizinės sąsajos į išorinio tunelio sąsają, įdėjimas tuo metu yra tikras. Jei jis nesikeičia, vidinis klientas jungiasi tiesiogiai, ką bebūtų sakoma skydelyje. Pakartokite išorinio serverio adresui, kuris vis tiek turi būti sprendžiamas per fizinę sąsają, nes maršrutas, rekursyviai užfiksuojantis abu galinius taškus, yra gedimas, visiškai atjungiantis mašiną nuo tinklo.

Antroji sąlyga: patikrinkite kelią kiekviename sluoksnyje

Maršruto parinkimas moderniame kliente yra daugiau nei pagrindinė lentelė. Politikos taisyklės gali siųsti pažymėtus paketus į kitą lentelę, klientas gali pririšti savo lizdą prie sąsajos, o konteineris ar vardų erdvė turi savo lenteles. ip rule ir ip route show table all yra būdas sužinoti, kuris iš šių mechanizmų veikia.

Klientas, kuris savo lizdui nustato SO_MARK arba yra sukonfigūruotas prisirišti prie konkretaus įrenginio, apeina numatytąjį maršrutą, kurį, kaip manėte, sutvarkėte. Tai funkcija, o ne klaida, ir tai reiškia, kad vienintelė patikima patikra yra ta, kuri vykdoma toje pačioje vardų erdvėje kaip klientas. Jei klientai veikia konteineriuose, patikras vykdykite tuose konteineriuose, o ne pagrindiniame kompiuteryje.

Trečioji sąlyga: kas atsitinka, kai išorinis tunelis nukrenta

Elgesys gedimo atveju reikalauja sprendimo, o ne numatytosios reikšmės. Užrašykite, kas turi atsitikti vidiniam tuneliui, kai išnyks išorinis, ir tada priverskite klientus taip daryti.

Variantai konkretūs. Vidinio kliento sustabdymas, kai išnyksta išorinis kelias, duoda švarią grandinę ir akivaizdų sutrikimą. Leidimas jam jungtis tiesiogiai duoda prieinamumą ir tyliai pašalina savybę, dėl kurios buvo statoma grandinė. Blokavimas iki išorinio kelio grįžimo yra griežčiausias ir eksploatuoti nemaloniausias variantas, nes kiekvienas išorinio tunelio svyravimas tampa matomu incidentu.

Išbandykite visus tris su nekenksmingu srautu ir tyčiniu išorinio tunelio gedimu, nes konfigūracijos skaitymas nepasakys, kurį turite. Užmuškite išorinį tunelį, stebėkite, ką daro vidinis klientas, ir dar kartą patikrinkite maršrutą, kol jis neveikia. Tada grąžinkite išorinį tunelį ir patvirtinkite, kad grandinė vėl susidaro, o ne palieka vidinį klientą tiesiame kelyje, kurį jis pasirinko tuo metu.

Ko grandinė neduoda

Papildomi sluoksniai prideda galinius taškus, raktus ir gedimų režimus; jie neprideda jokios anonimiškumo garantijos ir neleidžia išoriniam operatoriui nematyti, kad tunelis egzistuoja. Bet koks teiginys apie tai, nuo ko saugo įdėjimas, turi įvardyti stebėtoją, nuo kurio jis saugo.

Rezultatas yra trumpas dokumentas, o ne veikiantis ryšys: kuris galinis taškas naudoja kurį kelią, kas atsitinka išorinio gedimo metu ir trys komandos, rodančios dabartinę būseną. strongSwan dokumentacija apie persiuntimą yra naudingas šaltinis apie tai, kaip tunelio srautas persiunčiamas tarp sąsajų Linux hoste. Vėl paleiskite patikras po kiekvieno kliento atnaujinimo, nes numatytosios reikšmės, sukūrusios jūsų grandinę, nėra sutartis. Įdėtasis tunelis, kurio negalite patikrinti, yra gandas su būsenos indikatoriumi.