Nagsisimula ng VPN client sa SSH? I-pin muna ang sarili mong ruta
Ang client na may buong tunnel ay nagsusulat muli ng talahanayan na nagdadala ng iyong SSH na sagot. I-pin ang isang host route sa lumang gateway, o patakbuhin ang client sa sarili nitong namespace.
Nagli-log in ka sa SSH sa isang build host, sinisimulan doon ang VPN client, at tumitigil sa pagsagot ang session. Walang nag-crash, at walang mukhang mali ang pagkaka-configure sa halatang kahulugan. Naglagay ang client ng default na ruta, kaya lumalabas na ngayon ang mga sagot papunta sa iyong workstation sa tunnel, kung saan hindi naruruta ang address ng iyong workstation. Ang kawili-wiling bahagi ay ang resultang ito ay mahulaan, at ang solusyon ay isang rutang isinusulat bago magsimula ang client. Ipagpalagay natin ang isang server na may isang network card, isang gateway na 192.0.2.254, at isang administrador na kumokonekta mula sa 203.0.113.9.
Itala ang landas bago ka magsimula
ip route show default ay nagpangalan ng kasalukuyang gateway at interface, habang ang ip route get 203.0.113.9 ay nagpapakita kung aling interface at source address ang gagamitin ng kernel para sa iyong session. Itago ang parehong output. Pagkatapos umangat ng tunnel, dapat pa ring ilarawan ng dalawang command na iyon ang pisikal na landas, at kung ang tunnel ang inilalarawan nila, ang session ay nabubuhay na sa hiram na oras.
Ang mahalaga ay ang naitatag nang koneksyon, kaya huwag mag-validate gamit lamang ang bagong pag-log in. Ang bagong session ay maaaring magtagumpay nang sandali sa pamamagitan ng estado na wala na sa luma.
I-pin ang address sa sariling configuration ng client
Ang rutang idinagdag sa kamay ay nawawala sa reboot at nakikipagkarera sa sariling mga update ng talahanayan ng client, kaya ilagay ang exception kung saan pinamamahalaan ang talahanayan. Sa OpenVPN ang keyword na net_gateway ay nireresolba sa gateway na umiral bago ang tunnel, kaya ang route 203.0.113.9 255.255.255.255 net_gateway ay nagpapanatili ng eksaktong isang address sa labas nito. Kailangan ng WireGuard ng ibang paraan dahil ang wg-quick ay mismo ang namamahala ng mga ruta: itakda ang Table = off at idagdag ang exception sa PostUp, kasama ang tugmang PostDown na nag-aalis nito. Ang dalawang anyo ay nagpapahayag ng parehong layunin, at parehong nililimitahan ang exception sa isang address sa halip na pahinain ang tunnel para sa lahat.
Para sa IPv6 ang parehong ideya ay kumukuha ng prefix ng isang host, at ang kaso ng naka-balot na transportasyon ay dapat tandaan: kung ang panlabas na koneksyon ng tunnel mismo ay nasa isang fixed na address, ang address na iyon ay dapat manatili sa labas ng tunnel na dinadala nito, kung hindi ay iruruta ng client ang sariling transportasyon papasok sa sarili nito.
O alisin ang pangunahing talahanayan sa equation
Kapag maraming serbisyo sa host ang dapat mapanatili ang kanilang normal na landas, itigil ang pag-edit ng pangunahing talahanayan at bigyan ang client ng sarili nito. Ang network namespace na may veth pair ay malinis itong gawin: ang default na ruta ng client ay nasa ibang stack at tanging mga prosesong sinimulan sa loob nito ang gumagamit ng tunnel. Naabot ng policy routing ang katulad na lugar para sa isang destinasyon, sa pamamagitan ng pagpapadala ng tugmang trapiko sa isang dedikadong talahanayan na ang default ay nakaturo pa rin sa pisikal na gateway. Alinman sa dalawang paraan ay iniiwan ang pangunahing talahanayan ng host na walang bagong default na ruta, at ang katangiang iyon ang nagpapanatili sa SSH na sumasagot.
Ang dalawa ay mas maraming makinarya kaysa isang host route, at kapwa sulit kapag higit sa isang bagay sa makina ang kailangang makalampas sa tunnel.
Ipagpalagay na maaaring mabigo ang pag-pin
Ang rutang nakatali sa iyong kasalukuyang pampublikong address ay masisira sa sandaling muling italaga ito ng iyong provider. Kailangan noon ng malayong server ng landas na hindi umaasa sa address na iyon: isang console, isang pangalawang interface ng pamamahala, o isang jump host na nananatili sa labas ng tunnel.
Dalawang safeguard ang nagkakahalaga ng sampung minuto. Ang watchdog na humihinto sa client kung walang confirmation login na lumitaw sa loob ng ilang minuto ay ginagawang delay ang lockout, at ang ikalawang SSH session na itinatag sa bukas habang nagbabago ay nagpapatunay na gumagana ang exception habang nakataas ang tunnel. Ang keepalive lamang ay hindi nakakatulong dito, dahil ang landas ay wala na kaysa idle; ginagawa lamang nilang mas madaling mapansin ang kamatayan.
I-verify sa pagkakasunod-sunod na mahalaga
Ikonekta ang tunnel, kumpirmahin na ang ruta patungo sa iyong address ay lumalabas pa rin sa pisikal na gateway, pagkatapos ay magbukas ng bagong session. Kung gumagana ang bagong session at namamatay pa rin ang luma, ang dahilan ay connection tracking o stateful firewall at hindi routing, na ibang solusyon.
Isulat ang naka-pin na address at ang command na nagpatunay nito sa talaan ng pagbabago. Ang susunod na taong magsisimula ng client sa host na iyon ay mangangailangan ng dalawa, at maaaring nagbago na ang address sa oras na iyon.