Divi pakalpojumu adresi vienā OpenVPN klientā: iroute un lo

Lietotne atbild uz sava tuneļa adreses, un adrese, ko tai dokumentējāt, nekur neved. Nekas OpenVPN žurnālā nesūdzas, vienaudzis tiek rādīts kā savienots, un centrs uzskaita tieši vienu klientu. Trūkums ir tāds, ka otrā adrese klientā ir divi atsevišķi fakti: resursdatoram tā ir jāpieder, un centram jāzina, kuram vienaudzim tā pieder. Apstrādājiet vienu bez otra, un trafiks vai nu iet bojā centrā, vai ierodas bez ceļa mājup.

Aizstājvārds ir vietējs, īpašumtiesības ir attālas

Par tuneļa adresi vienojas, tāpēc abi gali to uzzina rokas spiediena laikā. Par papildu pakalpojuma adresi nemaz nevienojas, tāpēc tās pievienošana pati par sevi centrā neko nemaina. Klients var uzreiz iegūt adresi, un serveris joprojām sūtīs šo trafiku uz savu noklusējuma ceļu vai to izmetīs. Jāizveido divi ieraksti, divās dažādās vietās.

Klientā adrese pieder resursdatoram, un loopback ir dabiskas mājas pakalpojuma identitātei, kurai nekad nevajadzētu parādīties fiziskā saitē. Centrā vienaudža sasaiste ar prefiksu ir atsevišķa deklarācija, ko lasa tikai serveris. Neviens ieraksts neietver otru.

Turiet abus diapazonus atsevišķi arī savos pierakstos. Piemēra adreses ir dokumentācijas vērtības, un to pārklāšanās ar īstu LAN ir ātrākais veids, kā likt strādājošam iestatījumam izskatīties salauztam.

Pievienojiet adresi klientam pastāvīgi

Novietojiet pakalpojuma adresi uz loopback ar resursdatora prefiksu, lai resursdators to uzskatītu par vietēju ievadi, nevis sasniedzamu apakštīklu. ip address add 10.66.0.10/32 dev lo to dara vienai adresei, un komandas atkārtošana otrai adresei modelē divus pakalpojumus.

Palaidiet to kā vienreizēju testu, pēc tam pārvietojiet to uz to, kam pieder resursdatora tīkla konfigurācija, jo izpildlaika papildinājums pazūd pēc pārstartēšanas, un dublikāti uzkrājas starp atkārtotiem savienojumiem. Pēc tīkla sakārtota systemd vienība ir viena iespēja, un distribūcijas tīkla pārvaldnieks ir otra. Ko vien izvēlaties, adresei jāpastāv pirms lietotne piesaistās, citādi pakalpojums ceļas nepareizajā ligzdā. Pārbaudiet ar ip address show dev lo pēc pārstartēšanas, nevis pēc manuālās komandas.

Piesaistīšana ir atsevišķs lēmums no adresēšanas. Lietotne, kas klausās katrā adresē, pieņem trafiku saskarnēs, kuras jūs nekad neesat paredzējis, tāpēc vērsiet to uz konkrētu pakalpojuma adresi. Tad vietējai ievades politikai ir ar ko precīzi saskaņoties.

Pieprasiet to CCD failā, ko centrs patiešām lasa

Serverī īpašumtiesību deklarācija nonāk katra klienta failā, ko izvēlas autentificētais kopīgais nosaukums, direktorijā, ko nosauc client-config-dir. Rinda ir iroute 10.66.0.10 255.255.255.255, viena uz adresi, un tā pasaka serverim, kuram vienaudzim jāsaņem trafiks uz šo galamērķi.

Divi sīkumi to klusi salauž. Faila nosaukumam jāatbilst nosaukumam, ko serveris patiešām izmanto, un tas atšķiras, kad spēlē ir username-as-common-name. Un iroute darbojas tikai TUN režīmā ar konfigurētu klienta konfigurācijas direktoriju, tāpēc tā pati rinda neko nedara tiltveida izvietojumā. Pievienojiet rindas esošajam failam, nevis aizstājiet to, jo tajā jau var būt fiksēta adrese vai push opcijas. OpenVPN 2.6 uzziņa dokumentē gan direktoriju, gan īpašumtiesību direktīvu.

Arī centra kodolam vajag ceļu uz šiem galamērķiem, lai vietēji ģenerēts trafiks nonāktu tuneļa procesā. Servera konfigurācijā route 10.66.0.10 255.255.255.255 aptver trafiku, ko rada pats serveris, bet citiem klientiem vajag push "route 10.66.0.10 255.255.255.255", lai paši uzzinātu galamērķi.

Maršrutēšana un autorizācija paliek atsevišķi. Nosūtītais maršruts pasaka klientam, kur sūtīt paketes, un neko nepiešķir; pakalpojumam joprojām jāpieņem zvanītājs ar saviem noteikumiem.

Pārbaudiet ievades politiku un atbildes ceļu

Uz aizstājvārdu adresēta pakete nonāk to īpašošajā resursdatorā kā vietēja ievade, tāpēc jautājums ir, vai vietējais ugunsmūris atļauj šo avotu un portu. Atļaujiet konkrēto pakalpojuma portu no VPN avota diapazona, nevis atveriet visu adresi.

Atbildēm vajag ceļu atpakaļ pie zvanītāja. Zvanītājam parastajā tuneļu baseinā šis ceļš jau pastāv, jo to nes tuneļa ierīce. Zvanītājam aiz cita maršrutēta tīkla vajag arī tā tīkla atgriešanās maršrutu, un tieši šeit asimetriski iestatījumi pazaudē paketes.

Uzmaniet otru klausītāju tajā pašā portā, kas piesaistīts citai adresei, jo kodols piegādā tai ligzdai, kas atbilst, un rezultāti izskatās nejauši. Pārbaudiet ar ss -lntp un apstipriniet, ka piesaistītā adrese ir pakalpojuma aizstājvārds. Avota NAT šeit nav vajadzīgs, un tā pievienošana paslēpj zvanītāja identitāti, no kuras atkarīgi jūsu žurnāli.

Pārbaudiet adreses un īpašumtiesības atsevišķi

Pārbaudiet divos soļos. Vispirms apstipriniet, ka īpašošais resursdators var sasniegt pakalpojumu uz sava aizstājvārda no sevis, kas atdala piesaistes un ugunsmūra problēmas no maršrutēšanas. Pēc tam pārbaudiet no īsta VPN zvanītāja, izmantojot pašas lietotnes autentifikāciju. Kad pirmais iztur un otrais neizdodas, trūkstošā daļa ir centra pusē.

Pārbaudiet arī atteices režīmus, kas pārdzīvo savienojumu: aizstājvārds paliek piešķirts, kad tunelis ir izslēgts, un centrs saglabā savu maršrutu, kad vienaudža nav. Neviens objekts viens pats nepierāda, ka pakalpojums ir sasniedzams, tāpēc divu soļu tests pārspēj vienu ping no klēpjdatora.