Kāpēc OpenVPN UDP atbilde nāk no nepareizas adreses

OpenVPN klients izsauc vienu adresi, serveris atbild no citas, un tunelis nekad nepaceļas. Servera žurnāls rāda ienākošo paketi, bet ieraksts rāda izejošo atbildi, tāpēc kļūda tiek piedēvēta klientam. Resursdatorā ar vairākām saskarnēm vai vairākām adresēm vienā saskarnē abas puses vienkārši nevienojas, kura adrese tiek izmantota. Atbilde ir derīga IP slānī, taču daudzi klienti izmet datagrammu, kura avots nav adrese, ar kuru tie sazinājās.

Ko klients redz, kad avots mainās

UDP ligzdai, kas nav piesaistīta konkrētai vietējai adresei, nav fiksēta avota, tāpēc kodols to izvēlas nosūtīšanas brīdī. Šī izvēle nāk no maršruta meklēšanas uz klienta adresi, un par avotu kļūst tās saskarnes adrese, kuru meklēšana izvēlas. Vienas saskarnes mašīnā izvēle ir neredzama; resursdatorā ar pārvaldības adresi, publisku adresi un sekundāro adresi tajā pašā tīkla kartē tā ir atkarīga no maršruta metrikām un politikas. Uz politiku balstīta maršrutēšana neatbilstību padara ticamāku, nevis mazāk ticamu, jo noteikums var izvēlēties augšupēju, kuru klients nekad nesasniedza. Pietiek ar noklusējuma maršrutu, kas apgūts no viena pakalpojumu sniedzēja, un avota noteikumu, kas norāda uz citu.

Klienti, kas filtrē atbildes, un savienojumu izsekošana, kas gaida precīzu četrinieku un avotu, atmetīs atbildi bez noderīga ziņojuma. Tad tunelis beidzas tā, it kā nekas nebūtu ieradies, un tāpēc tas tiek kļūdaini uzskatīts par klienta puses ugunsmūra problēmu. Ieraksts, kas veikts tikai serverī, apstiprina kļūdu, nevis izskaidro to, jo atbilde tiešām iziet. Salīdziniet atbildes avotu ar adresi, kuru klients izsauca, pirms kaut ko citu mainīt.

Ko opcija multihome faktiski dara

Direktīva tiek rakstīta kā multihome konfigurācijas failā un kā --multihome komandrindā, un tā liek UDP serverim atbildēt no adreses, kuru sasniedza klienta pakete. Kodols saņemšanas laikā nodod sākotnējo galamērķa adresi kā papildu datus, un OpenVPN izmanto šo vērtību kā atbildes avotu. Tā serveris, kas klausās uz vispārīgas adreses, local 0.0.0.0 IPv4 vai tās IPv6 ekvivalents, uzvedas tā, it kā katrs klients būtu sasniedzis atsevišķu klausītāju. Klienti, kas ienāca caur publisko adresi, saņem atbildes no publiskās adreses, un klienti iekšējā adresē saņem tās no šīs adreses. Nekas cits paketes ceļā nekustas: maršruts, filtra noteikumi un tuneļa konfigurācija paliek tieši tādi, kādi tie bija.

Tieši šī pēdējā īpašība padara opciju drošu pievienošanu citādi strādājošam serverim, un tā ir arī iemesls, kāpēc tā nevar salabot filtru, kas atļauj tikai vienu adresi. Pakete tomēr ir jāpieņem ceļā, pa kuru tā iet, tāpēc avota labojums maina atbildes izcelsmi un neko vairāk. Tā ir arī tikai UDP: TCP klausītājam šī problēma nav tādā pašā formā, jo savienojums tiek identificēts ar četrinieku, nevis ar atbildes avota adresi.

Kad fiksēta vietējā adrese ir nepareizā noklusējuma vērtība

Pirms ķerties pie opcijas, pārbaudiet, vai serveris piesaista vienu konkrētu vietējo adresi, jo piesaistīts klausītājs vienmēr atbild no šīs adreses. Tas ir pareizi izvietojumam ar vienu saskarni un nepareizi, tiklīdz klienti likumīgi izmanto vairāk nekā vienu adresi. Ja piesaiste bija apzināta, izlemiet, vai serverim vispār jāpieņem trafiks papildu adresēs. Piesaistes noņemšana palielina pakļautību, tāpēc atļautās saskarnes un avota tīklus jānodrošina servisam un filtram, nevis tikai piesaistes adresei.

OpenVPN uzziņa ierobežo opciju ar UDP serveriem, atzīmē papildu apstrādi paketes ceļā un reģistrē, kuras platformas to atbalsta. Apstipriniet to instalētajā laidienā, pirms plānot uz tā pamata. Kur tas nav atbalstīts, alternatīva ir piesaistīt konkrēto adresi vai salabot atgriešanās maršrutu, un abi ir šaurākas izmaiņas, nekā šķiet no pirmā acu uzmetiena. Klausīšanās uz vispārīgas adreses rada sekas arī ārpus atbildēm: serveris visās adresēs ir sasniedzams no katra tīkla, kuram resursdators ir pievienots, un tā varētu nebūt tā pakļautība, ko kāds bija domājis.

Pierādiet atbildes avotu no ārpuses

Pārbaudiet ārpus servera un pierakstiet precīzu adresi un transportu, ko klients izmantoja, pirms kaut ko ierakstīt. Trīs pārbaudes zemāk atbild uz trim dažādiem jautājumiem, un secībai ir nozīme.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

Ieraksts rāda atbildes avota adresi, un uz šo faktu balstās viss raksts. Ligzdu saraksts rāda, ko serveris faktiski piesaistīja, jo vispārīgais un konkrētais klausītājs konfigurācijas failā izskatās vienādi un tīklā uzvedas atšķirīgi. Maršruta meklēšana rāda avotu, kuru kodols izvēlētos šai plūsmai, un tas izskaidro ierakstu, pirms kaut ko maināt. Atkārtojiet visus trīs atsevišķi IPv4 un IPv6, jo tie ir atsevišķi klausītāji un atsevišķas meklēšanas, un vienas saimes vispārīgais ieraksts neko neizsaka par otru.

Maršrutēšana, atklāšana un filtrēšana paliek atsevišķi

Atbildes avota saglabāšana neinstalē izejošo maršrutu, neatjaunina dinamisku DNS un neliek vienai adrešu saimei pieņemt otru. Serverī ar vairākām augšupējām saitēm katra avota atgriešanās ceļš ir apzināti jāsaskaņo, citādi atbildes iziet pa saskarni, kuru klienta filtrs nekad nav atļāvis. Tāpat jaunai adresei pēc prefiksa maiņas jāsasniedz klienti caur atklāšanu un atbalstīto atkārtotās savienošanās plūsmu, nevis caur veco ierakstu.

Atstājiet servera identitātes pārbaudes un sertifikātu verifikāciju tieši tādas, kādas tās ir, jo mainīta adrese neattaisno nepadomāta partnera pieņemšanu. Ja atbilde tagad iziet no paredzētā avota un tunelis joprojām neizdodas, uzskatiet avota problēmu par atrisinātu un ejiet tālāk. Nākamā novērotā kļūda pieder maršrutēšanai, filtrēšanai vai autentifikācijai, un atkārtota klausītāja maiņa to nesasniegs. Ierakstiet atbildes avotu biļetē blakus adresei, kuru klients izsauca, lai nākamā persona varētu pārbaudīt to pašu faktu ar vienu komandu.