Kopii la /32 de la tunelo ne enkursigos la oficejan subreton
La adreso, kiun la VPN donas al via adaptilo, priskribas la ligon, ne la celon. Aldonu la resurso-prefikson al la profilo kaj lasu la defaŭltan trankvila.
La VPN konektiĝas, la interfaco montras adreson kun tridek-du-bita masko, kaj la oficeja servilo restas neatingebla. La sekva movo ofte estas reuzi tiun maskon en itinero, laŭ la teorio ke la interfaco priskribas kion la tunelo povas atingi. Ĝi ne faras. Tiu adreso priskribas la lokan finon de punkto-al-punkta ligo, kaj la celo, pri kiu vi zorgas, troviĝas en alia prefikso ĉe ĝia alia flanko.
Du malsamaj aferoj estas konfuzataj: la adreso, kiun la tunelo donis al vi, kaj la reto, kiun vi volas atingi tra ĝi.
Du adresoj, du taskoj
En punkto-al-punkta tunelo, la klienta adreso ofte estas unu sola gastiganta adreso, ĉar estas precize unu samtavolo ĉe la alia fino de la ligo. Ne estas komuna segmento kaj ne estas ARP, do masko, kiu sur Ethernet ŝajnus absurda, estas tute normala ĉi tie.
La cela prefikso estas fakto pri la oficeja reto, ne pri la tunelo. Se vi bezonas unu servilon, la itinero estas gastiga itinero por tiu servilo. Se vi bezonas la tutan oficejan subreton, la itinero estas la subreto. Neniun el la du respondoj eblas legi de la interfaco, kaj elekti unu ĉar ĝi aperis apud la tunela adreso estas kiel funkcianta agordo rompiĝas.
| What you need to reach | What to install |
|---|---|
| One server, nothing else | A host route for that address |
| The office subnet | A route for the subnet prefix |
| Everything in the private space | Only if the requirement says so, and only with the owner's approval |
Tiu tria vico estas kie optimismo fariĝas ĉeso. Enkursigi tutan privatan gamon en tunelon, kiu servas nur unu lokon, puŝas nerilatan trafikon en vojon, kiu ne povas liveri ĝin, kaj la rezultaj fiaskoj aspektas kiel rompita VPN anstataŭ tro larĝa itinero.
Elektu la prefikson el la postulo
Skribu la postulon kiel frazon antaŭ ol tuŝi profilon: kiuj gastigantoj devas esti atingeblaj, kaj kio estas la plej mallarĝa prefikso, kiu kovras ilin? Unu servilo estas gastiga itinero. Subreto estas subreta itinero. Gamo de subretoj estas resumo, kaj resumo estas promeso, ke ĉiu adreso ene estas atingebla, kio malofte veras.
Poste kontrolu la nombron kontraŭ tio, kion la oficejo efektive uzas. Kopii prefikson el babileja mesaĝo sen konfirmi ĝin kontraŭ la adresada plano de la loko estas kiel itinero finiĝas montrante al subreto, kiun neniu posedas.
Memoru ankaŭ, ke itinero estas vojo, ne permeso. La enirejo ankoraŭ decidas, ĉu via kliento rajtas uzi la celon, kaj servo ankoraŭ povas rifuzi vin. Ĝuste instali la itineron venigas la paketon tien kaj respondas nenion pri rajtigo.
Aldonu al la profilo, neniam anstataŭigu ĝin
Itineroj en NetworkManager-profilo estas plurvalora eco, kaj la diferenco inter agordi kaj aldoni estas unu signo. Uzu la plus-formon por aldoni eron kaj konservi ĉion jam konservitan.
nmcli connection modify uuid 11111111-2222-4333-8444-555555555555 \
+ipv4.routes "10.40.20.9/32"Sen la pluso, la atribuo anstataŭigas la tutan liston. Sur profilo, kiu jam portas plurajn prefiksojn, tio silente forigas la funkciantajn, kaj la simptomo venas poste kiel servo, kiu antaŭe estis atingebla de ĉi tiu tekkomputilo.
Uzu la UUID anstataŭ la nomon. Nomoj duobliĝas post restarigoj, kaj la konekto, kiun vi redaktas, eble ne estas tiu, kiu portas vian trafikon. Unue kontrolu ekzistantan identan eron, ĉar aldoni duoblaĵon estas malordema eĉ kiam ĝi estas sendanĝera.
La referenco de itineraj ecoj dokumentas la celon, la laŭvolan sekvan salteton, la metrikon kaj la atributan sintakson por la instalita versio. Legu ĝin antaŭ ol aldoni sekvan salteton, ĉar ĉu ĝi necesas dependas de la integriĝo kaj la topologio, kaj diveni ĝin el la unua adreso en interfaca listo ne estas metodo.
Defaŭlta itinero kaj DNS estas apartaj decidoj
Adding an office prefix says nothing about where the rest of your traffic goes. If policy requires ordinary internet traffic to stay outside the tunnel, that is the ipv4.never-default decision, and it belongs to whoever owns the connection policy rather than to whoever is fixing one unreachable server.
Aŭtomataj itineroj estas la alia afero, kiun oni ne perturbu senzorge. Subpremi ilin por solvi unu mankan eron povas forigi plurajn funkciantajn, kaj la persono, kiu tion proponis, kutime rigardis alian profilon kun aliaj puŝoj.
DNS havas sian propran vojon kaj siajn proprajn fiaskojn. Nomo, kiu solviĝas al la ĝusta adreso per la malĝusta solvilo, aŭ solvilo, kiu ne povas respondi por la privata zono, aspektos kiel enkursiga problemo dum la itinero estas perfekta. Testu la adreson kaj la nomon aparte, poste decidu, kiu tavolo efektive fiaskis.
Kontrolu, kio estis aplikita
Konservita modifo ne estas aplikita modifo. Rekonektiĝu tra la subtenata vivociklo de la administrilo, poste rigardu la faktan itineron por la celata celo kaj la politikajn regulojn, kiuj decidas, kiu tabelo estas konsultata.
Se la prefikso estas tie kaj la konekto ankoraŭ fiaskas, vi transiris al alia problemo: elekto de fonta adreso, revena itinero ĉe la malproksima fino, aŭ servo, kiu rifuzas vian klienton. Ĉiu el tiuj estas pli bona loko por rigardi ol la profilo, kiun vi jam korektis.