OpenVPN serveris un klients vienā saimniekā: kāpēc klienti atkrīt

Pievienojiet klienta profilu mašīnai, kurā jau darbojas VPN serveris, un pirmais upuris būs sākotnējais pakalpojums. Jaunais tunelis var nekad neizveidoties, vai arī tas var pacelties, kamēr servera esošie klienti klusi pārstāj saņemt atbildes. Divas sadursmes dod abus rezultātus: jau izmantots tuneļu baseins un jaunā klienta puses uzstādītais noklusējuma maršruts, kas nosedz visu tabulu. Neviens no tiem nerada OpenVPN kļūdas ziņojumu, tāpēc kļūme tiek lasīta kā servera problēma.

Viena mašīna, divas lomas un divas nesavienojamas atbildes par to, kur atbildēm jāiet.

Tas pats baseins, divi serveri: kurš uzvar

Katrai servera instancei vajag savu tuneļa apakštīklu. Kopējot rindu, piemēram, server 10.8.0.0 255.255.255.0, otrajā konfigurācijā, abas instances iegūst vienu un to pašu prefiksu, un rezultāts ir vai nu atteikšanās startēt, vai klusa sacensība, kurā viena servera klienti saņem adreses, ko otrs arī uzskata par savām. Dažādi UDP porti un dažādi ierīču nosaukumi nepalīdz, jo neviens no tiem neaizskar adrešu telpu. Nomainiet otro baseinu un nomainiet to visur, kur maršruti to piemin.

Uzskaitiet, kas ir aktīvs pirms rediģēšanas: ip -4 addr show uzskaita tuneļa ierīces, ss -lunp uzskaita klausītājus, un systemctl list-units nosauc vienības. Viens skatiens uz tuneļa adresēm izšķir, vai baseini saduras.

Ko klienta profils pievieno tabulai

Klienta puse raksta maršrutus, tiklīdz tā pieslēdzas. redirect-gateway def1 sadala noklusējuma maršrutu 0.0.0.0/1 plus 128.0.0.0/1, abi tiek maršrutēti caur jauno ierīci, kopā ar resursdatora maršrutu uz attālo serveri, kas apzināti piesprausts pie fiziskās saskarnes. Šis piespraudums pastāv, lai tunelis saglabātu ceļu savam transportam. Viss pārējais, tostarp atbildes, ko vietējais serveris ir parādā saviem klientiem, tagad seko jaunajam noklusējumam un iziet pa attālo savienojumu.

Tātad otrā sadursme nav salauzts tunelis. Tas ir strādājošs tunelis nepareizajā tabulas vietā.

Trīs veidi, kā šķirt lomas

Vismazāk invazīvais labojums izņem noklusējuma maršrutu no klienta profila: route-nopull plus skaidras route rindas attālajiem prefiksiem, lai vietējā tabula mainītos tikai tur, kur jūs to lūdzāt. Nākamais solis ir politikas noteikums, kas atbrīvo vietējo tuneļa apakštīklu, ļaujot atbildēm uz vietējiem klientiem iziet pa saskarni, pa kuru tās ienāca, pat ja pastāv noklusējuma maršruts. Vispilnīgākais ir atsevišķa tīkla nosaukumvieta klienta lomai, kas pilnībā noņem kopīgo tabulu un prasa uzturēt otru maršrutēšanas kontekstu.

Lai kādu ceļu izvēlētos, izņēmumam jānosauc vietējais tuneļa apakštīkls, nevis LAN. Vietējā servera sūtītās atbildes galamērķis ir tuneļa adrese, tāpēc LAN formas izņēmums tam nekad neatbilst.

Kura no abām instancēm ir vainīga

Apturiet klienta instanci un vēlreiz pārbaudiet sākotnējos klientus. Tūlītēja atlabšana nozīmē maršrutēšanu, nevis serveri. Ieslēdziet klientu atpakaļ un izsekojiet vienu atbildi ar ip route get, kuram dots gan avota, gan galamērķa adrese, kas parāda ceļu, kuru izvēlētos kodols, un pēc tam novērojiet saskarni, ko paketes patiešām izmanto, ar tcpdump -ni any port 1194. Servera statusa fails, kas tiek rakstīts ik pēc dažām sekundēm caur status direktīvu, satur savienoto klientu sarakstu un baitu skaitītājus abos virzienos.

Lasiet šos skaitītājus vienu pret otru. Satiksme, kas iziet un nekad neatgriežas, ir maršrutēšanas atbilde, nevis rokas paspiešanas problēma.