Hayaang Mag-SSH ang Isang OpenVPN Client sa Isa Pa Nang Hindi Binubuksan ang Pool

Kailangang maabot ng isang client ang serbisyong SSH ng isa pang client, at dapat manatiling kasing-hiwalay ngayon ang iba pang bahagi ng pool. Ang mapang-akit na switch ay ang client-to-client, na nagsisindi ng access sa pagitan ng mga kapantay para sa lahat nang sabay at inililipat ang desisyon sa OpenVPN kaysa sa kernel. Ang mas makitid na sagot ay nag-iiwan ng switch na iyon na patay at hinahayaang ang sariling routing at firewall ng server ang magdala ng eksaktong isang daloy.

Mas mahalaga ang mekanismo kaysa sa teksto ng patakaran, dahil inilalagay ng dalawang paraan ang packet sa magkaibang lugar. Ang pag-alam kung alin ang pinili mo ay nagpapaliwanag kapwa sa patakarang tila walang ginagawa at sa kapantay na kumokonekta nang wala ito.

Saan inililipat ng client-to-client ang packet

Kapag naka-on ang client-to-client, ipinapasa ng server ang packet ng kapantay sa loob sa halip na ipadala ito pabalik sa labas sa pamamagitan ng tunnel device, kaya hindi kailanman umabot ang packet sa landas ng pag-forward ng kernel. Ito ay maginhawa at nangangahulugan din na hindi kailanman nakikita ng iyong firewall ang daloy na dapat nitong bantayan. Iwanang patay ang opsyon at iruruta ng server ang packet pabalik sa labas sa parehong interface, na naglalagay nito sa harap ng netfilter. Parehong interface ang pumapasok, parehong lumalabas, at ang FORWARD chain ang may boto.

Ang palitan ay malinaw: nakakakuha ka ng isang punto ng patakaran at ikaw ang umaako sa routing at pag-forward na ginagawa ng shortcut para sa iyo. Maliit ang gawaing iyon para sa isang daloy at lumalaki sa bawat pagbubukod na idinadagdag mo. Bilangin ang mga pagbubukod ngayon, dahil sa hanay ng patakaran nakatira talaga ang patakaran sa pagitan ng mga kapantay.

Ang landas na talagang tinatahak ng packet ng kapantay

Ipagpalagay ang isang serbisyong Linux Community OpenVPN 2.6, pagpoproseso ng TUN sa user space kaysa sa DCO, topolohiyang subnet, tun0, at isang pool ng 10.44.0.0/24 na may client A sa 10.44.0.21 at client B sa 10.44.0.37. Sa topolohiyang subnet, sakop na ng address at netmask na natanggap ng A ang pool, kaya ipinapadala ng A ang packet sa tunnel device nang hindi kailangan ng karagdagang itinulak na ruta. Suriin ang epektibong ruta sa A kaysa magpalagay ng isa.

Sa server dumarating ang packet na naka-address kay B, na hindi lokal na address, kaya ipinapasa ito. Kailangang nakabukas ang pag-forward ng IPv4 para mangyari iyon, at kailangang ipadala ng paghahanap ng ruta ang packet pabalik sa labas sa tun0. Kaya nakikita ng firewall ang isang naipasang daloy na may parehong interface sa magkabilang panig, at iyon ang detalyeng nalalampasan ng karamihan ng hanay ng patakaran. Walang kailangang pagsasalin ng pinagmulan dito, at ang pagpapanatiling buo ng address ni A ang nagpapahintulot kay B na ilapat ang sarili nitong patakarang nakabatay sa pinagmulan.

Dalawang patakaran sa server, sa ayos na ito

Tatlong patakaran ang nagdadala ng buong pahintulot: pag-forward, ang pagbubukod ng pares, at isang default na pagtatapon para sa pares ng tunnel. Pinapangalanan ng patakaran ng pagtanggap ang pares at ang serbisyo, kaya nabubuhay ang pahintulot sa pool na lumalaki. Ilagay ito bago ang anumang pangkalahatang pagtanggi sa trapikong tunnel-sa-tunnel, dahil ang unang tugma ang nananalo:

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROP

Ang mga utos na iyon ay pantulad at kabilang sa mekanismong ginagamit ng iyong host upang itago ang mga patakaran; ang pagsingit sa oras ng pagtakbo ay nawawala sa susunod na pag-boot. Ang patakarang may estado ang nagpapahintulot sa mga sagot ni B at sa TCP handshake na bumalik nang walang pangalawang salamin na pagtanggap.

Suriin ang mga counter pagkatapos kaysa sa listahan ng patakaran, dahil ang patakarang hindi kailanman tumutugma ay kamukha ng gumagana. Kung manatiling zero ang mga counter, hindi tinatahak ng packet ang landas na inaakala mo.

Ano pa ang dapat pahintulutan ng B

Ang B ang nagpapatakbo ng serbisyong SSH, kaya ang B ang nagpapasya kung may nakikinig sa address ng tunnel at kung tinatanggap ng sarili nitong host firewall ang pinagmulan. Ang pahintulot sa network sa server ay hindi pahintulot para sa anumang account sa B, at ang pagpapatunay ng host key at pagpapatunay ng user ay umiiral pa rin gaya ng mula saanman.

Subukan muna ang positibong kaso: isang bagong koneksyong SSH mula A patungo sa address ng tunnel ni B, na tinanggap gamit ang inaasahang host key. Pagkatapos subukan ang ibang kapantay o ibang port at tiyakin na tinatanggihan ito, dahil ang pahintulot na tahimik na nagpapahintulot sa lahat ay hindi makikilala sa gumagana hanggang sa maging mahalaga ito. Kailangan ang dalawang hati ng pagsubok na iyon, at ang pangalawa ang nilalaktawan ng mga tao.

Itala ang mga itinalagang address, ang epektibong ruta sa dalawang client at ang eksaktong patakaran sa server at sa B. Ang matagumpay na ping sa gateway o bukas na port sa server ay hindi nagpapatunay ng anuman sa mga ito, dahil maaaring totoo ang dalawa habang naka-block pa rin ang pag-forward sa pagitan ng mga kapantay. Isulat ang mga numerong iyon habang nakataas ang tunnel, dahil ang address na natatanggap ng client pagkatapos ng muling pagkonekta ay maaaring iba.