OpenVPN: vietējā adrese pret tuneļa adresi — divas dažādas ligzdas

Klients atsakās startēt un sūdzas, ka nevar piesaistīt vietējo adresi, un acīmredzamais risinājums izskatās pēc norādīšanas uz tuneļa adresi, kuru tas gaida. Tas nevar darboties, un iemeslu ir vērts saprast: pirms tuneļa pastāvēšanas iekšējās adreses nav, un ligzdai, kas sazinās ar serveri, jāpastāv pirmajai. Šeit ir divas dažādas adreses, un tikai vienu no tām var izvēlēties lokāli.

Piesaistes kļūda nosauc vietējo adresi

Kad OpenVPN ziņo, ka nevar piesaistīt vietējo adresi, tas runā par transporta ligzdu: UDP vai TCP galapunktu, kas pārnēsā šifrēto savienojumu uz partneri.

Skaidra local direktīva lūdz dēmonu piesaistīt šo ligzdu konkrētai vietējai adresei. Adresei jāpastāv tīkla nosaukumtelpā, kurā darbojas process, un tai jābūt piešķiramai brīdī, kad klients startē.

Publiska adrese, kas tulkota maršrutētājā vai mākoņa malā, nav vietējā adrese, ko dēmons var piesaistīt, pat ja tā ir adrese, ko redz serveris. Šī atšķirība izskaidro, kāpēc viens profils darbojas mājās un neizdodas mākoņa instancē. Tā arī izskaidro, kāpēc publiskās adreses pievienošana loopback saskarnei nepalīdz, jo tad transports nāktu no adreses, uz kuru tīkls nevar atbildēt. Pirms profila rediģēšanas izlasiet saskarņu sarakstu.

Ko patiesībā izvēlas local un remote

remote nosauc partneri, ar kuru sazināties. local piesaista tās pašas ligzdas tuvāko galu. nobind ļauj operētājsistēmai izvēlēties gan vietējo adresi, gan portu, tāpēc klienti aiz mājas maršrutētājiem parasti darbojas bez abām direktīvām.

Nevienai no direktīvām nav nekāda sakara ar adresi tuneļa iekšienē.

Konteinera vai tīkla nosaukumtelpā darbojas tas pats noteikums ar šaurākām robežām: saimnieka adreses iekšienē nav, tāpēc no saimnieka konfigurācijas nokopētā local rinda neizdodas pavisam cita iemesla dēļ nekā nepareiza adrese.

ip -brief address show
ip route get 203.0.113.10

Iekšējā adrese nāk no servera

Adrese tuneļa iekšienē tiek apspriesta vai piešķirta pēc vadības kanāla izveidošanas. Dinamiskā pūlā serveris to izlemj savienošanās brīdī, un klientam specifiskā konfigurācijā tā var būt fiksēta katrai identitātei.

Rakstīšana local ar iekšējo adresi nelūdz serveri piešķirt šo adresi. Labākajā gadījumā piesaiste neizdodas; sliktākajā gadījumā klients atrod nesaistītu saimnieka adresi ar tādu pašu vērtību un sāk to izmantot transportam.

Arī lasāmās saskarnes atšķiras. ifconfig parametri un pūla konfigurācija apraksta iekšieni, bet remote, local, proto un nobind apraksta ārpusi. Abu sarakstu šķiršana izskaidro gandrīz katru mulsinošo piemēru, ko atradīsiet forumā. OpenVPN 2.6 rokasgrāmata tos dokumentē atsevišķās sadaļās tieši šī iemesla dēļ.

Slazds: pilns tunelis, kas notver savu transportu

Kad tunelis ir uzcelts un nes noklusējuma maršrutu, to uzturošos paketes nedrīkst maršrutēt tajā. Tā ir maršrutēšanas, nevis adresācijas problēma, un dēmons to risina, instalējot konkrētāku maršrutu uz paša servera adresi caur sākotnējo vārteju.

Ja piesaistāt transportu konkrētai vietējai adresei un vēlāk maināt ceļu, ko šī adrese izmanto, ārējais savienojums var apmaldīties, kamēr iekšiene paliek konfigurēta. Tunelis turpina ziņot, ka ir savienots, jo iekšiene ir kārtībā. Bojāts ir tikai transports, un tāpēc žurnāli lasās kā pretrunas.

Tad simptomi izskatās kā tunelis, kas savienojas un iesalst, vai tāds, kas cilpā atkal savienojas bez noderīgas kļūdas. Pirms pārbaudāt kaut ko tuneļa iekšienē, pārbaudiet maršrutu uz partnera adresi un apstipriniet, ka piesaistītā vietējā adrese joprojām pieder gaidītajai saskarnei.

Paradums, kas novērš apjukumu

Izlasiet katru profila adresi un pirms rediģēšanas izlemiet, kuram slānim tā pieder.

Ja tā nosauc transporta tālo galu vai piesaista tā tuvāko galu, tā ir ārējā adrese, un tai jāpastāv pirms starta. Ja tā apraksta, kas notiek tuneļa iekšienē, tā nāk no servera vai no topoloģijas, un neviena vietējā direktīva to nevar aizstāt.

Ierakstiet abus sarakstus izvietošanas piezīmēs blakus profilam. Nākamā problēmu risināšanas sesija tad sāksies ar slāni, nevis ar minējumu.