WAN IP ir mainījies, un tunelis ir pārtrūcis: pārbaudes pēc kārtas

Tunelis pārtrūkst, maršrutētājs reģistrē atkārtotu savienojumu, un lokālajā tīklā nekas nav pārvietojies. Jauna WAN adrese padara ārējo savienojumu nederīgu, iekšienē neko nemainot: klienta avota adrese ir mainījusies, vecais NAT stāvoklis norāda uz avotu, kas vairs neeksistē, un attālais vienaudzis, iespējams, joprojām sūta uz iepriekšējo adresi. Atjaunošanās ir normāla uzvedība, un noderīgais jautājums ir, kurš stāvoklis netika atjaunināts.

Nosauciet notikumu pirms žurnāla lasīšanas

Pārbaudiet, kas patiešām notika piekļuves slānī. ISP līzinga atjaunošana ir viens notikums. Atkārtoti pievienota PPPoE sesija ir cits. Restartēts optiskās šķiedras modems vai WAN pāreja no viena kanāla uz otru maina ārējo adresi vai tās ceļu trešā veidā. Tie nav viens un tas pats notikums, un tie neatstāj tos pašus atlikumus.

Atkārtota savienojuma rinda VPN žurnālā arī nav WAN maiņas pierādījums. Dīkstāves taimauts, atkārtotas autentifikācijas intervāls un miruša vienaudža noteikšana visi rada atkārtotus savienojumus bez jebkādām adreses izmaiņām. Pirms jebkāda secinājuma salīdziniet piekļuves žurnāla laika zīmes ar VPN žurnālu un turiet salīdzināšanas logu pietiekami plašu, lai uztvertu nakts laikā notikušu izmaiņu.

Viesabonēšana un atkārtota savienošanās ir dažādi protokoli

WireGuard ir iebūvēta autentificēta viesabonēšana: kad vienaudzis saņem pareizi autentificētu paketi no jaunas avota adreses, tas atjaunina šī vienaudža galapunktu. WireGuard ātrā rokasgrāmata apraksta vienaudža konfigurāciju, kas to nodrošina, tāpēc klients mainīgā adresē bieži atjaunojas bez redzamas restartēšanas.

OpenVPN pēc noklusējuma uzvedas citādi. UDP sesija var beigties un atkal pievienoties, un neobligātā float uzvedība ļauj autentificētam vienaudzim turpināt no jaunas adreses tur, kur konfigurācija to atļauj. TCP balstīti tuneļi ir stingrāki, jo pats savienojums ir saistīts ar adrešu pāri. Šī atšķirība nosaka, vai atjaunošanās izskatīsies neredzama vai katru reizi pieteiksies žurnālā.

Neviena uzvedība neko nepasaka par lietotnēm iekšienē. Atjaunots tunelis neatjauno TCP sesiju, ko vienaudzis jau uzskatīja par mirušu.

Stāvoklis, kas tunelim nepieder

Tulkošanas un maršrutēšanas stāvoklis pārdzīvo atkārtotu savienojumu veidos, kas cilvēkus pārsteidz. Vecajam avotam izveidots conntrack ieraksts tur atbildes ceļu piesaistītu adresei, kas vairs neeksistē, un tas beidzas pēc sava grafika, nevis tad, kad tunelis atgriezās. Tuneļa pakalpojuma restartēšana šo gaidīšanu nesamazina, tāpēc salabots savienojums vēl kādu laiku var izskatīties salūzis.

Maršruti un politikas noteikumi var atsaukties uz veco vārteju vai interfeisu. Noteikumu kopa, kas bija pareiza pirms WAN pārslēgšanas, var norādīt uz ierīci, kas tagad ir izslēgta, un tas rada tuneli, kas ziņo par savienojumu, un trafiku, kas nekur nenonāk. Dinamiskais DNS serverim, ko mitināt, ir atsevišķa problēma no klienta, kas iegūst jaunu avotu. Ieraksts ir jāatjaunina, lai attālinātie klienti jūs atrastu, un neviena klienta puses konfigurācija nekompensē adresi, ko augšupējā tulkošana netransportēs.

Sakārtojiet pārbaudes no ārpuses uz iekšu

Zemāk dotā kārtība iet no ārējā savienojuma uz iekšu, un apstāšanās pie pirmā neizdevušā soļa ir tas, kas to padara noderīgu: katra pārbaude izslēdz slāni virs tās. Ievērojiet šo kārtību arī tad, kad bojājums izskatās acīmredzams.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

Pirmā komanda parāda pašreizējo galapunktu un katra vienaudža rokasspiediena vecumu. Otrā un trešā parāda, vai ārējais interfeiss un maršruts uz galapunktu joprojām ir jēgpilni. conntrack skaits ir aptuvena pārbaude stāvoklim, kas palicis no iepriekšējās adreses, un žurnāls ir vieta, kur tiek reģistrēts atkārtota savienojuma iemesls.

Pēc tam testējiet no LAN klienta, nevis no maršrutētāja. Paša maršrutētāja sūtītais ping izmanto citu ceļu nekā pārsūtītais trafiks, tāpēc veiksmīgs maršrutētāja ping pierāda, ka tunelis pastāv, un neko par klienta sasniedzamību.

Izlemiet gaidāmo uzvedību un pierakstiet to

Atkārtota savienošanās ir pareiza uzvedība lielākajai daļai izvietojumu, tāpēc mērķis nav to novērst. Tā vietā izlemiet, kas notiks ar trafiku pārtraukuma laikā: to apturēt, aizturēt vai pārslēgt uz citu ceļu. Šis lēmums pieder ugunsmūrim un maršrutēšanas politikai, nevis VPN profilam.

Reģistrējiet piekļuves notikumus un atkārtota savienojuma laikus kopā nedēļu. Atkārtotas izmaiņas bez atbilstoša piekļuves notikuma norāda uz piekļuves pakalpojumu, un VPN profila nomaiņa nesalabos kanālu, kas pastāvīgi atkārtoti pārrunā. Viens ierakstu pāris tajā pašā minūtē atrisina jautājumu par šo incidentu un dod nākamajam sākumlīniju.