VPN ir pārvietots: kāpēc jūsu OpenVPN klients joprojām zvana uz veco IP

Pakalpojumu sniedzējs nomainīja jūsu publisko adresi, jūs atjauninājāt dinamisko DNS ierakstu, un klients joprojām nevar savienoties. No ārpuses izskatās, ka ieraksts nav izplatījies. Visbiežāk ieraksts ir kārtībā un klients zvana uz adresi, kuru tas atrisināja pirms pārvietošanas, jo darbojošamies tunelim un saglabātajam profilam katram ir savs priekšstats par to, kur dzīvo serveris. Trim slāņiem jāsakrīt, un tie atjauninās pēc dažādiem grafikiem.

Skatieties, uz ko zvana profils, nevis ko saka DNS

Atveriet savienojumu, kuru patiešām lietojat, un izlasiet remote rindu. Ciparu adrese tur nekad neseko resursdatora nosaukuma atjauninājumam, lai cik pareizs kļūtu ieraksts.

Pēc tam pārbaudiet, vai profils, kuru rediģējāt, ir tas, kuru ielādēja klients. Importēti profili ir bieži: administrators pirms mēnešiem varēja paņemt kopiju un paturēt savu versiju, tāpēc fails jūsu lejupielāžu mapē un ieraksts lietotnē var atšķirties. Salīdziniet galapunktu paša klienta savienojuma informācijā, pirms vispār sākat atkļūdot DNS.

Divi faili, viens galapunkts — tas šeit ir ierasts atradums.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Izlasiet klienta nākamo savienošanās mēģinājumu

Restartējiet savienojumu ar detalizētu žurnālēšanu un izlasiet rindu, kurā nosaukta adrese, ar kuru tas sazināsies. Tieši šī vērtība ir svarīga, nevis tā, kuru atrisināja jūsu pārlūks.

Atrisinātāja kešatmiņa var joprojām turēt iepriekšējo atbildi, un daži tīkli to tur ilgāk, nekā prasa ieraksta TTL. Jautājiet atrisinātājam, kuru klients patiešām lieto, nevis publiskam, kuru pārbaudījāt citur.

Ja žurnāls rāda jauno adresi un savienojums joprojām neizdodas, problēma ir pārvietojusies: pakete kaut kur dodas un neviens neatbild. Tas ir klausītāja, ugunsmūra vai porta pāradresācijas jautājums, un tas ir servera pusē, nevis klienta atrisināšanas ceļā. Turiet šīs divas kļūdas atsevišķi, jo neaizsniedzama klausītāja uztveršana par DNS problēmu liek jums divreiz iet pa to pašu cilpu.

Ziniet, kādu restartu veicat

Ne visi restarti saglabā vienu un to pašu stāvokli, tāpēc adreses maiņa var uzvesties citādi atkarībā no tā, kā process tiek pārstrādāts. Signāla izraisīts mīksts restarts saglabā vairāk iepriekšējās sesijas konteksta, bet pilnīga apturēšana un palaišana atkal sākas no konfigurācijas. Ja pārbaudāt, vai klients atkal atrisina, jums vajag ceļu, kas sākas no konfigurācijas.

Noturības iestatījumi arī ir svarīgi, jo tie ir paredzēti, lai saglabātu to, kas tika autentificēts, nevis lai dzītos pēc jaunām adresēm.

Vistīrākais tests ir svaiga palaišana no paredzētā profila, kam seko skatiens uz žurnāla rindu, kurā nosaukts galapunkts. Viss, ko uzzināt no daļēji saglabātas sesijas, ir apgalvojums par šo sesiju.

Četras opcijas un to atsevišķie uzdevumi

remote ar resursdatora nosaukumu ir iestatījums, kas vispār padara iespējamu atkārtotu atrisināšanu; burtiska adrese šajā rindā to izslēdz. resolv-retry kontrolē, kas notiek, kad meklēšana neizdodas, un 2.6 to jau pēc noklusējuma iestata bezgalīgu. Tāpēc tā pievienošana neko nemaina, un tas nekad neieplāno periodisku pārbaudi citai atbildei. Kurš saka, ka tas aptaujā jaunas adreses, ir sajaucis atjaunošanu ar svaigumu.

persist-remote-ip ir par nepārtrauktību, nevis svaigumu: tas atkārtoti izmanto galapunktu, kas pēdējais autentificējās, cauri atbalstītajiem mīkstajiem restartiem. Kamēr pārbaudāt pārvietošanu, tas ir pretējs tam, ko vēlaties. Atspējojiet to testam, ja jūsu būvējums to iespējo, un pēc tam atjaunojiet, kad jaunais galapunkts ir pierādīts. Atstājot ieslēgtu, veiksmīgs atkārtots savienojums var jums neko nepateikt par DNS.

float pieņem autentificētu partneri, kura adrese mainījās sesijas vidū, un tikai tādās konfigurācijās, kas to atbalsta. Tas neatjaunina DNS un pats nesekos pakalpojumu sniedzēja maiņai. Uztveriet to kā noturības funkciju klejojošiem partneriem, nevis kā dinamisku adrešu mehānismu serveriem.

Apstipriniet jauno galapunktu pirms klienta vainošanas

Ārpus sava tīkla pārbaudiet, vai jaunajai adresei konfigurētajā portā ir klausītājs un vai pakalpojumu sniedzēja pāradresācija uz to norāda. Pareizs A ieraksts mašīnai bez atvērta porta rada tieši to simptomu, ko cilvēki piedēvē kešatmiņai.

Pēc tam savienojieties no jauna un pārbaudiet divas lietas: klients autentificējās pret gaidīto servera sertifikātu, un sesija sasniedz paredzēto resursu. Adreses maiņa nepaceļ identitātes prasības, un savienojums, kas izdodas pret nepareizu galapunktu, ir sliktāks par neizdevušos. OpenVPN 2.6 rokasgrāmata uzskaita visas četras opcijas ar to darbības jomu, un tas ir kontrolsaraksts, kas jātur pie profila.

Pirms restartējat tuneli, kas pārvadā jūsu administrēšanas piekļuvi, saglabājiet ceļu uz serveri ārpus joslas. Šis viens piesardzības pasākums novērš lielāko daļu incidentu, ko rada šis scenārijs.