Ang pagkopya ng /32 ng tunnel ay hindi magru-ruta sa subnet ng opisina
Ang address na ibinibigay ng VPN sa adapter mo ay naglalarawan ng link, hindi ng destinasyon. Idagdag ang prefix ng resource sa profile at hayaang tahimik ang default na ruta.
Kumokonekta ang VPN, nagpapakita ang interface ng address na may tatlumpu’t dalawang bit na mask, at nananatiling hindi maabot ang server ng opisina. Ang susunod na hakbang ay madalas na muling gamitin ang mask na iyon sa isang ruta, sa teoryang inilalarawan ng interface kung hanggang saan kayang maabot ng tunnel. Hindi ganoon. Inilalarawan ng address na iyon ang lokal na dulo ng link na punto-sa-punto, at ang destinasyong mahalaga sa iyo ay nasa ibang prefix sa kabilang panig.
Dalawang magkaibang bagay ang pinaghalo: ang address na ibinigay sa iyo ng tunnel, at ang network na gusto mong maabot sa pamamagitan nito.
Dalawang address, dalawang trabaho
Sa tunnel na punto-sa-punto, ang address ng client ay madalas na isang host address lamang dahil may eksaktong isang peer sa kabilang dulo ng link. Walang pinagsasaluhang segment at walang ARP, kaya ang mask na magmumukhang walang katuturan sa Ethernet ay ganap na normal dito.
Ang prefix ng destinasyon ay katotohanan tungkol sa network ng opisina, hindi tungkol sa tunnel. Kung kailangan mo ng isang server, ang ruta ay host route para sa server na iyon. Kung kailangan mo ang buong subnet ng opisina, ang ruta ay ang subnet. Wala sa dalawang sagot ang nababasa mula sa interface, at ang pagpili ng isa dahil lumitaw ito sa tabi ng address ng tunnel ay kung paano nasisira ang isang gumaganang setup.
| 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 |
Ang ikatlong hilera na iyon ang lugar kung saan nagiging pagkagambala ang optimismo. Ang pagruruta ng buong pribadong saklaw papasok sa tunnel na naglilingkod lamang sa isang site ay nagtutulak ng walang kaugnayang trapiko sa landas na hindi kayang maghatid nito, at ang mga resultang pagkabigo ay mukhang sirang VPN kaysa sobrang lapad na ruta.
Piliin ang prefix mula sa pangangailangan
Isulat ang pangangailangan bilang isang pangungusap bago hawakan ang profile: aling mga host ang dapat maabot, at ano ang pinakamakitid na prefix na sumasaklaw sa kanila? Ang isang server ay host route. Ang subnet ay subnet route. Ang saklaw ng mga subnet ay buod, at ang buod ay pangako na ang bawat address sa loob nito ay maaabot, na bihirang totoo.
Pagkatapos ay ihambing ang bilang sa aktwal na ginagamit ng opisina. Ang pagkopya ng prefix mula sa chat message nang hindi ito kinukumpirma sa plano ng pag-address ng site ay kung paano nauuwi ang ruta sa pagturo sa subnet na walang may-ari.
Tandaan din na ang ruta ay landas, hindi pahintulot. Nagpapasya pa rin ang gateway kung maaaring gamitin ng client mo ang destinasyon, at maaari ka pa ring tanggihan ng isang serbisyo. Ang wastong pag-install ng ruta ay naghahatid ng packet doon at walang sinasagot tungkol sa awtorisasyon.
Idagdag sa profile, huwag kailanman palitan ito
Ang mga ruta sa isang NetworkManager profile ay multi-value na property, at ang pagkakaiba ng pag-set at pagdagdag ay isang character. Gamitin ang plus form para magdagdag ng entry at mapanatili ang lahat ng naka-save na.
nmcli connection modify uuid 11111111-2222-4333-8444-555555555555 \
+ipv4.routes "10.40.20.9/32"
Kung walang plus, pinapalitan ng assignment ang buong listahan. Sa profile na may dalang ilang prefix na, tahimik nitong binubura ang mga gumagana, at ang sintomas ay dumarating mamaya bilang serbisyong dating maaabot mula sa laptop na ito.
Gamitin ang UUID sa halip na pangalan. Nadodoble ang mga pangalan pagkatapos ng restores, at ang koneksyong ine-edit mo ay maaaring hindi ang nagdadala ng trapiko mo. Suriin muna kung may umiiral nang kaparehong entry, dahil ang pagdagdag ng duplicate ay magulo kahit hindi ito nakakasama.
Ang reference ng mga property ng ruta ay nagdodokumento ng destinasyon, opsyonal na susunod na hop, metric at syntax ng attribute para sa naka-install na bersyon. Basahin ito bago magdagdag ng susunod na hop, dahil nakadepende sa integration at topology kung kailangan ito, at ang paghula mula sa unang address sa listahan ng interface ay hindi paraan.
Ang default na ruta at DNS ay magkaibang desisyon
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.
Ang mga awtomatikong ruta ang isa pang bagay na hindi dapat gambalain nang basta-basta. Ang pagsupil sa mga ito para ayusin ang isang nawawalang entry ay maaaring mag-alis ng ilang gumagana, at ang taong nagmungkahi nito ay madalas na tumitingin sa ibang profile na may ibang push.
May sariling landas at sariling pagkabigo ang DNS. Ang pangalang nare-resolve sa tamang address sa maling resolver, o resolver na hindi makasagot para sa pribadong zone, ay magmumukhang problema sa routing habang perpekto ang ruta. Subukan ang address at pangalan nang hiwalay, pagkatapos ay magpasya kung aling layer ang aktwal na nabigo.
I-verify kung ano ang inilapat
Ang naka-save na pagbabago ay hindi inilapat na pagbabago. Kumonekta muli sa pamamagitan ng sinusuportahang lifecycle ng manager, pagkatapos ay tingnan ang aktwal na ruta para sa nilalayong destinasyon at ang mga patakaran ng patakaran na nagpapasya kung aling talahanayan ang kinukonsulta.
Kung naroon ang prefix at nabibigo pa rin ang koneksyon, lumipat ka sa ibang problema: pagpili ng source address, return route sa malayong dulo, o serbisyong tumatanggi sa client mo. Bawat isa sa mga iyon ay mas magandang lugar na tingnan kaysa sa profile na naitama mo na.