Kaks VPN-hüpet ühel Pi-l: milline marsruut kannab millist partnerit

Kaks tunneliaadressi ühel väikesel plaadil näivad veana ja refleks on üks kustutada. See refleks rikub selle, mida ta pidi korrastama. Kahte hüpet kandev host hoiab ühe aadressi liidese kohta ja iga aadressi valib erinev marsruut. Küsimus, mida tasub küsida, on see, milline marsruut valib millise kandja millise sihtkoha jaoks, mitte kui palju aadresse olemas on.

Kolm sihtkohta, mis vajavad erinevaid kandjaid

Kahe hüppe kett on kolm kihiti asetatud sihtkohtade klassi ja igaüht kannab erinev liides. Välimise partnerini tuleb jõuda füüsilise lingi kaudu. Sisemise partnerini tuleb jõuda välimise tunneli kaudu. Kaetud rakenduse sihtkoht peab olema saavutatud sisemise tunneli kaudu, mille oma transporti kannab välimine.

Täitke read lugeja tegelike aadressidega enne marsruudi puudutamist, sest tabel on kasulik ainult siis, kui see on konkreetne. Töötav kett rahuldab kõiki nelja rida korraga ja pooltöötav kett rahuldab tavaliselt ühte neist vale kandjaga. Just vale rea lugemine veana muudab marsruutimisprobleemi terveks pärastlõunaks parandusi.

Aadressidel on rollid, mitte arv

Linux lubab ühel liidesel mitut aadressi ja ühel hostil mitut tunnelit, nii et arv ei ütle õigsuse kohta midagi. Oluline on, milline aadress kuulub millisele liidesele ja kas antud partneri marsruut valib liidese, mida te mõtlesite. Kolm vaadet vastavad sellele kolmest suunast ja neid tasub lugeda iga kord samas järjekorras.

Aadresside loend näitab, mis on olemas ja milline liides seda omab. Marsruutide tabel vastab kandja küsimusele tavalise sihtkohaliikluse puhul. Poliitikavaade vastab sellele uuesti allika või märgise järgi valitud liikluse puhul, mis on tavaline korraldus, kui kaks klienti jagavad ühte hosti.

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

Aadressi kustutamine, sest nimekiri tundub pikk, võib eemaldada osa teest, ja marsruudi kustutamine, sest see tundub üleliigne, teeb sama vaiksemalt. Kumbki ei tekita viga; partner lõpetab lihtsalt vastamise teel, mida te kavatsesite, jäädes samal ajal teise kaudu kättesaadavaks. Rakendus, mis teatab sisemise partneri väljumisaadressi, ei tõesta, et liiklus läbis välimise tunneli, kuna otsene juurdepääs annab sama vaatluse. Just see lõhe vaatluse ja tõestuse vahel on põhjus, miks kandjat marsruutimiskihis kontrollitakse.

Aktiveerimise järjekord võidab fikseeritud une

Kui sisemine klient sõltub aadressist või marsruudist, mille välimine klient pakub, peab aktiveerimine ootama seda ressurssi, mitte viivitust. Uni töötab kuni päevani, mil välimine tunnel on aeglane, ja siis ebaõnnestub see aeg-ajalt viisil, mida keegi ei suuda korrata. Sõltuvuspõhine järjestamine eemaldab oletuse ja ei maksa midagi peale sõltuvuse ühekordse kirjeldamise. Ka liidesenimed ei ole järjestusmehhanism.

Kernel jagab nimesid nagu tun0 ja tun1 loomise järjekorras ja see järjekord võib taaskäivituste või uuesti ühendamiste vahel muutuda. Siduge konfiguratsioon identiteediga, mille tööriist pakub, või nimega, mille teadlikult määrate. Nimi, mille te valite, on leping; nimi, mille kernel valib, on juhus.

Hoidke iga kliendi transport teise rakenduse marsruudist väljas ja olge täpne selles, mida OpenVPN 2.6 marsruutimisvalikud tegelikult lubavad. Dokumenteeritud vaikimisi ümbersuunamise mehhanism hoiab kliendi suutlikuna jõuda oma kaugpartnerini juba olemas olnud lüüsi kaudu, mis lõikab läbi ühe konkreetse rekursioonisilmuse. See ei muuda ühte klienti teise kliendi kandjaks, nii et ülejäänud kett jääb teie kujunduseks. Kus kett vajab marsruudi asemel poliitikat, kirjutage selgesõnaline allika- või märgisureegel ja testige seda liiklusega, millega see peaks sobima.

Mis juhtub, kui välimine hüpe sureb

Enne kui kett loetakse täielikuks, otsustage, mis juhtub, kui välimine hüpe kaob. Sisemise kliendi transport sureb koos sellega ja järgmine samm on poliitika, mitte tehnika küsimus: ebaõnnestuda, uuesti proovida või ühenduda otse füüsilise lingi kaudu. Just kolmas tulemus on see, mille üle tasub mõelda. See muudab vaikselt kahe hüppe kujunduse ühe hüppe kujunduseks hetkel, mil kasutaja usub, et kate on veel puutumata.

Kui kaks hüpet on kohustuslikud, ei tohi sisemine klient suuta luua otsest teed, kui välimine on kadunud, ja selle teadasaamise viis on välimine hüpe katki teha ja vaadata, mida sisemine teeb. Kinnitatud varuplaan on seaduslik vastus, kuid see tuleb kirja panna, testida ja teatada. Varuplaan, mida keegi ei dokumenteerinud, ei erine juhtumi ülevaatamisel lekkest.

DNS ja teine aadresside perekond kuuluvad sama otsuse juurde. Kohapeal loodud päring järgib hosti enda poliitikat, mitte edastatud kliendi oma, nii et edastatud liikluse jaoks töötav resolver ei pruugi olla see, mida host ise kasutab.

Võtke iga kiht vastu selles järjekorras, milles te selle ehitasite

Testige selles järjekorras, milles kett ehitati: kõigepealt üksi välimine tunnel, seejärel sisemise kliendi transport läbi välimise tunneli, seejärel rakendus läbi sisemise tunneli. Iga vastuvõtt peab olema värske ühendus, mitte juba avatud leht. Seejärel katkestage ja taastage iga kiht eraldi ning jälgige, mida teeb järgmine.

Varuplaani tulemus on siin kõige väärtuslikum vaatlus ja see, mida avaliku IP leht kunagi ei näita. Salvestage partnerite teed, nende kasutatavad aadressid ja see tulemus konfiguratsiooni kõrvale, sest õnnelik tee ei ole see osa, mida hiljem kahtluse alla seatakse.