Jūs startējat klientu sāknēšanas laikā, vienība ziņo, ka ir aktīva, un tuneļa nav. Dabīgs secinājums ir, ka pakalpojums neiesākās, un dabīgs labojums ir to startēt vēlreiz. Abi ir pietiekami bieži nepareizi, lai būtu vērts noteikums: strādājošs klients, kas atkārto mēģinājumus, no ārpuses izskatās tieši kā salūzis. Atšķirība ir tajā, ko dara process, nevis vienības stāvoklī.

Mīts: startēts pakalpojums nozīmē strādājošu tuneli

Aktīva vienība pierāda, ka process tika startēts un nav beidzies. Tā nepierāda, ka profils tika ielādēts, sertifikāts pieņemts vai otrā puse atbildēja. Iepakots klients var minūtēm sēdēt atkārtošanas cilpā, kamēr systemd ziņo tikai par panākumiem. Šī plaisa starp stāvokli un uzvedību ir visa tēma.

Pretējais gadījums ir tikpat bieži sastopams. Process varēja beigties pēc tam, kad neizdevās nolasīt atslēgu, un tad vienība ziņo par neizdevušos stāvokli, kas neko nepasaka par iemeslu. Abiem stāvokļiem ir vajadzīgs žurnāls, lai tos atšķirtu.

Lasiet žurnālu konkrētajai instancei, nevis vienības stāvokli. Iemesla rinda ir žurnālā, nevis statusa birku.

Mīts: atkārtošanas iestatījumi nosedz katru kļūmi

Vārdu izšķiršana un transporta atkārtojumi ir atsevišķas vadības ar atsevišķām noklusējuma vērtībām. resolv-retry vada atkārtotus attālināta resursdatora nosaukuma meklējumus, un dokumentētā noklusējuma vērtība mēģina bezgalīgi. connect-retry nosaka intervālu starp mēģinājumiem, bet connect-retry-max var ierobežot, cik reizes tiek mēģināts katrs attālinātais ieraksts. Pirms jebkura no tiem maiņas pārbaudiet, kuru posmu žurnāls nosauc.

Nekas no tā neattiecas uz bojātu profilu, neizlasāmu privāto atslēgu vai noraidītu kontu. Tiem vajadzīgs labojums, un klients, kas tos turpina atkārtot, nevirzās uz priekšu.

Neapstiprināta sertifikāta bezgalīga atkārtošana nav iemesls noņemt pārbaudi. Tas ir iemesls izlasīt kļūdu.

Mīts: ar vienu palaidēju pietiek, tāpēc pievienojiet vēl vienu

Savienojumam, ko jau pārvalda NetworkManager vai iepakota vienība, nav vajadzīgs otrs palaidējs. Divi procesi, kas sacenšas par tiem pašiem maršrutiem, rada dubultotas saskarnes, mulsinošus žurnālus un tuneli, kas svārstās tādu iemeslu dēļ, ko neviens neredz. Otrā kopija parasti nāk kā apietais ceļš tam, ka pirmais ir lēns.

Izlemiet, kura komponente pārvalda tuneli pirms kaut ko pievienojat. Pēc tam noņemiet otru palaidēju, nevis atspējojiet to un ceriet.

Īpašnieks arī nosaka, no kurienes nāk atkārtojumi un akreditācijas dati, tāpēc šis lēmums ir pirms jebkādas regulēšanas. Īpašumtiesības nāk pirmās tieši šī iemesla dēļ.

Kam tiešām vajadzīga secība

Secība var gaidīt konfigurētu adresi, un tas ir viss, ko tā garantē. network-online.target aizkavē aktivizāciju, līdz pārvaldnieks uzskata tīklu par augšup, un augšup definīcija ir atkarīga no pārvaldnieka. Tā neko nepasaka par to, vai VPN resursdatora nosaukums tiek izšķirts, vai klausītājs atbild, vai gūsta portāls ir ielaidis ierīci.

Pirms atkarību pievienošanas izlasiet instalēto vienību un visus drop-in failus. Plašs After= katrā tīkla pakalpojumā aizkavē sāknēšanu, bet neizveido savienojumu, kas jums tiešām vajadzīgs.

Sakārtojiet atkarību, ko varat pārbaudīt, un visu pārējo pārbaudiet ar gatavības zondi. Zonde, kas atver tuneli, ir labāka par minējošu taimeri.

Kas notiek pēc tam, kad tunelis pirmo reizi paceļas

Sāknēšana ir viens notikums starp daudziem. Piekļuves saite mainās, portāla sesija beidzas, partneris restartējas. Atšķiriet iekšēju atkārtotu savienojumu no procesa iziešanas, ko apstrādā pakalpojumu pārvaldnieks, jo abiem ir atšķirīgi īpašnieki un tie atstāj atšķirīgus pierādījumus.

Interaktīva autentifikācija ierobežo uzraudzības neprasošu atjaunošanu. Fona vienība neatbloķē darbvirsmas atslēgu saišķi un neatbild uz MFA pieprasījumu, tāpēc ievērojiet apstiprināto akreditācijas datu kārtību pakalpojuma kontekstam.

Atsevišķi izlemiet, ko lietotnes drīkst darīt, kamēr tunelis ir izslēgts. Atkārtošana atjauno savienojumu, bet bloķēšanas politika izlemj, vai tajā starplaikā ir atļauts tiešs trafiks.

Saistītie raksti