OpenVPN redirect-gateway: ko katra karodziņa dara ar maršrutiem

Savienojieties ar redirect-gateway profilā, un jūsu datora noklusējuma maršruts var pazust, sadalīties divos vai palikt tieši tur, kur bija, atkarībā no karodziņiem, ko neviens nelasa divreiz. Opcija maina tikai maršrutēšanas stāvokli un neko citu, tāpēc vienīgais uzticamais pierādījums tam, ko tā izdarīja, ir tabula, ko klients pēc tam instalēja. Tālāk ir tabula pēc savienojuma, maršruts, kas uztur dzīvu pašu tuneli, un IPv6 datplūsma, ko direktīva nekad neapgalvo, ka aptver. Katrs solis ir komanda, ko varat izpildīt klientā, kamēr tunelis ir ieslēgts.

Ko katra karodziņa dara ar noklusējuma maršrutu

Bez neviena karodziņa opcija noņem parasto noklusējuma maršrutu un tā vietā ievieto tuneli, tāpēc vecā vārteja pazūd no tabulas, kamēr savienojums ir aktīvs. Pievienojiet def1, un šis noklusējums paliek sarakstā, darbu veic divi šaurāki maršruti. Pievienojiet bypass-dhcp, un arī DHCP maršruts izdzīvo, kas ir svarīgi tīklā, kur klientam vēl jāsasniedz vietējais DHCP serveris. Karodziņu saraksts OpenVPN 2.6 rokasgrāmatas lapā ir pietiekami īss, lai to izlasītu vienreiz, un katrs ieraksts maina, kuri maršruti nonāk tabulā.

Uzspiests variants uzvedas tāpat, kad tas ierodas, tāpēc klienta profilā var nebūt nekā, kamēr tabula izskatās pilnībā pāradresēta. Tas ir normāli: serveris nosūtīja karodziņus, klients tos piemēroja, un vietējais fails direktīvu nekad neminēja. Kad grūdiens izskatās neko nedarošs, pārbaudiet klienta puses filtru, kas pieņem vai noraida izvilktos variantus, jo noraidīts variants nevienā pusē neizraisa kļūdu.

def1 uzvar ar specifiskumu, neaizskarot jūsu noklusējumu

Divi pusnoklusējuma maršruti kopā aptver IPv4 telpu, 0.0.0.0/1 un 128.0.0.0/1. Katrs ir specifiskāks par 0.0.0.0/0, tāpēc meklēšana dod priekšroku tiem, kamēr īstais noklusējums paliek tabulā visam, kas prasa vismazāk specifisko atbilstību.

Lasiet tabulu, nevis profilu, jo tikai tabula parāda, kurā no šiem gadījumiem jūs esat. Lai tos atšķirtu, pietiek ar divām rindām:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Pievērsiet uzmanību saskarnei un metrikai katrā rindā, ne tikai galamērķim. Noklusējums, kas norāda uz tuneli, un pāris pusnoklusējumu, kas norāda uz tuneli, apraksta to pašu nodomu un neizdodas atšķirīgi, kad tunelis krīt, jo vienā gadījumā rezerves ceļš vēl pastāv. Ierakstiet abus laukus izmaiņu piezīmē. Izdzīvojušais rezerves ceļš dažkārt ir tas, kas notur attālo sesiju dzīvu pietiekami ilgi, lai salabotu tuneli, un tas ir arī tas, kas noplūdina datplūsmu, kad nodoms bija pilnīgs tunelis.

Turiet tuneļa galapunktu sasniedzamu

Klientam vajadzīgs maršruts uz tuneļa tālo galu, kas pats neiet caur tuneli. OpenVPN instalē šo resursdatora maršrutu pirms jebkā cita maiņas, un manuāla maršruta rediģēšana vai otrs VPN klients var to noņemt. Pēc tam simptoms ir savienojums, kas ziņo, ka ir savienots, un pēc tam neko neizlaiž.

Kamēr tunelis ir ieslēgts, pajautājiet kodolam, kuru saskarni tas izmantotu galapunkta adresei. Atbildē jānorāda fiziskā saskarne un tās vārteja, nekad tun0:

ip route get 198.51.100.20

Ja šī meklēšana atgriež tuneļa ierīci, tunelis pārvadā savu transportu un sabruks, tiklīdz kādam paketei būs jāiziet. Vietējie prefiksi, otrs adapteris un uz politiku balstīta maršrutēšana šeit joprojām ir svarīgi, tāpēc pāradresācija, kas strādā tīrā klēpjdatorā, var neizdoties resursdatorā ar pārvaldības saskarni un diviem noklusējumiem. Parasti vaino profilu tajā, ko izdarīja adrešu plāns.

IPv6 datplūsma turpina izmantot savu tabulu

IPv4 pāradresācija atstāj IPv6 mierā, un abas saimes maina dažādi karodziņi. Divkāršas kaudzes resursdatorā ar strādājošu v6 noklusējumu v4 datplūsma var pilnībā sēdēt tunelī, kamēr katrs v6 spējīgais galamērķis iziet pa fizisko saiti. Resursdators, kas vienā tabulā izskatās pareizi, otrā noplūst.

Pēc savienojuma pārbaudiet v6 tabulu, nevis pieņemiet, ka tunelis to aptvēra. Direktīva nes adreses saimes karodziņus tieši šī iemesla dēļ, un profils, kas tos izlaiž, manto to, ko platforma dara pēc noklusējuma:

ip -6 route show default
ip -6 route get 2001:db8::10

Pierādiet, kuru saskarni izmanto lietojumprogramma

Savienots stāvoklis nav bloķēšana, un maršruta maiņa nav avārijas slēdzis. Ja tiešai datplūsmai jāapstājas, kad tunelis neizdodas, šī politika dzīvo ugunsmūrī un tai vajadzīgs savs tests.

Pārbaudiet ceļu, ko lietojumprogramma patiešām iet, nevis ceļu, ko apraksta profils. Vispirms pajautājiet maršrutu, pēc tam pēc kārtas piesaistiet pieprasījumu katrai saskarnei un salīdziniet, ko ziņo tālā puse:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

Ja abi pieprasījumi atgriež vienu un to pašu adresi, lietojumprogramma neizmanto tuneli, lai gan maršrutēšanas tabula saka, ka tai vajadzētu. Ja izdodas tikai ar tuneli saistītais pieprasījums, fiziskais ceļš šim galamērķim ir filtrēts un tunelis dara to, ko jūs lūdzāt. Ierakstiet karodziņus, instalētos maršrutus, galapunkta meklēšanu un abus izejas rezultātus izmaiņu žurnālā, lai nākamais cilvēks mantotu faktus, nevis ekrānuzņēmumu.