Kāpēc apakštīkls aiz OpenVPN klienta nav sasniedzams?

Ping uz servera tuneļa adresi izdodas, paša klienta maršrutu tabula izskatās pareiza, un LAN aiz šī klienta joprojām nav sasniedzams. Klienta maršrutēšanas tabula izskatās pareiza, serverim ir uz tuneli vērsts maršruts, un paketes joprojām pazūd. Tas ir klasiskais layer-3 tuneļa simptoms, kas nezina, ka viens no tā klientiem ir arī vārteja.

tun saskarnei nav nākamā lēciena katram klientam. Kodols redz vienu saskarni ar daudziem partneriem, tāpēc lēmums, kurš klients saņems paketi attālam LAN, jāpieņem OpenVPN procesa iekšienē. Šis lēmums tiek konfigurēts ar iroute, un bez tā pakešu nav kur iet.

Serveris maršrutē pēc klienta, nevis pēc saskarnes

Kad serverim jāsūta pakete uz klienta tuneļa adresi, atbilde ir viennozīmīga: adrese pieder šī klienta sesijai. Kad galamērķis ir viss apakštīkls aiz šī klienta, adrese nepieder nevienam, ko serveris pazīst, un kodola maršruts uz tuneli tikai saka "pa šo saskarni", nenorādot, kurš partneris.

OpenVPN to risina ar iekšēju maršrutu tabulu, kas galamērķa prefiksu saista ar konkrētu klientu. Šī tabula tiek veidota no iroute ierakstiem, tāpēc ar parastu maršrutu servera saimniekā nepietiek. Kodola maršruts nogādā paketi uz tuneļa saskarni; iekšējā saiste nosaka, kura sesija to saņem. Tāpēc arī labojums nekad neparādās kodola maršrutu izvadē.

Ja saistes nav, pakete nonāk serverī, atbilst tuneļa maršrutam un tiek izmesta, jo neviens klients nepieprasa galamērķi. Nekas nereģistrē tīru kļūdu, tāpēc kļūme izskatās kā kluss melnais caurums, nevis maršrutēšanas cilpa.

Rakstīt iroute ierakstu, kas nosauc klientu

iroute dzīvo klientam raksturīgā konfigurācijas failā, nevis servera galvenajā konfigurācijā. Novirziet serveri uz direktoriju ar opciju client-config-dir, pēc tam izveidojiet failu, kura nosaukums ir klienta sertifikāta kopīgais nosaukums, un ievietojiet tajā prefiksu.

Filiālei, kuras LAN ir 10.20.0.0/24 un kuras sertifikāta kopīgais nosaukums ir branch-router, failā šajā ceļā ir rinda, piemēram, iroute 10.20.0.0 255.255.255.0. Galvenajai konfigurācijai vajadzīga tikai direktorijas opcija; prefikss dzīvo pie klienta.

Kopīgais nosaukums ir trauslā daļa. Sertifikāts, kas izsniegts ar citu subject, vai izvietojums, kas autentificē lietotājus pēc lietotājvārda, kamēr fails ir nosaukts pēc sertifikāta, rada failu, kas nekad netiek lasīts. Pārbaudiet nosaukumu, ko serveris faktiski ziņo sesijai, un apsveriet opciju, kas liek nesaskanīgam klientam neizdoties, nevis klusi pieslēgties bez saviem maršrutiem. Faila pārdēvēšana atbilstoši sertifikātam ir piecu minūšu labojums, kas novērš ļoti garu vakaru.

Viens klients var piederēt vairāki prefiksi. Pievienojiet vienu iroute rindu katram tīklam un glabājiet sarakstu blakus pārējiem šī klienta iestatījumiem, lai saiste paliktu pārbaudāma.

Atgriešanās ceļa veidošana abos virzienos

Pakešu nogādāšana attālajā LAN ir puse darba. Klientam arī jāsūta šī LAN trafiks tunelī, ko parasti dara, spiežot maršrutu klientam: rinda, piemēram, push "route 10.8.0.0 255.255.255.0", pastāsta katram klientam, kā sasniegt servera puses tīklu. Filiālei līdzvērtīgais maršruts norāda uz tuneli visam, kas tai jāsasniedz servera pusē.

Atgriešanās virzienam vajadzīgs īpašnieks tālajā pusē. Tur kādam jāzina ceļš atpakaļ: statisks maršruts LAN maršrutētājā, kas VPN kopu novirza uz serveri, vai adrešu tulkošana serverī pirms trafika nokļūšanas LAN. Statiskais maršruts saglabā sākotnējās adreses redzamas žurnālos un piekļuves noteikumos, bet prasa LAN īpašnieka sadarbību; tulkošana ir patstāvīga, bet slēpj, kas faktiski pieslēdzās.

Pāradresācijai jābūt iespējotai servera saimniekā. Bez tās kodols pieņem paketi no tuneļa un atsakās to nodot LAN saskarnei, kas no klienta viedokļa izskatās tieši tāpat kā trūkstošs iroute.

Sasniedzamības pārbaude ar pareizajiem zondiem

Testējiet pa slāņiem, nevis pingējiet tālo galu un miniet. No servera pārbaudiet, vai prefiksa iekšējā saiste pastāv un vai kodola maršruts norāda uz tuneli. No klienta apstipriniet, ka aizspiestais maršruts ir instalēts un ka tā noklusējuma ceļš uz LAN adresi ir tunelis.

Pēc tam vērojiet paketes. Uzņemšana tuneļa saskarnē parāda, vai serveris pārraida pretī klientam, un uzņemšana LAN saskarnē parāda, vai tas pārsūta. Ja pirmā rāda paketes, bet otrā neko, problēma ir pārsūtīšanā vai filtrā; ja neviena neko nerāda, meklēšana neizdevās agrāk.

Divi serveri, kas savienoti ar tuneli, atkārto to pašu noteikumu abās pusēs: katram vajadzīgs iroute otra kopai, un katram vajadzīgs maršruts un pāradresācija, kas padara ceļu simetrisku. Maršrutēšana un politika šeit ir atsevišķas lietas. Maršrutēšana izlemj, kur pakete var iet, bet FORWARD noteikums izlemj, vai drīkst, tāpēc klients ar divām iroute rindām sasniedz abus prefiksus, ja vien filtrs nepasaka citādi.