Viena NIC vai divas? VPN servera saskarņu izvietojuma noteikšana

Daudziem VPN serveriem pietiek ar vienu fizisku adapteri, un tas arī nav universāls risinājums. Šifrētais savienojums ienāk pa šo adapteri, VPN process to atšifrē, un pēc tam iekšējā trafika iziet caur virtuālu saskarni, pirms tā sasniedz vietēju pakalpojumu vai maršrutētu LAN. Vai tas darbosies, ir atkarīgs no trim nosacījumiem: kur atrodas mērķis, vai LAN ir atgriešanās ceļš uz klientu kopu un vai viens koplietots fiziskais savienojums dod jums to izolāciju, uz kuru jūs pretendējat. Atbildiet uz šiem trim, un adapteru skaits izrietēs pats.

Trīs nosacījumi, kas to izšķir

Pirmais nosacījums ir mērķis. Pakalpojums pašā VPN resursdatorā ir sasniedzams tikai caur tuneļa saskarni, bet resursdators LAN tīklā prasa pāradresāciju un atgriešanās ceļu. Otrais nosacījums ir šis atgriešanās ceļš, jo LAN ierīcei jāzina, kā sasniegt klientu kopu, vai nu ar maršrutu, vai ar tulkošanu serverī.

Trešais nosacījums ir atdalīšana. Viens adapteris nozīmē, ka katra pakete, šifrēta vai ne, dala vienu savienojumu un parasti vienu politikas ķēdi, tāpēc izolācijas apgalvojumu, kas balstās uz atsevišķu aparatūru, viena saskarne neizpilda. Tas ir fakts par ceļu, nevis par to, kā konfigurēta operētājsistēma. Jūs joprojām varat filtrēt tuneļa trafiku, bet nevarat apgalvot robežu, kuras jums nav.

Neviens no trim nav par portu skaitu korpusā. Tie ir par maršrutēšanu, adrešu piederību un to, cik ļoti projekts ir atkarīgs no fiziskas atdalīšanas.

Divi adapteri joprojām ir likumīga izvēle, ja fiziskas zonas, atsevišķi augšupejas kanāli, caurlaidspēja vai ārpusjoslas atkopšanas ceļš to attaisno. Tie ir konkrēti nosacījumi, un tos ir vērts formulēt, pirms kāds pasūta aparatūru.

Kad pakalpojums darbojas VPN resursdatorā

Vienkāršākajā gadījumā pāradresācija nav vajadzīga vispār. Dēmons saņem klienta paketes tuneļa saskarnē un nodod tās vietējai kontaktligzdai, un atbilde atgriežas pa to pašu saskarni. Resursdatoram klientu kopas adrese ir īsta vietējā adrese.

Divi lietas tomēr ir jāsakārto: pakalpojumam jāklausās adresē, kuru tunelis var sasniegt, un resursdatora ugunsmūrim jāpieņem trafika, kas ienāk tuneļa saskarnē. Abi ir redzami zemāk esošajās komandās.

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

Pakalpojuma piesaiste tikai publiskajai adresei vai nejauša tuneļa saskarnes filtrēšana rada savienojumu, kas sasniedz resursdatoru un tad nomirst. Tas izskatās pēc VPN kļūmes un parasti ir kontaktligzdas vai ugunsmūra lēmums.

Kad mērķis atrodas LAN tīklā

Šeit viena adaptera projekts iegūst reputāciju kā grūti pārvaldāms. Serverim ir jāpāradresē klienta paketes uz LAN, un LAN ierīcei ir jāpārsūta atbildes atpakaļ klientu kopā. Vai nu jūs nesat šo kopu kā maršrutu LAN tīklā, vai arī tulkojat avota adresi serverī, lai atbildes atgrieztos pie paša servera.

Abas atbildes ir likumīgas, un tās neizdodas atšķirīgi. Atgriešanās maršruts saglabā oriģinālo klienta adresi redzamu mērķim, kas ir labi žurnāliem un slikti ugunsmūra noteikumiem, kas pieņem LAN adreses. Tulkošana saglabā LAN vienkāršu un slēpj klienta identitāti no mērķa.

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

Asimetrisks ceļš ir klasiskais simptoms: klienta pieprasījums ienāk, atbilde iziet caur citu maršrutētāju, un savienojums beidzas ar taimautu bez kļūdas abos galos. Uzņemiet trafiku abās pusēs, pirms izdarāt jebkādu secinājumu par tuneli.

Kāpēc aizstājvārds neveido otru zonu

Otras adreses pievienošana tam pašam adapterim vai dummy saskarnes izveide, kas imitē otru portu, maina ļoti maz. Paketes joprojām iziet caur to pašu fizisko savienojumu, to pašu komutatora portu un parasti to pašu ugunsmūra ķēdi, tāpēc starp tām neveidojas jauna robeža. Tas ir konfigurācijas ērtība, nevis segmentācija. Uzskatīt to par zonas robežu ir veids, kā izolācijas apgalvojums izdzīvo tikai uz papīra.

Atsevišķai zonai nepieciešama reāla atdalīšana ceļā, un šo prasību izpilda otrs adapters. Ja noteikums ir atkarīgs no tā, ka trafiks uz VPN nekad nedala apraides domēnu ar trafiku uz LAN, viens kabelis nevar nodrošināt šo īpašību, lai kā arī resursdators būtu adresēts.

Kur produkts dokumentē vairāku saskarņu topoloģiju konkrētam režīmam, sekojiet šī produkta dokumentācijai, nevis izgudrojiet apvedceļu. Ražotāji arī maina atbalstītās topoloģijas starp laidieniem, kas ir vēl viens iemesls lasīt pašreizējo rokasgrāmatu, nevis veca vedņa ekrānuzņēmumu.

Pārbaudiet izvietojumu pret trafiku, ko pieļaujat

Uzskaitiet trafika klases, kas serverim jāpārvadā: klients uz resursdatoru, klients uz LAN, resursdators uz LAN un šifrētais ārējais savienojums. Katrai klasei ir avots, mērķis un saskarne, un izvietojumam jāapmierina visi četri vienlaikus. Projekts, kas apstrādā trīs no tiem, parasti ir tas, kas rada pieteikumus.

Pēc tam apstipriniet faktiskās saskarnes un faktisko uztveršanu, nevis diagrammu projektēšanas dokumentā. Zemāk esošās komandas izdrukā abus skatus.

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

Ja ārējā uztveršana rāda šifrēto trafiku un iekšējā uztveršana rāda atšifrēto trafiku tuneļa saskarnē, kamēr fiziskais adapters pārvadā abus, darbu veic viena NIC. Ja iekšējā uztveršana ir tukša, problēma ir tunelī vai pāradresācijas noteikumos, nevis adapteru skaitā. Nosakiet topoloģiju pēc šīm divām uztveršanām un maršrutēšanas tabulas, un nākamajai izmaiņai būs ar ko salīdzināt.