Plena tunelo de FortiClient: enkursigu nur la oficejan subreton

La tunelo ekfunkcias, la ikono verdiĝas kaj la loka reto malaperas: printiloj, la NAS kaj la oficeja enkursigilo ĉiuj ĉesas respondi. FortiClient faras tion, kion la profilo petis. La pordego puŝis defaŭltan itineron, la kliento instalas ĝin, kaj ĉiu paketo nun havas vojon en la tunelon. La riparo estas redakto de la enkursiga tabelo kun DNS-redakto malantaŭ ĝi, kaj la ordo de tiuj redaktoj decidas, ĉu la maŝino finiĝos pli bone aŭ pli malbone.

Kion la kliento instalas, kaj kial la LAN malaperis

Komencu legante la tabelon anstataŭ la klientan interfacon. En macOS netstat -rn presas la tutan tabelon kaj route -n get default nomas la interfacon kaj metrikon, kiuj nun venkas; en Linux la paro estas ip route show kaj ip route get 8.8.8.8. Ambaŭ respondas unu demandon: kiu rikordo portos paketon, kiu kongruas kun nenio pli specifa.

La nomo de la tunela aparato ne estas fiksa. Profilo IKEv2 en macOS kutime montras utun kun nombro, la kliento SSL VPN montras ppp0, kaj OpenVPN montras tun0. Du defaŭltaj itineroj ankaŭ povas ĉeesti samtempe kun malsamaj metrikoj, kaj la klienta rikordo eble transprenos nur post rekonekto anstataŭ en la momento, kiam ĝi aperas. Tial du tabelaj elpresaĵoj prenitaj kvin minutojn aparte povas rakonti malsamajn historiojn.

Kial la defaŭlta itinero de la tunelo devas foriri unue

La kerno elektas la plej longan kongruan prefikson, kaj kiam pluraj itineroj estas egale specifaj, ĝi elektas tiun kun la plej malalta metriko. Kliento, kiu instalas 0.0.0.0/0 kun pli bona metriko, do gajnas ĉiun celon sen forigi la originan defaŭltan itineron, kaj tial la fizika itinero ankoraŭ estas en la tabelo kaj ankoraŭ klarigas la interrompon. Forigi unue la defaŭltan itineron de la tunelo restarigas la antaŭan konduton. Nur tiam prefiksa itinero tra la tunelo faras tion, kion ĝia aŭtoro intencis.

Aldoni prefiksojn antaŭ tiu paŝo estas la eraro, kiu produktas duone funkciantan maŝinon. Trafiko por la nova prefikso sekvas la tunelon, kaj ĉio nelistigita ankaŭ sekvas la defaŭltan itineron de la tunelo, do nenio aspektas rompita ĝis iu malfermas servon, kiun neniu aldonis. Forigu, restarigu, poste aldonu, kaj la meza stato restas antaŭvidebla.

La sinsekvo en macOS kaj en Linux

En macOS la sinsekvo forigas la defaŭltan itineron de la tunelo, restarigas la fizikan defaŭltan itineron kaj resendas unu oficejan prefikson en la tunelon. Anstataŭigu la ilustrajn interfacnomojn ĉi tie per tiuj el via propra tabelo.

sudo route delete -net default -interface utun4
sudo route add -net 0.0.0.0 -interface en0
sudo route add -net 10.20.0.0 -netmask 255.255.0.0 -interface utun4

En Linux la sama ordo uzas alian ilon, kun la pordego de la LAN por la defaŭlta itinero kaj la tunela aparato por la oficeja prefikso. La malnova komando route ankoraŭ akceptas la malnovan sintakson, sed ip route estas la formo, kiu kongruas kun la nuna dokumentaro.

sudo ip route del default dev tun0
sudo ip route add default via 192.168.50.1
sudo ip route add 10.20.0.0/16 dev tun0

Kiam la itinero bezonas sekvan salteton anstataŭ aparaton, prenu la peer el la eligo de la kliento. Divenado donas unu el du eraroj, kaj ili signifas malsamajn aferojn: malĝusta pordego donas tuj network unreachable, dum malĝusta tunela celo donas tempolimon. Legu, kiun vi ricevis, antaŭ ol denove ŝanĝi la komandon.

Prefiksoj, la solvilo kaj la DMZ, kiu restas malluma

Unu prefikso malofte kovras la laboron. Aplikaj serviloj, administraj retoj, la DMZ kaj la DNS-serviloj mem povas ĉiu sidi en malsama gamo, do listigu ĉiun gamon, kiun vi povas nomi, antaŭ ol komenci, kaj testu serĉon apud ĉiu ping. Celo malkovrita dum la testado estas tiu, kiu forgesiĝas en la ŝanĝprotokolo. Itinero, kiu respondas laŭ adreso sed malsukcesas laŭ nomo, kutime estas solvila problemo en enkursiga kostumo.

La solvilo estas aparta decido. Kiam la profilo puŝis internajn DNS-servilojn, forpreni la defaŭltan itineron povas lasi tiujn adresojn neatingeblaj por publikaj nomoj aŭ atingeblaj nur tra la tunelo, kaj ambaŭ statoj produktas konfuzajn partajn rezultojn. Enkursigu la adresojn de la solvilo tra la tunelo, aŭ agordu solvon laŭ domajno, por ke publikaj serĉoj uzu la lokan solvilon.

La Linuxa SSL-kliento havas kampan fiaskon, kiun indas koni: la tunelo konektiĝas, la oficeja LAN respondas, kaj unu DMZ-gamo restas malluma. La mankanta peco estas itinero por tiu gamo tra la tunela pordego, kaj la pordego malsamas inter maŝinoj, do malmola adreso estas la maniero, kiel la sekva tekkomputilo rompiĝas. Derivu ĝin el la stato de la kliento kaj tenu la komandon memdokumentan:

PEER=$(ip -4 addr show dev ppp0 | awk '/peer/ {print $4}' | cut -d/ -f1)
sudo ip route add 192.168.30.0/24 via "$PEER"

Legu la du valorojn antaŭ ol ruli ĝin. peer estas la malproksima fino de punkto-al-punkta tunelo, kaj tio estas la adreso, kiun la DMZ-itinero bezonas; en enkursigita tunelo la ekvivalento estas la interfaco aŭ la pordego, kiun la kliento raportas. Se neniu aperas, la kliento ne estas en la reĝimo, kiun vi supozis.

Post la sekva konekto, kaj kiam ĉesi fari tion loke

FortiClient rekonektiĝas post dormo aŭ retŝanĝo kaj reinstalas tion, kion la profilo specifas. Manaj itineroj do postvivas nur ĝis la sekva konekto, kaj tio estas ĝuste la intervalo, en kiu unu sukcesa testo povas aspekti kiel riparo. Itinero, kiu malaperas dum la nokto, estas atendata konduto, ne nova misfunkcio.

Ekzistas du daŭraj respondoj. Skripto, kiu reŝutas la korekton post ĉiu konekto, estas provizora solvo, kiu povas postvivi sian aŭtoron, dum profilo de dividita tunelo de la pordega administranto estas la vera riparo, ĉar tiam la kliento instalas nur la gamojn, kiujn la laboro bezonas. Petu la duan kaj uzu la unuan nur dum vi atendas. Kontrolu ankaŭ la politikon, kiun vi akceptis, antaŭ ol dividi plenan tunelon loke, ĉar la fora reto eble dependas de tio vidi vian tutan trafikon.

La kontrolo estas mallonga: legu la tabelon, forigu la defaŭltan itineron de la tunelo, restarigu la defaŭltan itineron de la LAN, aldonu ĉiun prefikson, riparu la solvon aparte, kaj atendu, ke la itineroj revenos ĉe rekonekto.