Kāpēc OpenVPN klienti netrāpa vārtejas IPsec selektoriem

Nosūtiet ping no vārtejas uz resursdatoru aiz attālā IPsec tuneļa un tas atbild tīri, tāpēc tunelis izskatās vesels un biļete virzās tālāk. Tad pievienots klients mēģina to pašu resursdatoru un nesaņem neko. Šis ping nekad nebija klienta plūsmas pierādījums, jo tas izgāja ar pašas vārtejas avota adresi un atbilda citam IPsec selektoram. Saprašana, kāpēc šie divi gadījumi atšķiras, ir lielākā daļa no labojuma.

Vārtejas ping pārbauda plūsmu, ko jūsu klients nekad neizmanto

Avota adrese nosaka, kura politika tiek piemērota. Vārtēs izveidots pakets iznāk ar adresi no tās vietējā LAN vai no tuneļa galapunkta, un politika, kas tam atbilst, tika rakstīta tieši šim gadījumam. Klienta pakets ierodas OpenVPN saskarnē ar adresi no klientu kopas, kas ir pilnīgi cits selektors.

Tāpēc kļūme izskatās pēc maršrutēšanas problēmas, lai gan patiesībā tā ir politikas tvēruma problēma. Sasniedzamība no vārtejas pierāda, ka partneris darbojas un priekšlikumi ir saskaņoti, un tā nepierāda neko par to, vai kopa ir aizsargāta.

Aizstumiet attālo prefiksu, kas lietotnei patiešām vajadzīgs

Ņemiet ilustratīvo pāri 10.8.0.0/24 pievienotiem klientiem un 172.30.239.0/25 aizsargātajam attālajam tīklam. Klientam vajadzīgs maršruts uz šo otro prefiksu, nevis uz vārtejas LAN un nevis uz kādu citu tuneļa adresi. Tieši kopā aizstumtais maršruts liek klientam vispār nodot šo satiksmi vārtejai. Bez tā pakets nekad nesasniedz politikas lēmumu, ko jūs atkļūdojat.

Community serverī, kas pieņem aizstumtos maršrutus, direktīva iegūst īsto masku: push "route 172.30.239.0 255.255.255.128". Access Server konfigurē to pašu galamērķi caur instalētās versijas privātā tīkla vai piekļuves noteikumu iestatījumiem, apzināti izvēloties maršrutēto vai pārtulkoto režīmu. Ģenerēto ugunsmūra ķēžu rediģēšana īpašnieka konfigurācijas vietā ir ceļš, kā strādājoša instalācija kļūst neatkārtojama.

Pēc pievienošanās lasiet klienta maršrutēšanas tabulu, nevis servera nodomu. Maršruts, kas aptver tikai kopu, nozīmē, ka aizstumšana nekad nav ieradusies, un noklusējuma maršruts caur tuneli ir plašāks par šo prasību un vēlāk jūs pārsteigs. Pārbaudiet masku un prefiksu, jo /25, aizstumts kā /24, sūta kaimiņu adrešu satiksmi ceļā, kas to nevar nest. Pēc tam apstipriniet, ka klients šim galamērķim izvēlējās tuneļa saskarni.

Panāciet, lai selektori ietvertu klientu kopu

Maršrutētai piekļuvei, kas saglabā klientu adreses, IPsec politikai jāaizsargā satiksme starp kopu un attālo prefiksu. Selektori, kas rakstīti pašas vārtejas LAN, pielaiž ping un izmet klienta pieprasījumu, un tā ir tieši tā asimetrija, kas sāka šo izmeklēšanu.

Pārbaudiet saskaņoto politiku un arī konfigurētos priekšlikumus, piemēram, ar ipsec statusall strongSwan vai līdzvērtīgu statusa komandu jūsu ieviešanai. Uz politiku balstītā IPsec parastais maršruts var norādīt uz fizisku saskarni, kamēr atbilstošā satiksme joprojām tiek šifrēta, tāpēc trūkstoša tuneļa ierīce neko nepierāda. Salīdziniet selektoru pārus ar kopu un prefiksu, ko pierakstījāt.

Vispārīgs avota NAT uz vārtejas var arī salauzt atbilstību. Ja masquerade noteikums pārraksta klienta avotu pirms politikas pārbaudes, pakets vairs neizskatās kā jūsu rakstītais selektors. Tas ir viens no iemesliem, kāpēc plašs masquerade noteikums ir slikts otrā VPN labojums: tas maina, kura politika tiek piemērota un kādu adresi reģistrē attālā puse. Atbrīvojiet satiksmi, ko plānojat maršrutēt, vai apzināti to pārtulkojiet un atjauniniet selektorus.

Apzināti izvēlieties maršrutēšanu vai tulkošanu

Maršrutēšana saglabā klienta adresi redzamu attālajai pusei, tāpēc attālie žurnāli un noteikumi pēc avota paliek jēgpilni, un tā prasa, lai attālā vārteja zinātu atgriešanās ceļu uz kopu. Tulkošana paslēpj kopu aiz vienas adreses, kas novērš atgriešanās maršruta problēmu un iznīcina katra klienta identitāti.

Izvēlieties vienu dizainu un pierakstiet to, jo abiem vajadzīgi dažādi selektori un cita ugunsmūra secība. Daļēji piemērots masquerade nonāk starp tiem un neapmierina nevienu. Pierakstītā izvēle ir arī tas, kas ļauj nākamajam inženierim atšķirt kļūdu no apzināta lēmuma.

Noslēdziet cilpu pārsūtīšanā un atbildē

Vārtejai jāpārsūta protokols un galamērķis, ko domājat, kas nozīmē ieslēgtu IP pārsūtīšanu un pārsūtīšanas ķēdi, kas atļauj pāri. Tad attālajai pusei atbildes jāsūta atpakaļ pa IPsec ceļu, un tas ir maršrutēšanas lēmums viņu vārtejā, nevis jūsējā. Abas puses ir parasta konfigurācija, un abas ir viegli atstāt pusceļā. Pārbaudiet tās atsevišķi, lai trūkstošs pārsūtīšanas noteikums netiktu sajaukts ar salauztu tuneli.

Pārbaudiet ar vienu īstu pieprasījumu no klienta uz lietotni, vērojot, kā tas šķērso OpenVPN saskarni, IPsec lēmumu un attālo resursdatoru. Apskatiet atbildi kā atsevišķu novērojumu, jo pienākošs pieprasījums un atbilde, kas nekad neatgriežas, no klienta vietas izskatās vienādi. Viens izsekots pieprasījums ir vērtīgāks par jebkuru ping skaitu no vārtejas.

Turiet galamērķa atļauju šauru, kamēr testējat, un apstipriniet, ka klients bez noteikuma nevar sasniegt pakalpojumu. Instalēts maršruts un izveidota asociācija nav tas pats, kas piešķirta piekļuve.