Unu NIC aŭ du? Kiel elekti la interfacan aranĝon de VPN-servilo

Unu fizika adaptilo sufiĉas por multaj VPN-serviloj, kaj ĝi ankaŭ ne estas universala dezajno. La ĉifrita konekto alvenas sur tiu adaptilo, la VPN-procezo malĉifras ĝin, kaj la interna trafiko eliras tra virtuala interfaco antaŭ ol atingi lokan servon aŭ enkursigitan LAN. Ĉu tio funkcias dependas de tri kondiĉoj: kie troviĝas la celo, ĉu la LAN havas revenan vojon al la klienta baseno, kaj ĉu unu komuna fizika ligilo donas al vi la izolon, kiun vi asertas. Respondu tiujn tri kaj la nombro da adaptiloj sekvos.

La tri kondiĉoj, kiuj decidas

La unua kondiĉo estas la celo. Servo sur la VPN-gastiganto mem atingeblas nur tra la tunela interfaco, dum gastiganto en la LAN postulas plusendadon kaj revenan vojon. La dua kondiĉo estas tiu reena vojo, ĉar la LAN-aparato devas scii, kiel atingi la klientan basenon, ĉu per enkursigo ĉu per traduko ĉe la servilo.

La tria kondiĉo estas apartigo. Unu adaptilo signifas, ke ĉiu paketo, ĉifrita aŭ ne, dividas ligilon kaj kutime politikan ĉenon, do izola aserto, kiu dependas de aparta aparataro, ne estas plenumita de unu interfaco. Tio estas fakto pri la vojo, ne pri tio, kiel la operaciumo estas agordita. Vi ankoraŭ povas filtri la tunelan trafikon, sed vi ne povas aserti limon, kiun vi ne havas.

Neniu el la tri temas pri la nombro da havenoj sur la ĉefskatolo. Ili temas pri enkursigo, posedo de adresoj kaj kiom la dezajno dependas de fizika apartigo.

Du adaptiloj restas legitima elekto, kiam fizikaj zonoj, apartaj suprenligoj, trairo aŭ eksterbanda reakira vojo pravigas ilin. Tiuj estas konkretaj postuloj, kaj indas deklari ilin antaŭ ol iu mendas aparataron.

Kiam la servo funkcias sur la VPN-gastiganto

La plej simpla kazo bezonas tute neniun plusendadon. La demono ricevas la paketojn de la kliento sur la tunela interfaco kaj transdonas ilin al loka ingo, kaj la respondo revenas tra la sama interfaco. La adreso de la klienta baseno estas reala loka adreso laŭ la vidpunkto de la gastiganto.

Du aferoj tamen devas esti ĝustaj: la servo devas aŭskulti sur adreso, kiun la tunelo povas atingi, kaj la fajroŝirmilo de la gastiganto devas akcepti trafikon alvenantan sur la tunela interfaco. Ambaŭ videblas en la komandoj sube.

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

Ligi servon nur al la publika adreso, aŭ erare filtri la tunelan interfacon, produktas konekton, kiu atingas la gastiganton kaj poste mortas. Tio aspektas kiel VPN-difekto kaj kutime estas decido pri ingo aŭ fajroŝirmilo.

Kiam la celo troviĝas en la LAN

Ĉi tie unu-adaptila dezajno gajnas sian reputacion kiel malfacila. La servilo devas plusendi la paketojn de la kliento al la LAN, kaj la LAN-aparato devas sendi respondojn reen al la klienta baseno. Aŭ vi portas tiun basenon kiel enkursigon en la LAN, aŭ vi tradukas la fontan adreson ĉe la servilo, por ke respondoj revenu al la servilo mem.

Ambaŭ respondoj estas legitimaj kaj ili malsukcesas malsame. Reena enkursigo tenas la originan klientan adreson videbla al la celo, kio bonas por protokoloj kaj malbonas por fajroŝirmilaj reguloj, kiuj supozas LAN-adresojn. Traduko tenas la LAN simpla kaj kaŝas la identecon de la kliento antaŭ la celo.

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

Malsimetria vojo estas la klasika simptomo: la peto de la kliento alvenas, la respondo eliras tra alia enkursigilo, kaj la konekto finiĝas sen eraro ĉe ambaŭ finoj. Kaptu ambaŭflanke antaŭ ol konkludi ion pri la tunelo.

Kial alias ne kreas duan zonon

Aldoni duan adreson al la sama adaptilo, aŭ krei falsan interfacon por imiti duan havenon, ŝanĝas tre malmulte. La paketoj ankoraŭ eliras tra la sama fizika ligilo, la sama ŝaltila haveno kaj kutime la sama fajroŝirmila ĉeno, do ne ekzistas nova limo inter ili. Tio estas agorda oportuneco, ne segmentado. Trakti ĝin kiel zontan limon estas la maniero, kiel izola aserto postvivas nur surpapere.

Aparta zono bezonas veran apartigon en la vojo, kaj tio estas la postulo, kiun plenumas dua adaptilo. Se regulo dependas de tio, ke VPN-direkta trafiko neniam dividu dissendan domajnon kun LAN-direkta trafiko, unu kablo ne povas liveri tiun econ, kiel ajn la gastiganto estas adresita.

Kie produkto dokumentas multinterfacan topologion por specifa reĝimo, sekvu la dokumentaron de tiu produkto anstataŭ elpensi provizoran solvon. Vendistoj ankaŭ ŝanĝas siajn subtenatajn topologiojn inter eldonoj, kio estas plia kialo legi la aktualan gvidilon anstataŭ malnovan ekrankopion de asistanto.

Kontrolu la aranĝon kontraŭ la trafiko, kiun vi permesas

Listigu la trafikklasojn, kiujn la servilo devas porti: kliento al gastiganto, kliento al LAN, gastiganto al LAN, kaj la ĉifrita ekstera konekto. Ĉiu klaso havas fonton, celon kaj interfacon, kaj la aranĝo devas plenumi ĉiujn kvar samtempe. Dezajno, kiu traktas tri el ili, kutime estas tiu, kiu generas biletojn.

Poste konfirmu la efektivajn interfacojn kaj la efektivan kaptaĵon, ne la diagramon en la dezajna dokumento. La komandoj sube presas ambaŭ vidojn.

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

Se la ekstera kaptaĵo montras la ĉifritan trafikon kaj la interna kaptaĵo montras la malĉifritan trafikon sur la tunela interfaco, dum la fizika adaptilo portas ambaŭ, unu NIC faras la laboron. Se la interna kaptaĵo estas malplena, la problemo estas en la tunelo aŭ en la plusendaj reguloj, ne en la nombro da adaptiloj. Decidu la topologion el tiuj du kaptaĵoj kaj la enkursiga tabelo, kaj la sekva ŝanĝo havos laŭ kio mezuriĝi.