Kas kahe OpenVPN-serveri kliendid pääsevad üksteiseni?

Teise OpenVPN serveri püstitamine annab teise koha, kuhu kliendid saavad ühenduda, ja mitte midagi enamat. See ei pane neid kliente esimese serveri võrku, ja valik nimega client-to-client muudab ainult edastust ühe serveriprotsessi sees. Kaks kogumit saavad üheks võrguks, kui marsruudite nende vahel teadlikult, igale suunale oma vastutajaga. Kõik allpool eeldab kasutajaruumi TUN-režiimi, kus see sisemine edastus on välja lülitatud, nii et otsuse teeb kernel.

Müüt: üks kontode nimekiri, üks võrk

Autentimine ja kättesaadavus aetakse segi, sest mõlemad elavad serveri konfiguratsioonis. Kasutaja, kes saab sisse logida kummassegi lüüsi, näeb väljastpoolt välja nagu ühe kahe uksega süsteemi kasutaja. Sees jagab iga server aadresse oma kogumist ja paigaldab marsruute ainult nendele klientidele, kelle ühenduse ta lõpetab. Nii küsib lüüsil A olev klient, kes saadab paketi lüüsil B olevale kliendile, sihtkohta, millest tema oma server pole kunagi kuulnud. Pakett läheb A vaikemarsruudile, lahkub tunnelist ja jõuab tulemüüri, kellelt pole kunagi palutud seda lubada.

Teise serveri lisamine ei lisa seega koondumist, avastamist ega ühist ringhäälingu domeeni. See lisab marsruuditud võrgu, mis vajab plaani, ja plaan algab adresseerimisest.

Andke kummalegi lüüsile oma kogum ja transiitaadress

Kaks vahemikku, mis ei tohi millegi muuga kattuda, pluss väike transiitlüli hostide vahel – see on kogu aadressiplaan. Hoidke transiiti privaatses segmendis, mida kontrollite, ja kirjutage numbrid üles enne, kui ükski server rendi väljastab.

Vastustage kiusatusele anda mõlemale serverile sama kogum, et profiilid jääksid samaks. Kerneli marsruut ei saa öelda, kumb kahest hostist parasjagu omab suvalist aadressi ühises vahemikus, nii et marsruutimistabel osutaks ühele lüüsile ja klient võib olla ühendatud teisega. Liidesenimed on kohalikud tavad, mitte ühine olek. Mõlemad hostid nimetavad siin tunneliseadet tun0 ja transiitlüli transit0, mis on korras, sest ükski pakett neid nimesid ei kanna.

Paigaldage marsruut mõlemale poole

Kummagi lüüsi jaoks on vaja marsruuti teise kogumi juurde üle transiitaadressi, ja edastus peab olema sees, et kumbki saaks hüppena toimida. Kinnitage esmalt praegune tabel, seejärel lisage kirje ja tehke see püsivaks hosti võrguhalduri kaudu, mitte ühenduse taastamise konksu kaudu.

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

Peegeldage seda teisel hostil kogumitega vahetatult. Sama marsruudi korduv lisamine kõrvalisest skriptist on viis, kuidas host saab mitu koopiat ja järgmisel tabeli lugemisel salapärase muudatuse. Kui transiitlüli on ise tunnel, osutab marsruut selle tunneli topoloogiale ja hüpe peab selle taasühenduse üle elama. Transiitaadress, mis kaob kolmekümneks sekundiks, viib endaga kaasa kogumitevahelise tee, mis on disainiomadus, mida tasub deklareerida, mitte avastada.

Lükake kliendi marsruut ilma omandit teeseldes

Klientidel on vaja marsruuti kaugkogumi juurde, muidu saadab nende oma operatsioonisüsteem paketi oma vaikelüüsile ja tunnel ei näe seda kunagi. Serveri konfiguratsioon on loomulik koht selle kohaletoimetamiseks.

push "route 10.64.20.0 255.255.255.0"

Pange peegelrida teise serveri konfiguratsiooni, seejärel ühendage testklient uuesti ja lugege selle tabelit. Klient, kes lükatud marsruute eirab, vajab oma kinnitatud konfiguratsiooni, ja marsruut, mis kunagi kohale ei jõua, ei ole juurdepääsukontroll. Ärge andke kliendile iroute teise lüüsi kogu kogumi jaoks. See direktiiv on mõeldud ühe ühendatud kliendi taga oleva alavõrgu jaoks, ja selle kasutamine puuduva lüüsidevahelise marsruudi katmiseks tekitab serveri, mis usub end omavat aadresse, kuhu ta ei ulatu.

Tõestage üks päring ja keelake teine

Valige tegelik toiming, näiteks HTTPS kliendilt aadressil 10.64.10.21 teenusele aadressil 10.64.20.37, ja lubage täpselt seda mõlemal hostil. Iga tulemüür võtab päringu vastu oma sissetuleval küljel ja jälgitud vastuse tagastusküljel; sihtkoha enda teenusepoliitika peab selle ikkagi vastu võtma.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Vastastikuste marsruutide korral on lähte-NAT tarbetu ja siin aktiivselt kahjulik: lähte tõlkimine varjab, milline klient päringu tegi, ja nurjab lähtepõhise poliitika sihtkoha poolel. Kontrollige, et olemasolev maskeerimisreegel interneti väljapääsu jaoks ei püüaks ka seda teed. Seejärel testige keeldumist. Teenus, mis peaks jääma kogumisse B kohalikuks, peab jääma kogumist A kättesaamatuks, ja ka sama lüüsi kliendipaare tuleb testida, sest just muudetud edastuspoliitika kehtib ka nende kohta.

Veel üks parandus vaimsesse mudelisse: transiitlüli kannab dekrüpteeritud sisemisi pakette, seega on see usalduspiir, mitte privaatne garantii. Kui see läbib võrku, mida te ei kontrolli, kaitske seda hüpet kinnitatud krüpteeritud tunneliga ja marsruutige selle tegeliku topoloogia kaudu. Otsast-otsani TLS autendib rakendust endiselt ise, mistõttu sisemine teenus peaks seda edasi kasutama.