Kurš komponents īsti pārvalda OpenVPN maršrutu limitu?
Maršrutu limits var piederēt OpenVPN dzinējam, NetworkManager spraudnim vai serverim. Nosauciet īpašnieku, pirms rediģējat profilu vai paaugstināt skaitli.
Profils ar divsimt maršrutiem strādā vienā mašīnā un otrā uzstāda četrdesmit. Dzinējam, to palaidošajai integrācijai un to barojošajam serverim katram ir savs vārds, un katrs var apturēt sarakstu citā vietā. Bojājuma lasīšana kā viena limita noved pie nepareizā faila. Mehānismam ir trīs posmi, un apstājies posms atstāj redzamas pēdas, kad zināt, ko meklēt.
Trīs posmi, trīs dažādi limiti
Vispirms dzinējs analizē opciju un izlemj, vai šī versija to saprot. Pēc tam integrācija uzstāda to, ko dzinējs ziņo, un tās pašas kods var ierobežot vai pārveidot sarakstu. Beigās serveris izlemj, cik maršrutu tas nosūtīs konkrētai identitātei, pirms jebkurš klienta posms kaut ko redz. Trīs posmi, trīs griesti, un tikai viens no tiem ir skaitlis profilā.
Vienu griestu paaugstināšana neko nedara pārējiem. Noraidīts nosūtīts maršruts var būt servera politikas lēmums, klienta atrisināta pārklāšanās vai uzstādītāja limits, kas izmeta pārpalikumu. Katram no šiem ir cits labojums.
Atdaliet trīs, pirms kaut ko mērīt. Parsētāja kļūda nosauc marķieri, uzstādītāja limits atstāj īsu maršrutu tabulu, un politikas lēmums neatstāj neko. Pēdas pasaka, kuru posmu pārbaudīt vispirms.
| Stage | Who decides | What you can see |
|---|---|---|
| Parse | Client engine | An error naming the option |
| Install | Activation owner | A route count below the pushed count |
| Offer | Server policy | A route absent from the pushed list |
Parsētājs runā pirmais
Nezināma opcija neizdodas skaļi un agri, un kļūdas teksts nosauc marķieri. Tas ir visvieglāk atpazīstamais posms: salīdziniet precīzo ziņojumu ar uzstādīto dzinēja versiju, jo vienā laidienā pievienota opcija iepriekšējā nav zināma. Profils, kas nokopēts no jaunākas izvietošanas, ir ierastais šīs neatbilstības avots. Parsētājs nekad klusām neignorē direktīvu, kuru tas neatpazīst.
Pieņemta opcija neko nepasaka par rezultātu. Analīze izdodas, un sarakstu tomēr var apgriezt uzstādītājs vai arī serveris to var nekad nepiedāvāt. Uzskatiet tīru analīzi par atļauju turpināt, nevis par pierādījumu.
Pierakstiet versijas virkni no binārā faila, kas tiešām darbojās, nevis no pakotņu pārvaldnieka priekšstata par to, kas ir uzstādīts. Šie divi nesaskan biežāk, nekā sagaidāms.
Uzstādītājam ir savi griesti
Komponents, kuram pieder aktivizācija, var būt NetworkManager spraudnis, nevis dzinēja binārais fails, un tas var uzlikt savu limitu, pirms eksistē jebkurš tunelis. Tā redaktors var rādīt lauku, kuru strādājošais dzinējs nekad nelasa, vai lasīt lauku, kuru redaktors nerāda. Abas situācijas no ārpuses izskatās kā klienta kļūda. Nevienu neizlabo profila rediģēšana.
Skaitiet, kas ieradās, nevis kas tika konfigurēts. Komanda ip route show dev tun0 uzskaita uzstādītos maršrutus, un šī skaitļa salīdzināšana ar nosūtīto sarakstu atdala izmesto maršrutu no tā, kas nekad netika nosūtīts. Skaitlis, kas atbilst nosūtīšanai, novirza aizdomas atpakaļ uz serveri.
Apvalks ap dzinēja bināro failu, lai piespiestu lielāku skaitli, aizmiglo atjauninājumus un pārvērš atritināšanu minējumos. Tas arī slēpj īsto limitu no katra, kas lasīs konfigurāciju nākamreiz.
Serveris izlemj, ko jums piedāvāja
Politika katram klientam var samazināt sarakstu pirms pārraides. Klientam specifisks fails var pievienot maršrutus vienai identitātei, vai grupas politika var tos izlaist, un klients nevar atšķirt filtrētu maršrutu no tā, kas nekad netika definēts. Tieši šī neskaidrība padara servera ierakstu svarīgu. Pieprasiet faktisko sūtīšanas sarakstu šai identitātei, nevis veidni.
Salīdziniet servera ierakstu ar saņemto sarakstu. Starpa starp tiem ir politikas slānis, un tā parasti ir mazāka, nekā profils liek domāt.
Kad dizains to atļauj, apkopojiet blakus esošos tīklus un dzēsiet novecojušos ierakstus. Mazāk un lielāku maršrutu atrisina vairāk gadījumu nekā augstāki griesti.
Mainiet skaitli pareizajā vietā
Izmantojiet dokumentēto tā komponenta iestatījumu, kuram limits patiešām pieder. Ja lauks spraudnī nav, pārbaudiet, vai spraudnis ir vecāks par funkciju vai arī maršrutus pārvalda cita pamatne. Pēc tam dokumentējiet dzinēja, spraudņa un servera versijas blakus izvēlētajai vērtībai. Nākamais atjauninājums no jauna atver jautājumu, un tieši piezīme padara to atbildamu.
Pārbaudiet vēlreiz pēc jebkura no trim atjauninājuma. Pareizajā vietā paaugstināts limits tomēr pārvietojas, kad mainās to īstenojošais komponents. Versiju ieraksts ir vienīgais, kas šo kustību padara paredzamu.