OpenVPN serveris ir klientas tame pačiame hoste: kodėl klientai atkrenta

Pridėkite kliento profilį prie mašinos, kurioje jau veikia VPN serveris, ir pirmoji auka bus pradinė paslauga. Naujas tunelis gali niekada neatsirasti arba iškilti, kai serverio turimi klientai tyliai nustoja gauti atsakymus. Dvi kolizijos duoda abu rezultatus: jau naudojamas tunelių baseinas ir naujos kliento pusės įdiegtas numatytasis maršrutas, apimantis visą lentelę. Nė viena nesukuria OpenVPN klaidos pranešimo, todėl gedimas skaitomas kaip serverio problema.

Viena mašina, dvi rolės ir du nesuderinami atsakymai, kur turi eiti atsakymai.

Tas pats baseinas, du serveriai: kas laimi

Kiekvienai serverio kopijai reikia savo tunelio potinklio. Nukopijavus eilutę kaip server 10.8.0.0 255.255.255.0 į antrą konfigūraciją, abi kopijos gauna tą patį prefiksą, o rezultatas yra arba atsisakymas startuoti, arba tyli kova, kurioje vieno serverio klientai gauna adresus, kuriuos kitas taip pat laiko savais. Skirtingi UDP prievadai ir skirtingi įrenginių pavadinimai nepadeda, nes nė vienas neliečia adresų erdvės. Pakeiskite antrą baseiną ir pakeiskite jį visur, kur maršrutai jį mini.

Surašykite, kas veikia, prieš redaguodami: ip -4 addr show išvardija tunelių įrenginius, ss -lunp išvardija klausytojus, o systemctl list-units įvardija unitus. Vienas žvilgsnis į tunelių adresus nusprendžia, ar baseinai susiduria.

Ką kliento profilis prideda lentelei

Kliento pusė rašo maršrutus iškart, kai prisijungia. redirect-gateway def1 padalija numatytąjį maršrutą į 0.0.0.0/1 plius 128.0.0.0/1, abu nukreipiami per naują įrenginį, kartu su hosto maršrutu į tolimą serverį, kuris sąmoningai prisegtas prie fizinės sąsajos. Šis prisegimas egzistuoja tam, kad tunelis išlaikytų kelią savo transportui. Visa kita, įskaitant atsakymus, kuriuos vietinis serveris skolingas savo klientams, dabar seka naująjį numatytąjį maršrutą ir išeina per tolimąją jungtį.

Taigi antroji kolizija nėra sulaužytas tunelis. Tai veikiantis tunelis netinkamoje lentelės vietoje.

Trys būdai atskirti roles

Mažiausiai invazyvus pataisymas pašalina numatytąjį maršrutą iš kliento profilio: route-nopull plius aiškios route eilutės tolimiesiems prefiksams, kad vietinė lentelė keistųsi tik ten, kur paprašėte. Kitas žingsnis — politikos taisyklė, išimanti vietinį tunelio potinklį ir leidžianti atsakymams vietiniams klientams išeiti per sąsają, kuria jie atėjo, net kai egzistuoja numatytasis maršrutas. Išsamiausias sprendimas — atskira tinklo vardų erdvė kliento rolei, kuri visiškai pašalina bendrą lentelę ir kainuoja antrą maršrutizavimo kontekstą prižiūrėti.

Kad ir kokį kelią pasirinktumėte, išimtis turi įvardyti vietinį tunelio potinklį, o ne LAN. Vietinio serverio siunčiamo atsakymo paskirties vieta yra tunelio adresas, todėl LAN formos išimtis niekada jam netinka.

Kuris iš dviejų kopijų kaltas

Sustabdykite kliento kopiją ir dar kartą patikrinkite pradinius klientus. Jei atsistato iš karto, tai maršrutizavimas, o ne serveris. Įjunkite klientą atgal ir sekite vieną atsakymą su ip route get, kuriam duotas ir šaltinio, ir paskirties adresas, tai parodo kelią, kurį pasirinktų branduolys, o tada stebėkite sąsają, kurią paketai tikrai naudoja, su tcpdump -ni any port 1194. Serverio būsenos failas, rašomas kas kelias sekundes per status direktyvą, turi prisijungusių klientų sąrašą ir baitų skaitiklius abiem kryptimis.

Skaitykite tuos skaitiklius vieną prie kito. Srautas, kuris išeina ir niekada negrįžta, yra maršrutizavimo atsakymas, o ne rankos paspaudimo problema.