Du paslaugų adresai viename OpenVPN kliente: iroute ir lo

Programa atsako savo tunelio adresu, o adresas, kurį jai dokumentavote, niekur neveda. OpenVPN žurnale niekas nesiskundžia, partneris rodomas prisijungęs, o centras išvardija tiksliai vieną klientą. Spraga ta, kad antrasis adresas kliente yra du atskiri faktai: prieglobai jis turi priklausyti, o centras turi žinoti, kuriam partneriui jis priklauso. Tvarkykite vieną be kito ir srautas arba miršta centre, arba atvyksta be kelio namo.

Slapyvardis vietinis, nuosavybė nuotolinė

Dėl tunelio adreso deramasi, todėl abu galai jį sužino per rankos paspaudimą. Dėl papildomo paslaugos adreso visai nesiderama, todėl jo pridėjimas savaime centre nieko nekeičia. Klientas gali iš karto turėti adresą, o serveris vis tiek siųs tą srautą savo numatytuoju keliu arba jį išmes. Reikia sukurti du įrašus dviejose skirtingose vietose.

Kliente adresas priklauso prieglobai, o loopback yra natūralūs namai paslaugos tapatybei, kuri niekada neturėtų pasirodyti fizinėje jungtyje. Centre partnerio susiejimas su priešdėliu yra atskira deklaracija, kurią skaito tik serveris. Nė vienas įrašas neimplikuoja kito.

Laikykite abu diapazonus atskirai ir savo užrašuose. Pavyzdžio adresai yra dokumentacijos reikšmės, o jų persidengimas su tikru LAN yra greičiausias būdas priversti veikiančią sąranką atrodyti sugedusia.

Pridėkite adresą kliente visam laikui

Įdėkite paslaugos adresą į loopback su prieglobos priešdėliu, kad priegloba jį traktuotų kaip vietinę įvestį, o ne kaip pasiekiamą potinklį. ip address add 10.66.0.10/32 dev lo tai daro vienam adresui, o komandos kartojimas antram adresui modeliuoja dvi paslaugas.

Paleiskite tai kaip vienkartinį testą, tada perkelkite į tai, kas valdo prieglobos tinklo konfigūraciją, nes vykdymo metu pridėtas dalykas dingsta perkraunant, o dublikatai kaupiasi tarp prisijungimų. Už tinklo eilės tvarka išdėstytas systemd vienetas yra viena parinktis, o distribucijos tinklo tvarkyklė yra kita. Kad ir ką pasirinktumėte, adresas turi egzistuoti prieš programai susiejant, kitaip paslauga kils netinkamame lizde. Patikrinkite su ip address show dev lo po perkrovimo, o ne po rankinės komandos.

Susiejimas yra atskiras sprendimas nuo adresavimo. Programa, kuri klausosi kiekvieno adreso, priima srautą sąsajose, kurių niekada neketinote, todėl nukreipkite ją į konkretų paslaugos adresą. Tada vietinė įvesties taisyklė turi ką tiksliai atitikti.

Pareikalaukite jo CCD faile, kurį centras iš tikrųjų skaito

Serveryje nuosavybės deklaracija patenka į kiekvieno kliento failą, kurį parenka autentifikuotas bendrasis vardas, kataloge, kurį nurodo client-config-dir. Eilutė yra iroute 10.66.0.10 255.255.255.255, po vieną adresui, ir ji pasako serveriui, kuris partneris turi gauti to maršruto srautą.

Dvi detalės tai tyliai sugriauna. Failo vardas turi atitikti vardą, kurį serveris iš tikrųjų naudoja, o jis skiriasi, kai dalyvauja username-as-common-name. Ir iroute veikia tik TUN režimu su sukonfigūruotu kliento konfigūracijos katalogu, todėl ta pati eilutė nieko nedaro sujungtoje diegimo aplinkoje. Pridėkite eilučių prie esamo failo, o ne pakeiskite jį, nes jame jau gali būti fiksuotas adresas arba push parinktys. OpenVPN 2.6 žinynas dokumentuoja ir katalogą, ir nuosavybės direktyvą.

Centro branduoliui taip pat reikia kelio į tuos tikslus, kad vietoje sukurtas srautas patektų į tunelio procesą. Serverio konfigūracijoje route 10.66.0.10 255.255.255.255 apima srautą, kurį sukuria pats serveris, o kitiems klientams reikia push "route 10.66.0.10 255.255.255.255", kad patys sužinotų tikslą.

Maršrutizavimas ir autorizacija lieka atskiri. Stumiamas maršrutas pasako klientui, kur siųsti paketus, ir nieko nesuteikia; paslauga vis tiek turi priimti skambintoją savo sąlygomis.

Patikrinkite įvesties taisyklę ir atsakymo kelią

Į slapyvardį adresuotas paketas pasiekia jį turinčią prieglobą kaip vietinę įvestį, todėl klausimas, ar vietinė ugniasienė leidžia tą šaltinį ir prievadą. Leiskite konkretų paslaugos prievadą iš VPN šaltinio diapazono, o ne atverkite visą adresą.

Atsakymams reikia kelio atgal į skambintoją. Skambintojui įprastame tunelių telkinyje tas kelias jau egzistuoja, nes jį neša tunelio įrenginys. Skambintojui už kitos maršrutizuotos tinklo dalies reikia ir tos tinklo dalies grįžimo maršruto, ir būtent čia asimetrinės sąrankos pameta paketus.

Stebėkite antrą klausytoją tame pačiame prievade, susietą su kitu adresu, nes branduolys pristato tam lizdui, kuris atitinka, ir rezultatai atrodo atsitiktiniai. Patikrinkite su ss -lntp ir patvirtinkite, kad susietas adresas yra paslaugos slapyvardis. Šaltinio NAT čia nereikia, o jo pridėjimas paslepia skambintojo tapatybę, nuo kurios priklauso jūsų žurnalai.

Tikrinkite adresus ir nuosavybę atskirai

Tikrinkite dviem žingsniais. Pirmiausia patvirtinkite, kad nuosavybę turinti priegloba gali pasiekti paslaugą savo slapyvardžiu iš savęs, o tai atskiria susiejimo ir ugniasienės problemas nuo maršrutizavimo. Tada tikrinkite iš tikro VPN skambintojo naudodami pačios programos autentifikaciją. Kai pirmasis praeina, o antrasis nepavyksta, trūkstama dalis yra centro pusėje.

Patikrinkite ir gedimo būdus, kurie išlieka po ryšio: slapyvardis lieka priskirtas, kai tunelis išjungtas, o centras išsaugo savo maršrutą, kai partnerio nėra. Nė vienas objektas vienas neįrodo, kad paslauga pasiekiama, todėl dviejų žingsnių testas nugali vieną ping iš nešiojamojo kompiuterio.