Buong tunnel ng FortiClient: i-route lamang ang subnet ng opisina

Bumangon ang tunnel, nagiging berde ang icon, at nawawala ang lokal na network: huminto sa pagsagot ang mga printer, ang NAS at ang router ng opisina. Ginagawa ng FortiClient ang hiningi ng profile. Nagtulak ang gateway ng default na ruta, ini-install ito ng client, at bawat packet ay may daan na ngayon papasok sa tunnel. Ang pag-aayos ay isang pagbabago sa talahanayan ng ruta na may kasamang pagbabago sa DNS, at ang pagkakasunod-sunod ng mga pagbabagong ito ang nagpapasya kung ang makina ay mas mahusay o mas masama ang kahihinatnan.

Ano ang ini-install ng client, at bakit nawala ang LAN

Magsimula sa pagbasa ng talahanayan sa halip na interface ng client. Sa macOS, ipiniprint ng netstat -rn ang buong talahanayan at pinangalanan ng route -n get default ang interface at metric na nananalo ngayon; sa Linux ang pares ay ip route show at ip route get 8.8.8.8. Pareho silang sumasagot sa isang tanong: aling entry ang magdadala ng packet na hindi tumutugma sa anumang mas tiyak.

Ang pangalan ng device ng tunnel ay hindi fixed. Ang isang IKEv2 profile sa macOS ay karaniwang nagpapakita ng utun na may numero, ang SSL VPN client ay nagpapakita ng ppp0, at ang OpenVPN ay nagpapakita ng tun0. Maaaring may dalawang default na ruta sa parehong oras na may magkaibang metric, at ang entry ng client ay maaaring kumuha ng kontrol pagkatapos lamang ng muling pagkonekta at hindi sa sandaling lumitaw ito. Kaya naman ang dalawang dump ng talahanayan na kinuha limang minuto ang layo ay maaaring magkuwento ng magkaibang kuwento.

Bakit dapat mauna ang default na ruta ng tunnel

Pinipili ng kernel ang pinakamahabang tugmang prefix, at kapag maraming ruta ang pantay na tiyak pinipili nito ang may pinakamababang metric. Kaya ang client na nag-i-install ng 0.0.0.0/0 na may mas mahusay na metric ay nananalo sa bawat destinasyon nang hindi binubura ang orihinal na default, at iyon ang dahilan kung bakit ang pisikal na ruta ay nasa talahanayan pa rin at nagpapaliwanag pa rin ng pagkaantala. Ang alisin muna ang default na ruta ng tunnel ay nagbabalik ng dating gawi. Doon lamang gagawin ng prefix na ruta sa tunnel ang inilayon ng may-akda nito.

Ang magdagdag ng prefix bago ang hakbang na iyon ay ang pagkakamaling gumagawa ng kalahating gumaganang makina. Ang trapiko para sa bagong prefix ay sumusunod sa tunnel, at lahat ng wala sa listahan ay sumusunod din sa default na ruta ng tunnel, kaya walang mukhang sira hanggang may magbukas ng serbisyo na walang nagdagdag. Burahin, ibalik, pagkatapos ay idagdag, at ang intermediate na estado ay nananatiling mahulaan.

Ang pagkakasunod-sunod sa macOS at sa Linux

Sa macOS, binubura ng pagkakasunod-sunod ang default na ruta ng tunnel, ibinabalik ang pisikal na default, at ibinabalik ang isang prefix ng opisina sa tunnel. Palitan ang mga halimbawang pangalan ng interface dito ng mga mula sa sarili mong talahanayan.

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

Sa Linux, ang parehong pagkakasunod-sunod ay gumagamit ng ibang tool: ang gateway ng LAN para sa default na ruta at ang device ng tunnel para sa prefix ng opisina. Tumatanggap pa rin ang lumang utos na route ng lumang sintaks, ngunit ang ip route ay ang anyo na tumutugma sa kasalukuyang dokumentasyon.

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

Kapag ang ruta ay nangangailangan ng susunod na hop sa halip na device, kunin ang peer mula sa output ng client. Ang paghula ay gumagawa ng isa sa dalawang error, at magkaiba ang kahulugan: ang maling gateway ay agad na nagbibigay ng network unreachable, habang ang maling target ng tunnel ay nagbibigay ng timeout. Basahin kung alin ang nakuha mo bago mo muling baguhin ang utos.

Mga prefix, ang resolver at ang DMZ na nananatiling madilim

Bihirang masaklaw ng isang prefix ang buong gawain. Ang mga application server, management network, DMZ at ang mga DNS server mismo ay maaaring nasa magkaibang saklaw, kaya ilista ang bawat saklaw na mababanggit mo bago magsimula at subukan ang isang lookup sa tabi ng bawat ping. Ang destinasyong natuklasan sa gitna ng pagsubok ang siyang nakakalimutan sa talaan ng pagbabago. Ang rutang sumasagot sa address ngunit nabigo sa pangalan ay karaniwang problema ng resolver na nakasuot ng routing.

Ang resolver ay hiwalay na desisyon. Kapag nagtulak ang profile ng mga internal na DNS server, ang pag-alis ng default na ruta ay maaaring mag-iwan sa mga address na iyon na hindi maabot para sa mga pampublikong pangalan o maabot lamang sa pamamagitan ng tunnel, at parehong estado ay nagbibigay ng nakalilitong bahagyang resulta. I-route ang mga address ng resolver sa tunnel, o i-configure ang resolution ayon sa domain upang ang mga pampublikong lookup ay gumamit ng lokal na resolver.

Ang Linux SSL client ay may field-specific na pagkabigo na sulit malaman: kumokonekta ang tunnel, sumasagot ang LAN ng opisina, at isang saklaw ng DMZ ang nananatiling madilim. Ang kulang na piraso ay isang ruta para sa saklaw na iyon sa gateway ng tunnel, at nag-iiba ang gateway sa bawat makina, kaya ang hardcoded na address ang paraan kung paano masisira ang susunod na laptop. Kunin ito mula sa estado ng client at panatilihing nagsasalarawan sa sarili ang utos:

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"

Basahin ang dalawang halaga bago ito patakbuhin. Ang peer ay ang malayong dulo ng point-to-point na tunnel, at iyon ang address na kailangan ng ruta ng DMZ; sa routed na tunnel ang katumbas ay ang interface o gateway na iniuulat ng client. Kung wala sa dalawa ang lumitaw, wala ang client sa mode na inakala mo.

Pagkatapos ng susunod na koneksyon, at kailan ito ititigil sa lokal

Muling kumokonekta ang FortiClient pagkatapos ng pagtulog o pagbabago ng network at muling ini-install ang itinakda ng profile. Kaya ang mga manu-manong ruta ay nabubuhay lamang hanggang sa susunod na koneksyon, at iyon ang eksaktong agwat kung saan ang isang matagumpay na pagsubok ay maaaring magmukhang pag-aayos. Ang rutang nawawala magdamag ay inaasahang gawi, hindi bagong sira.

May dalawang pangmatagalang sagot. Ang script na muling nagpapatakbo ng pagwawasto pagkatapos ng bawat koneksyon ay isang pansamantalang solusyon na maaaring mabuhay nang mas matagal kaysa sa may-akda nito, samantalang ang split-tunnel na profile mula sa administrator ng gateway ang tunay na pag-aayos, dahil ini-install lamang ng client ang mga saklaw na kailangan ng gawain. Hingin ang pangalawa at gamitin ang una habang naghihintay lamang. Suriin din ang patakarang sinang-ayunan mo bago hatiin ang buong tunnel sa lokal, dahil maaaring umaasa ang remote na network na makita ang lahat ng trapiko mo.

Maikli ang checklist: basahin ang talahanayan, burahin ang default na ruta ng tunnel, ibalik ang default na ruta ng LAN, idagdag ang bawat prefix, ayusin ang resolution nang hiwalay, at asahan na babalik ang mga ruta sa muling pagkonekta.