Publiskā IP adrese mainījās, un VPN pārstāja laist datplūsmu

Atkārtots savienojums pie pakalpojumu sniedzēja vai izmaiņa tulkojumā augšup maina VPN sesijas publisko avotu, bet klienta vietējā privātā adrese parasti paliek tieši tāda, kāda tā bija. Tad tunelis izskatās savienots, lai gan caur to neiet nekas lietderīgs. Abi novērojumi ir patiesi vienlaikus, un tieši tas padara ziņojumu mulsinošu.

Veiciet četras pārbaudes pēc kārtas un apstājieties pie pirmās, kas neizdodas.

Kura adrese patiešām mainījās

Salīdziniet vietējās saskarnes stāvokli ar avotu, ko redz attāls galapunkts, vietā, kur jums ir atļauts skatīties. Jauna publiskā adrese nenozīmē jaunu vietējo vārteju, un vietējās saskarnes izmaiņa arī negarantē, ka publiskais avots ir pārvietojies. Tulkojums starpā nozīmē, ka tie ir divi neatkarīgi fakti. Pierakstiet precīzo ceļu un laiku, kad to novērojāt, jo no veca ziņojuma nokopēta ģeolokācijas etiķete atbild uz citu jautājumu.

Jautājiet konkrēti, vai mainījās ārējais avots, iekšējā tuneļa adrese vai abi. Tikai pirmais izskaidro partneri, kas turpina sūtīt uz ceļu, kura vairs nav.

Ļaujiet protokolam pašam tikt galā ar pārvietošanos

Protokoli atšķiras ar to, kā tie uzzina, ka partneris ir pārvietojies, un šī atšķirība ir svarīga jautājumā, vai jums vispār jāiejaukjas. WireGuard atjaunina partnera galapunktu, kad saņem paketi, kas autentificējas ar šī partnera atslēgu, tāpēc adreses maiņu var uzņemt bez jebkādas konfigurācijas. IKEv2 ir MOBIKE šim pašam nolūkam, kur to atbalsta abi gali. Vecāki risinājumi atjaunojas, pārbūvējot tuneli.

Ko jums nevajadzētu darīt, ir pieņemt neautentificētu ziņojumu kā pierādījumu, ka partnera identitāte ir pārvietojusies. Ir vienkārši viltot datagrammu, kas apgalvo jaunu adresi, un klients, kas tic, ka to var novirzīt uz uzbrucēja galapunktu. Autentificētais protokols ir mehānisms; paziņojums nav.

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

Notīriet novecojušo ārējo saistījumu

Kad protokols atbalsta viesabonēšanu un datplūsma tomēr neiet, šķērslis bieži ir stāvokli saglabājoša iekārta pa vidu vai politika tālajā galā. Ugunsmūris, kas sekoja vecajai plūsmai, var saglabāt novecojušo ierakstu, un servera puses piekļuves noteikums, kas piesaistīts vecajam avotam, klusi izmetīs jauno. Notīrīt kartējumu un vēlreiz pārbaudīt noteikumu ir ātrāk nekā nomainīt akreditācijas datus.

Izmeklēšanas laikā saglabājiet nepieciešamo bloķēšanu. Politikas plaša atvēršana, lai pārbaudītu, vai tunelis atjaunojas, neko neiemāca par cēloni un atstāj izvietojumu sliktāku, nekā jūs to atradāt.

Pārbaudiet vēlreiz ar jaunu pieprasījumu

Lietojumprogrammas sesija, kas izveidota pirms izmaiņas, to nepārdzīvo, jo četrinieks, uz kura tā tika veidota, vairs neeksistē. Pēc atjaunošanas ģenerējiet jaunu pieprasījumu un apstipriniet, ka tas pabeidzas, nevis skatieties, kā veca lejupielāde stāv uz nulles, un seciniet, ka tunelis joprojām ir salauzts. Tieši šī vienīgā atšķirība atrisina lielu daļu šo ziņojumu.

Pēc tam pierakstiet abas diagnozes puses: kas mainījās augšup un kurš atbalstītais atjaunošanas solis atgrieza plūsmu. Nākamā reize būs ātrāka, un tieši pieraksts to padara ātrāku.

Ja jauns pieprasījums izdodas un vecais nekad neatjaunojas, tunelis tika salabots, un lietojumprogrammai vienkārši jāpievienojas no jauna.