Kam vajadzētu piederēt maršrutiem un DNS, kad openfortivpn pievienojas?

Strādājošā openfortivpn sesijā četri posmi slāņojas viens uz otra. Klients autentificējas pie vārtejas un sāk TLS savienojumu, pēc tam tajā savienojumā palaiž PPP, pēc tam saņem adresi un DNS informāciju, un visbeidzot piemēro resursdatora maršrutus un resolvera iestatījumus. Katrs posms var būt dzīvs, kamēr nākamais nav, un tāpēc “pievienots” atbalsta sarunās ir tik slidens vārds.

Lēmums, kas novērš lielāko daļu neskaidrības, ir tas, kam pieder pēdējais posms. Vai nu VPN klients pats piemēro resursdatora izmaiņas, vai to dara cita komponente, un abu sajaukšana uz pusceļa ir iemesls, kāpēc maršruti un resolvera faili galu galā apraksta dažādas sesijas.

Četri posmi, kas izskatās kā viens savienojums

Pirmais posms ir uzņemšana. nosaukts autentifikācijas domēns vai vienreizēju kodu, un saņem turpināšanai nepieciešamos parametrus. Kad klients izdrukā, ka ir pievienots vārtejai, tas nozīmē, ka TLS transports darbojas. Tas nenozīmē, ka PPP ir vienojies, un noteikti nenozīmē, ka iekšēja lietojumprogramma ir sasniedzama.

Otrais posms ir PPP saite. Klients palaiž PPP procesu pret tuneļa ierīci, un abas puses vienojas par saites opcijām un adresēm. Tikai pēc tam resursdators zina, kādas vietējās un attālās adreses sesija izmanto, un tikai tad maršrutam uz tuneli var būt jēga.

Trešais posms ir šīs informācijas piemērošana resursdatoram, un šeit ir svarīgas īpašumtiesības. Klients var pievienot maršrutus un pārrakstīt resolvera konfigurāciju, vai tam var likt atkāpties un atstāt abus tam, kas citādi pārvalda tīklu tajā mašīnā. Projekta README fails to apraksta kā atsevišķus pienākumus, nevis vienu automātisku uzvedību.

Kas rediģē maršrutēšanas tabulu

Pēc noklusējuma īpašnieks ir klients. Tas pievieno maršrutu uz vārteju caur fizisko saskarni, maršrutu tuneļa partnerim un maršrutus tīkliem, kuras sesijai ir atļauts izmantot, un pēc tam noņem tos, kad process beidzas. Šis noklusējums ir ērts klēpjdatorā ar vienu tīkla pārvaldnieku un bez citas VPN programmatūras.

Izvēlieties nodošanu tikai tad, kad kaut kas cits patiešām pārvalda maršrutēšanu. Tīkla pārvaldnieka integrācija, konteinera tīkla vārdu telpa vai visas vietnes maršrutēšanas aģents jau var zināt, kā instalēt un notīrīt tos pašus prefiksus. Tad no-routes opcijas nodošana neļauj diviem rakstītājiem cīnīties par vienu un to pašu tabulu, kas ir sacensība, kura izpaužas kā periodisks viena apakštīkla zudums, nevis kā tīra kļūme.

Pārklāšanās ir otrais nodošanas iemesls. Ja uzstumtie maršruti ietver prefiksu, ko vietējais tīkls jau izmanto, klients nevar atrisināt konfliktu jūsu vietā. Kādam ir jāizlemj, vai šis prefikss ir sasniedzams caur tuneli, caur fizisko saiti vai caur konkrētāku maršrutu, un šis lēmums pieder tam, kam pieder topoloģija.

Tīrīšana ir trešā. Klients, kas avarē pirms savu maršrutu noņemšanas, atstāj melnu caurumu, kas pārdzīvo sesiju, un nākamais savienojums var tam virsū pievienot dublikātu. Kam pieder maršrutēšana, tam pieder arī pārbaude, ka vecie ieraksti ir pazuduši. Padariet šo pārbaudi starta ceļa daļu, nevis neobligātu tīrīšanas soli.

Kam pieder DNS un resolvera fails

DNS ir tas pats lēmums ar asākām malām. Klients var pieņemt DNS serverus, ko ziņo vārteja vai PPP partneris, un ierakstīt tos resursdatora resolvera konfigurācijā. Vienkāršā mašīnā tas ir tieši tas, ko vēlaties, jo iekšējie nosaukumi tad tiek atrisināti tikai tik ilgi, kamēr tunelis ir aktīvs.

Mūsdienu Linux resursdatorā resolveru var pārvaldīt vietējais stub, un resolvera faila pārrakstīšana aiz šī stub muguras rada konfigurāciju, kas izskatās pareiza un uzvedas nekonsekventi. Ja resursdators jau palaiž resolvera pārvaldnieku, ļaujiet tam piederēt DNS un padodiet tam tuneļa serverus caur tā atbalstīto saskarni. Klienta no-dns opcija tur ir pareizā izvēle, nevis apietais ceļš.

Sadalītais DNS ir atsevišķs jautājums no tā, kas raksta failu. Sūtīt katru vaicājumu caur tuneli ir vienkārši un lēni; sūtīt caur to tikai iekšējās zonas prasa konfigurāciju katram domēnam, ko lielākā daļa vienkāršo klientu nepiedāvā. Izlemiet, kāda uzvedība resursdatoram nepieciešama, pirms iespējojat klienta resolvera izmaiņas. Nepareiza izvēle šeit izskatās kā nosaukumu atrisināšanas pārtraukums pat tad, ja pats tunelis ir kārtībā.

Privilēģijas, gatavība un nodošana

Tuneļa ierīces izveide un resursdatora maršrutu vai resolvera stāvokļa rediģēšana prasa paaugstinātu tīkla autoritāti. Bieža kļūda ir secināt, ka tāpēc visam jādarbojas kā root, tostarp pārlūkam vai lietojumprogrammai, kas izmanto tuneli. Turiet priviliģēto daļu mazu: klients un tā konfigurācijas fails administratora īpašumā, kamēr lietotāja lietojumprogrammas saglabā savu parasto kontu.

Gatavība jādefinē katram patērētājam. Uzraugs var uzskatīt pakalpojumu par sāktu, kad klienta process darbojas un tuneļa ierīce pastāv. Dublēšanas uzdevumam VPN jāuzskata par lietojamu tikai tad, kad tā krātuves galapunkts atbild caur tuneli. Tie ir dažādi pārbaudījumi, un vājākā izmantošana stiprākam mērķim rada uzdevumus, kas sākas pārāk agri un periodiski neizdodas. Pierakstiet izvēlēto definīciju, jo uzraugs un uzdevums, kas nepiekrīt par gatavību, ir atbalsta biļete, kas gaida notikšanu.

Pārbaudiet līgumu ar četriem novērojumiem: vārtejas posms pabeidzas, PPP piešķir adreses, paredzētais maršruts ir, un pieprasījums iekšējam resursdatoram izdodas. Pēc tam apturiet klientu un apstipriniet, ka katrs no tiem ir noņemts vai atjaunots. Ja pēc tuneļa aizvēršanas resursdators joprojām atrisina iekšējos nosaukumus vai joprojām tur maršrutu, īpašumtiesību nodošana nav pilnīga.