Ein nettenging eða tvær? Að ákveða uppsetningu tengja á VPN-þjóni

Eitt líkamlegt millistykki er nóg fyrir marga VPN-þjóna, og það er ekki heldur algild hönnun. Dulkóðaða tengingin kemur á það millistykki, VPN-ferlið afkóðar hana, og síðan fer innri umferðin út um sýndartengi áður en hún nær staðbundinni þjónustu eða leiðsendingar-LAN. Hvort það virkar fer eftir þremur skilyrðum: hvar áfangastaðurinn er, hvort LAN hefur afturleið að biðlarasafninu, og hvort ein sameiginleg líkamleg tenging gefi þér þá einangrun sem þú heldur fram. Svaraðu þessum þremur og fjöldi millistykja fylgir.

Þrjú skilyrðin sem ráða því

Fyrsta skilyrðið er áfangastaðurinn. Þjónusta á VPN-hýsilinu sjálfu er aðeins aðgengileg um göngutengið, en hýsil á LAN krefst framsendingar og afturleiðar. Annað skilyrðið er sú afturleið, því LAN-tækið verður að vita hvernig á að ná biðlarasafninu, annaðhvort með leið eða með þýðingu á þjóninum.

Þriðja skilyrðið er aðskilnaður. Eitt millistykki þýðir að hver pakki, dulkóðaður eða ekki, deilir tengingu og venjulega sömu stefnukeðju, svo fullyrðing um einangrun sem byggir á aðskildum vélbúnaði er ekki uppfyllt með einu tengi. Það er staðreynd um leiðina, ekki um hvernig stýrikerfið er stillt. Þú getur samt síað umferð göngunnar, en þú getur ekki haldið fram mörkum sem þú hefur ekki.

Ekkert þessara þriggja snýst um fjölda portanna á hylkinu. Þau snúast um leiðsendingu, eignarhald á heimilisföngum og hversu mikið hönnunin byggir á líkamlegum aðskilnaði.

Tvö millistykki eru áfram lögmætur kostur þegar líkamleg svæði, aðskildar uppstreymistengingar, afköst eða endurheimtarleið utan bands réttlæta þau. Þetta eru áþreifanlegar kröfur, og það er þess virði að orða þær áður en einhver pantar vélbúnað.

Þegar þjónustan keyrir á VPN-hýsilnum

Einfaldasta tilfellið þarf enga framsendingu. Þjónustuforritið tekur við pökkum biðlarans á göngutenginu og afhendir þá staðbundinni sökkul, og svarið fer sama veg til baka. Frá sjónarhóli hýsilsins er heimilisfang biðlarasafnsins raunverulegt staðbundið heimilisfang.

Tvennt verður samt að vera rétt: þjónustan verður að hlusta á heimilisfang sem göngin ná til, og eldveggur hýsilsins verður að samþykkja umferð sem berst á göngutengið. Bæði sjást í skipununum hér að neðan.

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

Að binda þjónustu eingöngu við opinbera heimilisfangið, eða sía göngutengið fyrir mistök, framleiðir tengingu sem nær hýsilnum og deyr svo. Það lítur út eins og VPN-bilun og er yfirleitt ákvörðun um sökkul eða eldvegg.

Þegar áfangastaðurinn er á LAN

Hér fær einmillistykjahönnunin orðspor sitt fyrir að vera flókin. Þjónninn verður að framsenda pökkum biðlarans til LAN, og LAN-tækið verður að senda svör til baka í biðlarasafnið. Annaðhvort berðu safnið sem leið á LAN, eða þýðir upprunalega heimilisfangið á þjóninum svo svörin komi aftur til þjónsins sjálfs.

Bæði svörin eru lögmæt og þau bregðast á ólíkan hátt. Afturleið heldur upprunalegu biðlaraheimilisfanginu sýnilegu fyrir áfangastaðnum, sem er gott fyrir annála og slæmt fyrir eldveggjarreglur sem gera ráð fyrir LAN-heimilisföngum. Þýðing heldur LAN einföldu og felur auðkenni biðlarans frá áfangastaðnum.

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

Ósamhverf leið er klassískt einkenni: beiðni biðlarans berst, svarið fer út um annan beini, og tengingin rennur út á tíma án villu á báðum endum. Gríptu umferð á báðum hliðum áður en þú ályktar nokkuð um göngin.

Hvers vegna alias skapar ekki annað svæði

Að bæta öðru heimilisfangi við sama millistykkið, eða búa til dummy-tengi til að líkja eftir öðru porti, breytir mjög litlu. Pakkarnir fara samt út um sömu líkamlegu tenginguna, sama rofaport og venjulega sömu eldveggjakeðjuna, svo engin ný mörk verða á milli þeirra. Þetta er þægindi í stillingum, ekki sundurhlutun. Að meðhöndla það sem svæðamörk er hvernig fullyrðing um einangrun lifir aðeins á pappír.

Aðskilið svæði þarf raunverulegan aðskilnað á leiðinni, og það er krafan sem annað millistykki uppfyllir. Ef regla byggir á því að umferð til VPN deili aldrei útsendingarléni með umferð til LAN, getur einn kapall ekki veitt þann eiginleika, hvernig sem hýsilnum er beitt.

Þar sem vara skjalfestir fjöltengja-tóppólógíu fyrir tiltekinn ham skaltu fylgja skjölum þeirrar vöru í stað þess að finna upp sniðgöngu. Framleiðendur breyta einnig studdum tóppólógíum milli útgáfa, sem er önnur ástæða til að lesa núverandi leiðarvísi frekar en gamalt skjáskot af leiðsagnarforriti.

Berðu uppsetninguna saman við umferðina sem þú leyfir

Skráðu umferðarflokkana sem þjóninum er ætlað að bera: biðlari til hýsils, biðlari til LAN, hýsill til LAN, og dulkóðaða ytri tengingin. Hver flokkur hefur uppruna, áfangastað og tengi, og uppsetningin verður að uppfylla alla fjóra í einu. Hönnun sem annast þrjá þeirra er venjulega sú sem framleiðir miða.

Staðfestu síðan raunverulegu tengin og raunverulegu grípunina, ekki skýringarmyndina í hönnunarskjölunum. Skipanirnar hér að neðan prenta báðar sýnirnar.

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

Ef ytri grípan sýnir dulkóðuðu umferðina og innri grípan sýnir afkóðuðu umferðina á göngutenginu á meðan líkamlega millistykkið ber báðar, þá er eitt netkort að vinna verkið. Ef innri grípan er tóm er vandamálið í göngunum eða framsendingarreglunum, ekki í fjölda millistykja. Ákveddu tóppólógíuna út frá þessum tveimur grípum og leiðatöflunni, og næsta breyting hefur eitthvað til að mælast við.