Panatilihin ang lokal na SSH kapag gumagamit ang host ng papalabas na VPN

Isang maliit na Linux server ang gumagamit ng papalabas na VPN para sa application na hinohost nito, at nais pa rin ng administrator na maabot ito sa pamamagitan ng SSH mula sa katabing mesa. Makatwirang pangangailangan ito, at karaniwang hindi ito nangangailangan ng port forwarding, address ng provider o butas sa tunnel. Ang kailangan nito ay isang landas ng pamamahala na sadyang dinisenyo sa halip na minana mula sa ginawa ng VPN client sa routing table.

Ipinapalagay ng mga hakbang sa ibaba na ang administrator ay nasa parehong LAN.Ang pamamahala mula sa malayo ay ibang problema na may ibang sagot.

Ibigkis ang SSH sa address na ginagamit ng mga administrator

Magsimula sa listener.ss -ltnp | grep :22 ipinapakita kung ano ang nakakabit sa sshd, at ang listener sa 0.0.0.0 ay tumatanggap ng koneksyon mula sa bawat interface, kasama ang tunnel. Ang pagkakabit sa address ng LAN ay mas makitid at ginagawang nakikita ang layunin:ListenAddress 192.168.10.20 sa sshd_config, sinusundan ng pagsubok sa configuration at reload. Ang typo sa address na iyon ay mas nakikita kaysa wildcard, dahil tumatanggi ang sshd na magsimula kapag wala ang address.

Panatilihin ang pagsusuri ng key ng host at ang pagpapatunay ng bawat user nang eksakto kung ano sila. „Lokal na network lang ito“ ay hindi paraan ng pagpapatunay, at ang channel ng pamamahala na lumalampas sa pagpapatunay ng key dahil maikli ang ruta ay channel na naghihintay ng pang-aabuso. Ang reserbasyon ng DHCP o static na address ay ginagawang mahulaan ang target nang hindi ito ginagawang pampublikong pagkakakilanlan ng server.

Panatilihin ang rutang LAN sa labas ng tunnel

Ang host na may address sa 192.168.10.0/24 ay may konektadong ruta para sa prefix na iyon, at ang mas partikular na ruta ay nananalo sa default ng VPN sa parehong table. Ito ang dahilan kung bakit kadalasang nagpapatuloy ang lokal na SSH nang mag-isa kapag tumaas ang tunnel. I-verify ito sa halip na ipagpalagay:ip route get 192.168.10.50 pinangalanan ang interface at source address na gagamitin ng kernel, at ang sagot ay dapat na aparato ng LAN, hindi ang tunnel. Ulitin ang pagsusuri mula sa makina ng administrator, dahil ang sarili nitong table ang nagpapasya kung darating ang mga packet. Dalawang host sa parehong kawad ay maaaring hindi magkasundo kung aling direksyon ang maaabot.

Nababasag ang palagay sa dalawang lugar. Ang patakaran ng routing na batay sa policy ay maaaring magpadala ng trapiko sa isang table na ang default ay tumuturo sa tunnel bago tiningnan ang pangunahing table. Ang VPN client na may lock-down o kill switch feature ay maaari ring harangan ang trapikong hindi pumapasok sa tunnel, anuman ang sinasabi ng routing table.

Ang mga routed na management VLAN ang isa pang kaso. Kung ang administrator ay nakaupo sa 192.168.50.0/24 sa likod ng lokal na router, kailangan ng server ng tahasang ruta para sa prefix na iyon sa pamamagitan ng 192.168.10.1, at dapat na malampasan ng rutang iyon ang muling pagkonekta. Panatilihing partikular ang pagbubukod para sa prefix ng pamamahala; ang malawak na pagbubukod para sa mga pribadong saklaw ay sumisira sa layunin ng tunnel.

Gawing kasingkitid ng patakaran ang pagbubukod sa firewall

Kung may firewall ang host, payagan ang SSH mula sa pinagmulan ng pamamahala lamang, at sa interface ng LAN lamang. Ang patakarang nagpapahintulot sa port 22 mula sa kahit saan ay mas malawak kaysa pangangailangan at mas mahirap ipagtanggol sa isang review. Sa host na nftables, ang patakaran ay nasa input chain na tugma ang interface at pinagmulan; sa host na iptables, ang katumbas ay isang pares ng pagtutugma sa -i at -s. Magkomento sa patakaran kasama ang grupong administrator na pinaglilingkuran nito, upang hindi kailangang manghula ng susunod na audit kung bakit bukas ang port 22.

Suriin din ang sariling filter ng VPN client. May mga client na naglalagay ng patakarang nagtatapon ng lokal na trapiko ayon sa disenyo, at ang tamang patakaran ng firewall sa ibabaw ng pagtatapon sa antas ng client ay walang binabago. Basahin ang configuration ng client bago baguhin ang firewall ng host, dahil dalawang filter na magkakasunod ay gumagawa ng pagkabigo na hindi kamukha ng alinman sa kanila.

Subukan ang dalawang estado

Patakbuhin ang pagsubok nang dalawang beses: isang beses na nakakonekta ang tunnel at isang beses na naka-disconnect. Sa bawat estado, kumpirmahin ang listener, ang ruta at isang tunay na pag-log in sa SSH mula sa makina ng administrator. Ang landas na gumagana lamang habang nakataas ang tunnel ay hindi landas ng lokal na pamamahala; ito ay pagkakataon.

Pagkatapos, i-restart ang tunnel habang bukas ang isang sesyon ng SSH. Ang sesyong nakakaligtas ay nagpapatunay na matatag ang routing; ang sesyong bumabagsak ay nagsasabi sa iyo na muling sinusulat ng client ang mga ruta o filter kapag muling kumonekta, na dapat malaman bago ang isang insidente at hindi habang nangyayari ito.

Itala ang source address kung saan ka nagsubok, dahil ang patakarang isinulat para sa 192.168.10.50 ay tahimik na nabibigo kapag lumipat ang laptop ng administrator sa ibang subnet.

Isulat ang landas ng pagbawi sa runbook

Magpasya ngayon kung ano ang mangyayari kung masisira ng papalabas na VPN ang lokal na landas. Ang pag-access sa console, pangalawang address ng pamamahala o dokumentadong pamamaraan para sa paghinto ng client ay pawang lehitimong sagot, at ang alinman sa mga ito ay mas mabuti kaysa matuklasan ang problema sa sandaling kailangan mong mag-log in. Kung malayo ang server, wala ang lokal na landas, at ang tamang disenyo ay hiwalay na aprubadong ruta ng malayuang pag-access o bastion sa halip na nakalantad na pampublikong port.

Panatilihing hiwalay ang dalawang tungkulin sa dokumentasyon: lokal na SSH para sa administrator na malapit, at ang papalabas na tunnel para sa trapiko ng application. Kapag nakasulat na ang mga tungkuling iyon, ang pagbabago sa hinaharap sa alinman sa kanila ay may malinaw na lugar na susuriin, at hindi na kailangang muling tuklasin ng susunod na tao kung bakit sumasagot pa rin sa address ng LAN nito ang isang server na may VPN.