Bumagsak ang OpenVPN pagkatapos ng DHCP renewal: panatilihin ang ruta ng endpoint

Kumokonekta ang tunnel, pagkatapos pinapatay ito ng renewal ng lease sa access link, at sinisisi ng log ang timeout sa halip na ruta. Walang nagbago sa configuration ng VPN, at iyon ang palatandaan: may nagbago sa labas nito. May event na DHCP na nagsulat muli ng address o gateway, at ang host route na nagpapanatiling maabot ang endpoint ng tunnel ay tumuturo na ngayon sa susunod na hop na wala na. Problema ito sa pagmamay-ari bago maging problema sa routing.

Ihambing ang sintomas sa mga half-default na ruta

Sa redirect-gateway def1, nag-i-install ang OpenVPN ng 0.0.0.0/1 at 128.0.0.0/1 sa halip na palitan ang default route. Magkasama, sinasaklaw ng dalawang iyon ang buong address space, at nilalampasan nila ang 0.0.0.0/0 sa haba lang ng prefix. Kaya ang anumang destinasyon na walang mas tiyak na tugma ay pumapasok sa tunnel.

Kailangan ng endpoint ng eksepsiyon. Nagdadagdag ang OpenVPN ng host route patungo sa address ng server sa pamamagitan ng orihinal na access gateway bago pumasok ang mga half-default, upang makalabas ang mga encapsulated packet. Kapag nawala ang eksepsiyong iyon, o pinanatili ang susunod na hop na wala na, tumutugma ang sariling panlabas na packet ng tunnel sa isang half-default at ipinapadala pabalik sa tunnel. Ang resulta ay isang koneksiyon na namamatay sa susunod na keepalive o handshake, na walang anumang nasa log na mukhang error sa routing.

Kumpirmahin ang hugis ng talahanayan bago hawakan ang anumang iba. ip route show dapat maglista ng dalawang hati at isang host route para sa address ng server; kapag kulang ang host route, may malinaw na simulang punto ang natitirang pagsisiyasat.

Bakit nananalo ang mga half-default nang walang pagbabago sa metriko

Hindi tinatalo ng mas mababang metriko ang mas mahabang prefix. Nanalo ang mga rutang /1 dahil unang itinutugma ng kernel ang pinakatiyak na ruta, kaya ang pagtaas ng metriko sa default route ay walang binabago sa kung saan pupunta ang trapikong patungo sa tunnel. Ang paghabol sa mga metriko ang pinakakaraniwang maling liko sa diagnosis na ito.

Suriin ang pagpili gamit ang ip route get 203.0.113.10, na inilalagay ang tunay na address ng server. Pinapangalanan ng sagot ang interface at susunod na hop na talagang gagamitin ng kernel, na mas nagbibigay-kaalaman kaysa sa pagbasa ng talahanayan at pag-iisip tungkol dito.

Patakbuhin ang command na iyon bago magsimula ang tunnel, habang buhay ito, at pagkatapos ng lease event. Tatlong sagot mula sa isang command, at nagiging nakikita ang punto ng pagkakaiba.

Kumuha ng tatlong snapshot, hindi isa

Kolektahin ang access address, access gateway, destinasyon ng endpoint, piniling ruta at anumang patakaran sa tatlong sandali: pagkatapos ma-configure ang access link, pagkatapos kumonekta ang VPN, at pagkatapos ng lease o carrier event. Ang bawat snapshot ay isang dakot na command, at may kahulugan lamang sila kapag magkasama. Ang isang snapshot pagkatapos ng pagkabigo ay nagtatala ng estado, hindi ng paglipat. Isulat ang mga command sa maliit na script upang ang bawat snapshot ay makuha sa parehong paraan.

Itago ang mga snapshot sa isang file na may mga timestamp, dahil ang kawili-wiling tanong mamaya ay ang pagkakasunod-sunod. Dumating ba ang DHCP event bago o pagkatapos na i-refresh ng OpenVPN ang ruta nito? Ang sagot ang magpapasya kung sino ang dapat mag-ayos. Ang timestamp mula sa maling orasan ay mas masahol pa sa wala, kaya kunin ito mula sa host na may-ari ng routing table.

Kapag ang endpoint ay na-configure bilang pangalan sa halip na address, lutasin din ito sa bawat snapshot. Maaaring ilipat ng pagbabago sa DNS sa access link ang endpoint nang walang ruta na nagalaw.

Magpasya kung aling component ang nagre-refresh ng eksepsiyon

Sa sistemang dhcpcd, tumatakbo ang mga hook mula sa hook directory at mula sa exit hook, at ang manager mode ay naiiba sa saklaw sa per-interface mode. Anuman ang gawin ng hook, dapat itong idempotent, dahil maaaring dumating ang mga renewal nang sabay-sabay.

Ang maaasahang may-ari ay ang integrasyong alam na ang dalawang panig: isang network manager na namamahala sa koneksiyon ng VPN, o isang unit na inayos pagkatapos umangat ang access link. Ang static na rutang idinagdag ng hook ay gumagana hanggang sa susunod na pagbabago ng gateway, pagkatapos ay nabigo sa eksaktong parehong paraan. Kung gagamit ka ng hook, hayaang basahin nito ang kasalukuyang gateway sa runtime sa halip na i-hardcode ang nakita mo ngayon.

Itala ang may-ari sa loob ng configuration. Kailangang malaman ng susunod na magde-debug ng muling pagkonekta na hook, hindi ang VPN, ang may pananagutan sa ruta ng eksepsiyon.

Subukan ang lifecycle, hindi lang ang muling pagkonekta

Pilitin ang renewal gamit ang dhcpcd -n eth0 o sa pamamagitan ng pagpapalaya at muling pagkuha ng lease, pagkatapos ay suriin muli ang ip route get para sa endpoint. Gawin ito nang dalawang beses, dahil nahuhuli ng ikalawang pagtakbo ang mga hook na nagdadagdag ng dobleng ruta. Pagkatapos ay i-reboot, dahil ang pagtitiyaga ay ibang katangian kaysa sa kawastuhan.

Ang tunnel na nakakaligtas sa renewal at reboot ay may may-ari at gumaganang eksepsiyon. Ang nakakaligtas lamang sa manu-manong restart ay wala sa dalawa, at mabibigo ito sa susunod na event na hindi mo maiiskedyul.