Laat een OpenVPN-kliënt per SSH by 'n ander uitkom sonder om die poel oop te maak

Een kliënt moet by 'n ander kliënt se SSH-diens uitkom, en die res van die poel moet so geïsoleer bly soos vandag. Die verleidelike skakelaar is client-to-client, wat eweknie-toegang vir almal tegelyk aanskakel en die besluit aan OpenVPN oorhandig in plaas van aan die kernel. 'n Nouer antwoord hou daardie skakelaar af en laat die bediener se eie routing en firewall presies een vloei dra.

Die meganisme maak meer saak as die reëlteks, want die twee benaderings plaas die pakket op verskillende plekke. As jy weet watter een jy gekies het, verduidelik dit beide die reël wat niks lyk te doen en die eweknie wat daarsonder konnekteer.

Waar client-to-client die pakket skuif

Met client-to-client aangeskakel, stuur die bediener 'n eweknie-pakket intern oor in plaas daarvan om dit weer deur die tonneltoestel uit te stuur, so die pakket bereik nooit die kernel se deurstuurpad nie. Dit is gerieflik en dit beteken ook jou firewall sien nooit die vloei wat hy veronderstel is om te polisieer nie. Laat die opsie af en die bediener stuur die pakket weer deur dieselfde koppelvlak uit, wat dit voor netfilter plaas. Dieselfde koppelvlak in, dieselfde koppelvlak uit, en die FORWARD-ketting kry die stem.

Die ruil is duidelik: jy kry 'n beleidspunt by en jy neem die routing- en deurstuurwerk oor wat die kortpad vir jou gedoen het. Daardie werk is klein vir een vloei en groei met elke uitsondering wat jy byvoeg. Tel die uitsonderings nou, want die reëlversameling is waar eweknie-beleid werklik woon.

Die pad wat 'n eweknie-pakket werklik volg

Neem aan 'n Linux Community OpenVPN 2.6-diens, gebruikerspasie-TUN-verwerking eerder as DCO, subnet-topologie, tun0, en 'n poel van 10.44.0.0/24 met kliënt A by 10.44.0.21 en kliënt B by 10.44.0.37. Met subnet-topologie dek die adres en netmasker wat A ontvang het reeds die poel, so A stuur die pakket na die tonneltoestel sonder 'n ekstra gestuurde roete. Kontroleer die effektiewe roete op A eerder as om een aan te neem.

Op die bediener kom die pakket aan geadresseer aan B, wat nie 'n plaaslike adres is nie, so dit word deurgestuur. IPv4-deursturing moet aangeskakel wees vir dit om hoegenaamd te gebeur, en die roete-opsoek moet die pakket weer deur tun0 uitstuur. Die firewall sien dus 'n deurgestuurde vloei met dieselfde koppelvlak aan beide kante, en dit is die besonderheid wat die meeste reëlstelle mis. Niks kort hier bronvertaling nie, en om A se adres ongeskonde te hou, is wat B in staat stel om sy eie brongebaseerde reël toe te pas.

Twee reëls op die bediener, in hierdie volgorde

Drie reëls dra die hele toestemming: deursturing, die paar-uitsondering, en 'n verstek-verwerp vir die tonnelpaar. Die aanvaardingsreël noem die paar en die diens, so die toestemming oorleef 'n poel wat groei. Plaas dit voor enige allesomvattende weiering vir tonnel-tot-tonnel-verkeer, want die eerste passing wen:

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

Daardie opdragte is illustratief en hoort in watter meganisme jou gasheer ook al gebruik om reëls te bewaar; 'n runtime-invoeging verdwyn by die volgende opstart. Die toestandsvolle reël is wat B se antwoorde en die TCP-handdruk laat terugkeer sonder 'n tweede, spieël-aanvaarding.

Kontroleer die tellers daarna eerder as die reëllisting, want 'n reël wat nooit gepas word nie lyk identies aan een wat werk. As die tellers op nul bly, neem die pakket nie die pad wat jy dink dit neem nie.

Wat B steeds moet toelaat

B hardloop die SSH-diens, so B besluit of enigiets op die tonneladres luister en of sy eie gasheer-firewall die bron aanvaar. 'n Netwerktoelating op die bediener is nie toestemming vir enige rekening op B nie, en gasheer-sleutelverifikasie en gebruikersverifikasie geld steeds soos van enige ander plek.

Toets eers die positiewe geval: 'n vars SSH-verbinding van A na B se tonneladres, aanvaar met die verwagte gasheer-sleutel. Toets dan 'n ander eweknie of 'n ander poort en bevestig dat dit geweier word, want 'n toestemming wat stilweg alles toelaat, is tot dit saak maak nie te onderskei van een wat werk nie. Beide helftes van daardie toets is nodig, en die tweede is die een wat mense oorslaan.

Teken die toegewysde adresse, die effektiewe roetes op beide kliënte en die presiese reëls op die bediener en op B aan. 'n Suksesvolle ping na die poort of 'n oop poort op die bediener bewys niks hiervan nie, want albei kan waar wees terwyl eweknie-deursturing steeds geblokkeer is. Skryf daardie nommers neer terwyl die tonnel op is, want die adres wat 'n kliënt ná 'n herverbinding kry, kan 'n ander een wees.