Vienas tinklo adapteris ar du? VPN serverio sąsajų išdėstymo sprendimas

Daugeliui VPN serverių pakanka vieno fizinio adapterio, ir tai nėra universali konstrukcija. Šifruotas ryšys ateina į tą adapterį, VPN procesas jį iššifruoja, o tada vidinis srautas išeina per virtualią sąsają, kol pasiekia vietinę paslaugą arba maršrutizuotą LAN. Ar tai veiks, priklauso nuo trijų sąlygų: kur yra paskirties vieta, ar LAN turi grįžimo kelią į klientų telkinį ir ar viena bendra fizinė jungtis suteikia izoliaciją, kurią skelbiate. Atsakykite į šiuos tris ir adapterių skaičius išplauks pats.

Trys sąlygos, kurios tai lemia

Pirmoji sąlyga – paskirties vieta. Paslauga pačiame VPN hoste pasiekiama tik per tunelio sąsają, o LAN esantis hostas reikalauja persiuntimo ir grįžimo kelio. Antroji sąlyga – tas grįžimo kelias, nes LAN įrenginys turi žinoti, kaip pasiekti klientų telkinį, arba maršrutu, arba vertimu serveryje.

Trečioji sąlyga – atskyrimas. Vienas adapteris reiškia, kad kiekvienas paketas, šifruotas ar ne, dalijasi viena jungtimi ir dažniausiai viena taisyklių grandine, todėl izoliacijos teiginys, pagrįstas atskira technine įranga, nėra patenkinamas viena sąsaja. Tai faktas apie kelią, o ne apie operacinės sistemos konfigūraciją. Tunelio srautą vis tiek galite filtruoti, bet negalite teigti turintys ribos, kurios neturite.

Nė viena iš trijų nėra apie prievadų skaičių korpuse. Jos apie maršrutizavimą, adresų nuosavybę ir tai, kiek projektas priklauso nuo fizinio atskyrimo.

Du adapteriai lieka teisėtas pasirinkimas, kai fizinės zonos, atskiros uplink jungtys, pralaidumas arba atsarginis atkūrimo kelias tai pateisina. Tai konkretūs reikalavimai, ir verta juos suformuluoti prieš kam nors užsakant techninę įrangą.

Kai paslauga veikia VPN hoste

Paprasčiausias atvejis visai nereikalauja persiuntimo. Daemonas priima kliento paketus tunelio sąsajoje ir perduoda juos vietiniam lizdui, o atsakymas grįžta ta pačia sąsaja. Hostui klientų telkinio adresas yra tikras vietinis adresas.

Du dalykai vis tiek turi būti teisingi: paslauga turi klausytis adreso, kurį tunelis gali pasiekti, o hosto ugniasienė turi priimti srautą, ateinantį tunelio sąsaja. Abu matomi toliau pateiktose komandose.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

Paslaugos priskyrimas tik viešajam adresui arba atsitiktinis tunelio sąsajos filtravimas sukuria ryšį, kuris pasiekia hostą ir tada miršta. Tai atrodo kaip VPN gedimas ir dažniausiai yra lizdo ar ugniasienės sprendimas.

Kai paskirties vieta yra LAN

Čia vieno adapterio konstrukcija užsitarnauja sudėtingos reputaciją. Serveris turi persiųsti kliento paketus link LAN, o LAN įrenginys turi siųsti atsakymus atgal į klientų telkinį. Arba tą telkinį nešate kaip maršrutą LAN, arba verčiate šaltinio adresą serveryje, kad atsakymai grįžtų į patį serverį.

Abu atsakymai teisėti ir jie žlunga skirtingai. Grįžimo maršrutas palieka pradinį kliento adresą matomą paskirties vietai, kas gerai žurnalams ir blogai ugniasienės taisyklėms, kurios numato LAN adresus. Vertimas palieka LAN paprastą ir paslepia kliento tapatybę nuo paskirties vietos.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

Asimetrinis kelias yra klasikinis simptomas: kliento užklausa ateina, atsakymas išeina per kitą maršrutizatorių, o ryšys baigiasi laiku be klaidos abiejuose galuose. Fiksuokite abiejose pusėse, prieš darydami kokią nors išvadą apie tunelį.

Kodėl alias nesukuria antros zonos

Antro adreso pridėjimas tam pačiam adapteriui arba dummy sąsajos, imituojančios antrą prievadą, sukūrimas keičia labai nedaug. Paketai vis tiek išeina per tą pačią fizinę jungtį, tą patį komutatoriaus prievadą ir dažniausiai tą pačią ugniasienės grandinę, todėl tarp jų neatsiranda naujos ribos. Tai konfigūracijos patogumas, o ne segmentavimas. Vertinimas to kaip zonos ribos yra būdas, kuriuo izoliacijos teiginys išlieka tik popieriuje.

Atskirai zonai reikia tikro atskyrimo kelyje, ir šį reikalavimą tenkina antrasis adapteris. Jei taisyklė priklauso nuo to, kad srautas link VPN niekada nedalytų transliacijos domeno su srautu link LAN, vienas kabelis negali suteikti šios savybės, kad ir kaip hostas būtų adresuojamas.

Kai produktas dokumentuoja kelių sąsajų topologiją konkrečiam režimui, vadovaukitės to produkto dokumentacija, o ne kurkite apeidinėjimą. Gamintojai taip pat keičia palaikomas topologijas tarp leidimų, ir tai dar viena priežastis skaityti dabartinį vadovą, o ne seno vedlio ekrano kopiją.

Patikrinkite išdėstymą pagal srautą, kurį leidžiate

Išvardykite srauto klases, kurias serveris turi pernešti: klientas į hostą, klientas į LAN, hostas į LAN ir šifruotas išorinis ryšys. Kiekviena klasė turi šaltinį, paskirties vietą ir sąsają, o išdėstymas turi tenkinti visus keturis iš karto. Konstrukcija, tvarkanti tris iš jų, dažniausiai ir generuoja bilietus.

Tada patvirtinkite faktines sąsajas ir faktinį fiksavimą, o ne schemą projektavimo dokumente. Toliau pateiktos komandos išspausdina abu vaizdus.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

Jei išorinis fiksavimas rodo šifruotą srautą, o vidinis fiksavimas rodo iššifruotą srautą tunelio sąsajoje, kol fizinis adapteris perneša abu, darbą atlieka vienas NIC. Jei vidinis fiksavimas tuščias, problema yra tunelyje arba persiuntimo taisyklėse, o ne adapterių skaičiuje. Nustatykite topologiją pagal tuos du fiksavimus ir maršrutų lentelę, ir kitas pakeitimas turės su kuo lygintis.