Ien klant moat by de SSH-tsjinst fan in oare klant komme, en de rest fan 'e pool moat sa isolearre bliuwe as no. De ferliedlike skeakel is client-to-client, dy't tagong tusken pearen foar allegear tagelyk oansette en de beslissing oan OpenVPN jout ynstee fan oan de kernel. In smeller antwurd hâldt dy skeakel út en lit de routing en firewall fan 'e server sels krekt ien stream drage.

It meganisme jildt mear as de tekst fan 'e regel, want de twa oanpakken sette it pakket op ferskillende plakken. Witte hokker't jo keazen hawwe, ferklearret sawol de regel dy't neat liket te dwaan as de peer dy't der sûnder ferbynt.

Wêr't client-to-client it pakket ferpleatst

Mei client-to-client oanset, jout de server in peer-pakket yntern troch ynstee fan it wer troch it tunnelapparaat út te stjoeren, sadat it pakket nea op it trochjaanpaad fan 'e kernel komt. Dat is handich en it betsjut ek dat jo firewall de stream nea sjocht dy't er beweitsje moatte soe. Lit de opsje út en de server rûtet it pakket wer troch deselde interface nei bûten, wat it foar netfilter pleatst. Deselde interface yn, deselde interface út, en de FORWARD-ketting krijt it wurd.

De ruil is dúdlik: jo winne in beliedspunt en jo nimme it routing- en trochjaanwurk oer dat de koarte wei foar jo die. Dat wurk is lyts foar ien stream en groeit mei elke útsûndering dy't jo tafoegje. Tel de útsûnderings no, want de regelset is wêr't it belied tusken pearen wier wennet.

It paad dat in peer-pakket wier nimt

Tink oan in Linux Community OpenVPN 2.6-tsjinst, brûkersromte-TUN-ferwurking ynstee fan DCO, subnet-topology, tun0, en in pool fan 10.44.0.0/24 mei klant A op 10.44.0.21 en klant B op 10.44.0.37. By subnet-topology dekke it adres en it netmasker dat A krige de pool al, dus A stjoert it pakket nei it tunnelapparaat sûnder in ekstra triuwde rûte. Kontrolearje de effektive rûte op A ynstee fan ien oan te nimmen.

Op 'e server komt it pakket oan adressearre oan B, dat gjin lokaal adres is, dus it wurdt trochjûn. IPv4 trochjaan moat oanset wêze om dat ea te litten barre, en de rûtesyktocht moat it pakket wer troch tun0 stjoere. De firewall sjocht dêrom in trochjûne stream mei deselde interface oan beide kanten, en dat is it detail dat de measte regelsets misse. Hjir is gjin boarne-oersetting nedich, en it yntakt hâlden fan A syn adres is wat B tastean lit syn eigen boarneynstelde regel te brûken.

Twa regels op 'e server, yn dizze folchoarder

Trije regels drage de hiele tastimming: trochjaan, de pear-útsûndering, en in standert drip foar it tunnelpear. De akseptregel neamt it pear en de tsjinst, dus de tastimming oerlibbet in pool dy't groeit. Pleats it foar elke algemiene wegering fan tunnel-nei-tunnel-ferkear, want de earste oerienkomst wint:

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

Dy opdrachten binne yllustratyf en hearre by hokker meganisme jo host ek brûkt om regels te bewarjen; in ynfoeging by runtime ferdwynt by de folgjende opstart. De stateful regel is wat B syn antwurden en de TCP-hânskieding weromkomme lit sûnder in twadde, spegele akseptaasje.

Kontrolearje de tellers dêrnei ynstee fan 'e regellist, want in regel dy't nea oerienkomt liket itselde as ien dy't wurket. As de tellers op nul bliuwe, nimt it pakket net it paad dat jo tinke.

Wat B noch tastean moat

B draait de SSH-tsjinst, dus B beslút oft der eat op it tunneladres harket en oft syn eigen host-firewall de boarne akseptearret. In netwurktastimming op 'e server is gjin tastimming foar in akkount op B, en hostkaai-ferifikaasje en brûkersautentikaasje jilde noch likegoed as fan oeral oars.

Testearje earst it positive gefal: in nije SSH-ferbining fan A nei B syn tunneladres, akseptearre mei de ferwachte hostkaai. Testearje dêrnei in oare peer of in oare poarte en befêstigje dat it wegere wurdt, want in tastimming dy't stil alles tastiet is net te ûnderskieden fan ien dy't wurket oant it derop oankomt. Beide helten fan dy test binne nedich, en de twadde is dejinge dy't minsken oerslaan.

Skriuw de tawiisde adressen, de effektive rûtes op beide klanten en de krekte regels op 'e server en op B op. In suksesfolle ping nei de gateway of in iepen poarte op 'e server bewiist hjir neat fan, want beide kinne wier wêze wylst trochjaan tusken pearen noch blokkearre is. Skriuw dy nûmers op wylst de tunnel omheech is, want it adres dat in klant nei opnij ferbinen krijt kin in oar wêze.

Relatearre artikelen