Sama serveri IP, kaks teed: OpenVPN-i välise voo märgistamine

Tavaline tsükli kaitse on host-marsruut: saatke liiklus VPN-serveri avalikku aadressi uplinki pidi välja, et krüpteeritud sessioon ei satuks kunagi omaenda tunnelisse. See toimib täpselt kuni hetkeni, mil soovite tunnelist läbi jõuda ka samas serveris asuva veebiteenuseni, sest erand on seotud sihtkohaga ja sihtkoht on sama. Väljapääs on lõpetada sihtkoha järgi klassifitseerimine ja hakata klassifitseerima selle järgi, milline pesa paketi saatis.

Alustage kahest voost, mida soovite eraldada

Üks voog on krüpteeritud OpenVPN transport ise, mis peab väljuma uplinki pidi, muidu kannaks tunnel omaenda välist ühendust. Teine on tavaline HTTPS-päring samale avalikule aadressile, mille soovite tunnelisse, et see jõuaks teenuseni tunneliallikast. Sama sihtkoht, paljudel juhtudel sama pordi number, erinev nõutav tee.

Selles ülevaates eeldage klienti aadressil 10.90.0.10 üle tun1, serveri avalikku aadressi 198.51.100.25 ja puutumata põhitabelit, mille vaikemarsruut osutab tavapärasele uplinkile. Serveripool peab samuti veebiteenuse vastu võtma sisemisel teel ja liikluse tagasi tunneliallikale saatma; paketi saatmine avalikule aadressile ei tühista serveri kuulajat ega tulemüüri poliitikat.

Enne millegi muutmist kirjutage üles hosti praegused reeglid ja valige väärtused, mida keegi teine ei kasuta: märgis, tabelinumber ja kolm reegli prioriteeti. Hoidke alles tee masinasse, mis ei käi läbi selle ühenduse, sest viga siin võtab ära teie enda kaugjuurdepääsu, mitte ainult ei riku brauseri kaarti.

Märgistage pesa, mis ümbrikku kannab

Kliendi konfiguratsioon saab märgise oma krüpteeritud väljuvatele pakettidele ja lõpetab ise marsruutide paigaldamise, nii et asenduspoliitika on ainus, mis teid määrab:

mark 42
route-noexec
disable-dco

Kümnendsüsteemi 42 on kuueteistkümnendsüsteemi 0x2a ja just kuueteistkümnendkuju vastavad marsruutimisreeglid. Link-options viide kirjeldab mark-i kui midagi, mis kehtib Linuxis krüpteeritud väljuvatele pakettidele, mis on täpselt see pesa, mille teed tuleb juhtida. Andmekanali mahalaadimise väljalülitamine hoiab selle näite kasutajaruumi teel, kus märgise käitumine on kirjeldatu.

route-noexec surub maha OpenVPN-i automaatse marsruutide lisamise ja eemaldamise. Nende asemele ei paigalda see midagi, seega sellest hetkest peab marsruutide omanik hoidma iga marsruuti, mida tunnel vajab. Kui privaatne sihtkoht kaob pärast muudatust, on see puuduv asenduspoliitika, mitte märgise viga.

Ärge hoidke põhitabelis host-marsruuti aadressile 198.51.100.25, kui seda teete. Selline marsruut toob uuesti sisse täpselt selle erandi, mida disain püüab kitsendada, ja võidab HTTPS-voo jaoks enne, kui küsitakse ükskõik millist allpool olevat poliitikat.

Saatke kõik muu tunnelitabelisse

Kui tunneli liides on olemas ja hoiab oma aadressi, näeb poliitika välja nii:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

Esimene reegel hoiab hosti konkreetsed marsruudid nähtavana, sealhulgas iga heakskiidetud kohaliku võrgu, tehes samal ajal põhitabeli vaikemarsruudi selle otsingu jaoks nähtamatuks. See erinevus loeb: vaikimisi marsruudi mahasurumine ei ole sama mis tabeli eiramine, ja kohalikud erandid, mida veel vajate, jäävad ellu just tänu sellele. Lugege neid erandeid ükshaaval, selle asemel et eeldada, et tulemus on universaalne hädaseiskamisnupp.

Märgistamata liiklus langeb seejärel tunnelitabelisse, võtab tunneliallika ja väljub VPN-i kaudu. Märgistatud liiklus ebaõnnestub fwmark-testis kahel järgmisel reeglil ja jätkub tavalisse põhiotsingusse nimekirjas allpool, kus uplinki vaikemarsruut veel asub. Lõplik unreachable-reegel on see, mis takistab märgistamata voolul tunnelimarsruudi puudumisel vaikselt uplinkile tagasi langeda. Selektor on märgis algusest lõpuni ja sihtkoha aadress ei lähe kunagi otsusesse.

Hoidke see kaitse ühenduste vahel paigal ja paigaldage see koos ülejäänud poliitikaga, mitte käsitsi. Reegel, mis kaob koos liidesega, ei ole poliitika, vaid juhus. Poliitika kustutamine tunneli kukkumisel muudab rikkerežiimi „blokeeritud“-ist „lekkis“-eks ja aegunud tunnelimarsruut, mis hiljem lõpeb, on palju kergemini seletatav probleem kui vale liidese kaudu väljunud liiklus.

Las tagasitee näeb sama märgist

Väljuvad märgised on ainult pool mehhanismist ja see on osa, mille enamik reproduktsioone välja jätab. Vastused krüpteeritud sessioonile saabuvad uplinki pidi ja alluvad tagasitee valideerimisele, mis küsib, kas allikas marsruuditaks tagasi sama teed pidi. Ilma abita rakendab see otsing teie märgistamata tunnelipoliitikat ja järeldab, et pakett on valel liidesel.

Parandus kuulub tulemüüri omanikule: salvestage märgis väljuvale ühendusele, taastage see sobivatel sissetulevatel pakettidel ja lubage allika valideeritud märgise töötlemine asjakohase tee jaoks. See, et OpenVPN seab pesa märgise, ei tee ühtegi neist kolmest asjast, ja retsept, mis loetleb ainult kliendi valikud, on puudulik. Küsige seda integreerimist kirjalikult, sest see on disaini kõige vähem nähtav osa ja kõige kergemini kaotsi minev ümberehitusel.

Ka lõtv tagasitee kontroll ei ole asendus. Lõtv režiim vajab ikkagi mingit marsruuti allika jaoks ja teie lisatud unreachable-kaitse eemaldab märgistamata otsingute jaoks ühe meelega. Laske ühenduse märgise integreerimine lõpule viia ja üle vaadata, enne kui sellele disainile loote, ning käsitlege hosti filtreid eraldi küsimusena: märgis on marsruutimissignaal, mitte luba. Kui integreerimine puudub, on sümptomiks sessioon, mis luuakse ja seejärel vaikib niipea, kui vastused hakkavad saabuma.

Tõestage seda kahe marsruudiotsinguga

Võrrelge, mida kernel kahe konteksti jaoks otsustab, ja lugege välju dev ja src, mitte väljumisolekut:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

Esimene otsing peaks lahenema tun1-le tunneliallikaga ja teine uplinkile. Need on sünteetilised otsingud, seega tõestavad need poliitikat, mitte töötavat protsessi: kinnitage eraldi töötava kliendi tegelik transporditee ja tehke seejärel tõeline HTTPS-päring, kus sertifikaadi kontroll on sisse lülitatud.

Kirjutage üles, mida disain ei kata, enne kui kuulutate selle valmis. DNS, IPv6 ja reeglite elutsükkel vajavad igaüks oma otsust ning see on IPv4 marsruutimise näide, mitte täielik privaatsuse konfiguratsioon. Selle väärtus on selektor: ümbrik saab uplinki erandi ja tavaline teenus samal aadressil ei pea seda pärima.