Paano nagdadala ang lokal na pagpapasa ng SSH ng isang sesyong TCP OpenVPN

Dito nagpapatong ang tatlong transport, at bawat isa ay may sariling pagbabalangkas. Ang kargang VPN ay naglalakbay sa loob ng isang sesyong TLS, ang sesyong TLS na iyon ay naglalakbay sa loob ng koneksyong TCP patungo sa port ng loopback, at ang mga byte ng koneksyong iyon ay naglalakbay sa loob ng SSH patungo sa host ng relay, na nagbubukas ng tunay na koneksyong TCP patungo sa tagapakinig ng VPN. Walang anuman sa kaayusang ito ang nagbabago sa OpenVPN awtentikahin, at walang anuman dito ang nagpapaging-abot ng tagapakinig ng UDP sa pamamagitan ng TCP. Basahin ang natitira bilang paglalarawan ng landas ng byte, hindi bilang resipi para iwasan ang isang kontrol sa network.

Ano ang talagang inililipat ng lokal na pagpapasa

Nakikinig ang kliyenteng SSH sa isang lokal na port. Kapag kumonekta ang isang lokal na proseso, ipinapakete ng kliyente ang mga byte sa sarili nitong naka-encrypt na channel, at binubuksan ng panig ng server ang isang bagong koneksyong TCP patungo sa destinasyong pinangalanan sa kahilingan ng pagpapasa.

Ang destinasyong iyon ay nireresolba ng relay, hindi ng iyong makina, kaya gumagana pa rin ang isang pangalang umiiral lamang sa loob ng malayong network. Nangangahulugan din ito na dapat maabot ng relay ang tagapakinig ng VPN at may ruta pabalik dito. Ang pangalang nireresolba sa iyong laptop ay walang sinasabi tungkol sa nakikita ng relay.

Ang pagsisimula ng sesyong SSH ay nagpapatunay lamang na ang relay ay maaabot at awtentikado. Hindi nito sinasabi kung buhay ang susunod na tagapakinig, kung tinatanggap ng firewall sa pagitan ng relay at tagapakinig ang koneksyon, o kung tatanggapin ng VPN ang iyong profile.

Itutok ang kliyente sa lokal na tagapakinig

Isang idineklarang halimbawa: naaabot ng relay ang tagapakinig ng TCP sa gw.internal.example:443, at inilalantad ng mataas na lokal na port ang landas na iyon sa makinang ito lamang.

ssh -N -L 127.0.0.1:24011:gw.internal.example:443 [email protected]

Ang manwal ng OpenSSH ay naglalarawan ng lokal na pagpapasa bilang lokal na pagtanggap ng mga koneksyong TCP at pagbubukas ng susunod na koneksyon mula sa malayong panig. Itali ang tagapakinig sa loopback sa halip na sa lahat ng interface, dahil ang pagpapasang maaabot mula sa network ay isang bukas na relay na may pangalan mo. Inilalantad din ng wildcard na pagtali ang port sa anumang iba pang lokal na account sa isang nakabahaging makina.

Pagkatapos ay ilagay ang kliyente ng VPN sa mode na TCP at itutok ito sa 127.0.0.1:24011. Kung gumagamit ng UDP ang profile, hindi makakatulong ang disenyong ito: nagdadala ang pagpapasa ng daloy ng byte, at walang landas ng datagram sa loob nito.

Panatilihing hiwalay ang dalawang awtentikasyon

Awtentikahin ng SSH ang host ng relay. Awtentikahin pa rin ng OpenVPN ang kapares ng VPN, at hindi binabago ng destinasyong loopback ang pangangailangang iyon. Ang pag-off ng mga pagsusuri ng sertipiko dahil nakaturo na ngayon ang socket sa localhost ang pinakamasamang shortcut sa disenyong ito. Ginagawa nitong kaayusan ng tiwala ang kaayusan ng transport, at walang sinuman ang pumayag sa pangalawa.

Panatilihing buo ang angkla ng tiwala ng profile, ang pagsusuri ng papel ng server at ang beripikasyon ng pangalan. Kung inihahambing ng iyong kliyente ang pangalan ng server sa address na tinawagan nito, maaaring kailanganin ng loopback ang tahasang setting ng pangalan sa halip na patay na pagsusuri, at ang dokumentasyon ng profile ang lugar upang kumpirmahin kung aling field ang inihahambing.

Ituring ang relay bilang ikalawang panig sa kuwento ng tiwala: nakikita ng admin nito ang metadata ng koneksyon at maaaring ilipat ang pagpapasa kung babaguhin ang configuration. Kailangan ng kaayusan ang pag-apruba mula sa relay at sa may-ari ng serbisyong VPN, hindi lamang sa nangangailangan nito ngayon.

Huwag magtayo ng loop sa ilalim ng tunnel

Kapag nag-install ang VPN ng mga ruta, ang koneksyong SSH na nagdadala nito ay kailangan pa rin ng landas patungo sa relay na hindi dumadaan sa tunnel. Kung lilipat ang default na ruta sa VPN at maaabot lamang ang relay sa pamamagitan ng parehong tunnel, babagsak ang transport at sasama ang VPN. Mukhang bumagsak na tunnel ang pagkabigo sa halip na pagkakamali sa routing, kaya mali ang diagnosis.

Ang karaniwang pag-aayos ay isang host route patungo sa address ng relay na naka-pin sa pisikal na interface bago umangat ang tunnel, kasama ang pagsusuri na nakakaligtas ang ruta sa muling pagkonekta. Beripikahin ito sa paghahanap ng ruta para sa address ng relay sa halip na ipagpalagay na tama ang pagkakasunod-sunod.

Asahan din na ang stack na ito ay mas mabagal at mas marupok kaysa sa direktang koneksyon, dahil may dalawang nakaayos na transport ngayon at isa pang endpoint na dapat panatilihin. Paraan ito ng pagtawid sa hangganan ng network, hindi teknik sa pagganap.

Isara ang tagapakinig kapag tapos ka na

Ihinto ang sesyong SSH kapag hindi na kailangan ang tunnel, at kumpirmahin na nailabas na ang lokal na port. Ang nakalimutang pagpapasa ay nag-iiwang bukas ng awtentikadong landas sa makinang maaaring nakabahagi.

Suriin din ang mga pinapayagang destinasyon ng pagpapasa ng relay, dahil ginagawang pangkalahatang pivot ng isang permisyong configuration ang anumang komprometidong account. Itala ang port, relay at destinasyon nang magkasama, upang malaman ng susunod na tao kung para saan ang pagpapasa at kung aprubado pa ito.