Tā pati servera IP, divi ceļi: OpenVPN ārējās plūsmas marķēšana

Parastā cilpas aizsardzība ir uzņēmēja maršruts: sūtiet trafiku uz VPN servera publisko adresi pa uplink, lai šifrētā sesija nekad neiekļūtu savā tunelī. Tas darbojas tieši līdz brīdim, kad vēlaties caur tuneli sasniegt arī tīmekļa pakalpojumu tajā pašā serverī, jo izņēmums ir piesaistīts galamērķim, un galamērķis ir identisks. Izeja ir pārstāt klasificēt pēc galamērķa un sākt klasificēt pēc tā, kura ligzda nosūtīja paketi.

Sāciet ar divām plūsmām, kuras vēlaties atdalīt

Viena plūsma ir pats šifrētais OpenVPN transports, kam jāiziet pa uplink, citādi tunelis nestu savu ārējo savienojumu. Otra ir parasts HTTPS pieprasījums uz to pašu publisko adresi, ko vēlaties tuneļa iekšienē, lai tas nonāktu pie pakalpojuma no tuneļa avota. Tas pats galamērķis, daudzos gadījumos tas pats porta numurs, cits nepieciešamais ceļš.

Šajā apskatā pieņemsim klientu 10.90.0.10 ar tun1, servera publisko adresi 198.51.100.25 un neskartu galveno tabulu, kuras noklusējuma maršruts norāda uz parasto uplink. Servera pusei arī jāpieņem tīmekļa pakalpojums iekšējā ceļā un jāsūta trafiks atpakaļ uz tuneļa avotu; paketes sūtīšana uz publisku adresi neatceļ servera klausītāju vai ugunsmūra politiku.

Pirms kaut ko maināt, pierakstiet pašreizējos uzņēmēja noteikumus un izvēlieties vērtības, ko neviens cits neizmanto: atzīmi, tabulas numuru un trīs noteikumu prioritātes. Saglabājiet ceļu atpakaļ uz mašīnu, kas neiet caur šo savienojumu, jo kļūda šeit atņem jūsu pašu attālināto piekļuvi, nevis vienkārši salauž pārlūka cilni.

Marķējiet ligzdu, kas nes apvalku

Klienta konfigurācija iegūst atzīmi savām šifrētajām izejošajām paketēm un pārstāj pati instalēt maršrutus, lai aizvietošanas politika būtu vienīgais, kas nosaka ceļus:

mark 42
route-noexec
disable-dco

Decimālais 42 ir heksadecimālais 0x2a, un tieši heksadecimālo formu saskaņos maršrutēšanas noteikumi. Atsauce par link-options apraksta mark kā tādu, kas attiecas uz šifrētām izejošajām paketēm Linux, tas ir tieši tā ligzda, kuras ceļš jākontrolē. Datu kanāla izkraušanas izslēgšana notur šo piemēru lietotāja telpas ceļā, kur atzīmes uzvedība ir aprakstītā.

route-noexec nomāc automātisko OpenVPN maršrutu pievienošanu un noņemšanu. To vietā tas neko neinstalē, tāpēc no šī brīža maršrutu īpašniekam jāuztur katrs tunelim nepieciešamais maršruts. Ja pēc izmaiņām privāts galamērķis pazūd, tā ir trūkstošā aizvietošanas politika, nevis atzīmes defekts.

Neturiet galvenajā tabulā uzņēmēja maršrutu uz 198.51.100.25, kamēr to darāt. Šāds maršruts no jauna ievieš tieši to izņēmumu, ko dizains cenšas sašaurināt, un uzvarēs HTTPS plūsmai, pirms tiek jautāts kāds no zemāk minētajiem politikas noteikumiem.

Sūtiet visu pārējo uz tuneļa tabulu

Kad tuneļa saskarne pastāv un tur savu adresi, politika izskatās šādi:

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

Pirmais noteikums notur uzņēmēja konkrētos maršrutus redzamus, tostarp jebkuru apstiprināto vietējo tīklu, vienlaikus padarot galvenās tabulas noklusējuma maršrutu šai meklēšanai neredzamu. Šī atšķirība ir svarīga: noklusējuma nomākšana nav tas pats, kas tabulas ignorēšana, un vietējie izņēmumi, kas jums joprojām vajadzīgi, izdzīvo tieši tāpēc. Lasiet šos izņēmumus pa vienam, nevis pieņemiet, ka rezultāts ir universāls avārijas slēdzis.

Nemarķētais trafiks pēc tam nonāk tuneļa tabulā, paņem tuneļa avotu un iziet caur VPN. Marķētais trafiks neiztur fwmark testu nākamajos divos noteikumos un turpinās uz parasto galveno meklēšanu tālāk sarakstā, kur joprojām atrodas uplink noklusējums. Noslēdzošais unreachable noteikums ir tas, kas neļauj nemarķētai plūsmai klusi atkrist uz uplink, kad trūkst tuneļa maršruta. Selektors ir atzīme no sākuma līdz beigām, un galamērķa adrese nekad neiekļūst lēmumā.

Turiet šo aizsardzību vietā starp atkārtotiem savienojumiem un instalējiet to kopā ar pārējo politiku, nevis ar roku. Noteikums, kas pazūd kopā ar saskarni, nav politika, tas ir nejaušība. Politikas dzēšana, kad tunelis nokrīt, maina atteices režīmu no „bloķēts“ uz „noplūdis“, un novecojis tuneļa maršruts, kas vēlāk beidzas, ir daudz vieglāk izskaidrojama problēma nekā trafiks, kas izgāja pa nepareizo saskarni.

Lai atgriešanās ceļš redz to pašu atzīmi

Izejošās atzīmes ir tikai puse no mehānisma, un šī ir daļa, ko lielākā daļa reprodukciju izlaiž. Atbildes uz šifrēto sesiju ienāk pa uplink un ir pakļautas atgriešanās ceļa validācijai, kas jautā, vai avots tiktu maršrutēts atpakaļ pa to pašu ceļu. Bez palīdzības šī meklēšana piemēro jūsu nemarķēto tuneļa politiku un secina, ka pakete atrodas nepareizajā saskarnē.

Labojums pieder ugunsmūra īpašniekam: saglabājiet atzīmi izejošajā savienojumā, atjaunojiet to atbilstošajās ienākošajās paketēs un ieslēdziet avota validētu atzīmju apstrādi attiecīgajam ceļam. Tas, ka OpenVPN iestata ligzdas atzīmi, neveic nevienu no šiem trim, un recepte, kas uzskaita tikai klienta opcijas, ir nepilnīga. Pieprasiet šo integrāciju rakstiski, jo tā ir vismazāk redzamā dizaina daļa un visvieglāk pazaudējamā pārbūvē.

Arī vaļīga atgriešanās ceļa pārbaude nav aizvietotājs. Vaļīgajā režīmā joprojām ir vajadzīgs kāds maršruts avotam, un jūsu pievienotā unreachable aizsardzība apzināti noņem vienu nemarķētajām meklēšanām. Pabeidziet un pārskatiet savienojuma atzīmes integrāciju, pirms paļaujaties uz šo dizainu, un uzskatiet uzņēmēja filtrus par atsevišķu jautājumu: atzīme ir maršrutēšanas signāls, nevis atļauja. Ja integrācijas nav, simptoms ir sesija, kas izveidojas un pēc tam apklust, tiklīdz sāk pienākt atbildes.

Pierādiet to ar divām maršruta meklēšanām

Salīdziniet, ko kodols nolemj abiem kontekstiem, un lasiet laukus dev un src, nevis iziešanas statusu:

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

Pirmajai meklēšanai jāatrisinās uz tun1 ar tuneļa avotu, bet otrajai uz uplink. Tās ir sintētiskas meklēšanas, tāpēc tās pierāda politiku, nevis darbojošos procesu: atsevišķi apstipriniet darbojošā klienta faktisko transporta ceļu un pēc tam veiciet īstu HTTPS pieprasījumu ar ieslēgtu sertifikāta pārbaudi.

Pierakstiet, ko dizains neaptver, pirms pasludināt to pabeigtu. DNS, IPv6 un noteikumu dzīves cikls katrs prasa savu lēmumu, un šis ir IPv4 maršrutēšanas piemērs, nevis pilnīga privātuma konfigurācija. Tā vērtība ir selektors: apvalks iegūst uplink izņēmumu, un parastam pakalpojumam tajā pašā adresē tas nav jāmanto.