Një NIC apo dy? Përcaktimi i strukturës së ndërfaqeve të serverit VPN

Një përshtatës fizik mjafton për shumë serverë VPN, dhe nuk është as një zgjidhje universale. Lidhja e kriptuar vjen në atë përshtatës, procesi VPN e dekripton, dhe më pas trafiku i brendshëm del përmes një ndërfaqeje virtuale përpara se të arrijë një shërbim lokal ose një LAN të rrugëtuar. Nëse kjo funksionon varet nga tri kushte: ku ndodhet destinacioni, a ka LAN-i një rrugë kthimi drejt grupit të klientëve dhe a ju jep një lidhje fizike e përbashkët izolimin që pretendoni. Përgjigjuni këtyre tre dhe numri i përshtatësve rrjedh vetë.

Tri kushtet që e vendosin

Kushti i parë është destinacioni. Një shërbim në vetë hostin VPN arrihet vetëm përmes ndërfaqes së tunelit, ndërsa një host në LAN kërkon përcjellje dhe një rrugë kthimi. Kushti i dytë është ajo rrugë kthimi, sepse pajisja e LAN-it duhet të dijë si të arrijë grupin e klientëve, qoftë me një rrugë, qoftë me përkthim në server.

Kushti i tretë është ndarja. Një përshtatës do të thotë që çdo paketë, e kriptuar ose jo, ndan një lidhje dhe zakonisht një zinxhir politikash, prandaj një pretendim izolimi që varet nga harduer i veçantë nuk plotësohet nga një ndërfaqe e vetme. Ky është një fakt për rrugën, jo për mënyrën se si është konfiguruar sistemi operativ. Mund të filtrash ende trafikun e tunelit, por nuk mund të pretendosh një kufi që nuk e ke.

Asnjë nga të tre nuk ka të bëjë me numrin e porteve në kasë. Kanë të bëjnë me rrugëtimin, pronësinë e adresave dhe sa varet projekti nga ndarja fizike.

Dy përshtatës mbeten një zgjedhje legjitime kur zona fizike, lidhje të veçanta lart, kapaciteti i transmetimit ose një rrugë rikuperimi jashtë brezit i justifikojnë. Këto janë kërkesa konkrete dhe ia vlen të deklarohen përpara se dikush të porosisë harduer.

Kur shërbimi ekzekutohet në hostin VPN

Rasti më i thjeshtë nuk ka nevojë fare për përcjellje. Daemoni i merr paketat e klientit në ndërfaqen e tunelit dhe i dorëzon një socket lokal, dhe përgjigjja kthehet përmes së njëjtës ndërfaqe. Për hostin, adresa e grupit të klientëve është një adresë e vërtetë lokale.

Dy gjëra duhet të jenë ende të sakta: shërbimi duhet të dëgjojë në një adresë që tuneli mund ta arrijë, dhe firewalli i hostit duhet të pranojë trafikun që mbërrin në ndërfaqen e tunelit. Të dyja shihen në komandat më poshtë.

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

Lidhja e një shërbimi vetëm me adresën publike, ose filtrimi i ndërfaqes së tunelit gabimisht, prodhon një lidhje që arrin hostin dhe pastaj vdes. Kjo duket si defekt VPN dhe zakonisht është një vendim për socket ose firewall.

Kur destinacioni ndodhet në LAN

Këtu një strukturë me një përshtatës fiton reputacionin e të qenit e ndërlikuar. Serveri duhet t'i përcjellë paketat e klientit drejt LAN-it, dhe pajisja e LAN-it duhet t'i dërgojë përgjigjet mbrapsht në grupin e klientëve. Ose e mbani atë grup si rrugë në LAN, ose e përktheni adresën burimore në server që përgjigjet të kthehen te vetë serveri.

Të dyja përgjigjet janë legjitime dhe dështojnë ndryshe. Një rrugë kthimi e mban adresën origjinale të klientit të dukshme për destinacionin, gjë që është mirë për regjistrat dhe keq për rregullat e firewallit që supozojnë adresa LAN. Përkthimi e mban LAN-in të thjeshtë dhe e fsheh identitetin e klientit nga destinacioni.

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

Një rrugë asimetrike është simptoma klasike: kërkesa e klientit mbërrin, përgjigjja del përmes një rrugëtuesi tjetër dhe lidhja skadon pa gabim në të dy skajet. Kapeni trafikun në të dyja anët përpara se të nxirrni ndonjë përfundim për tunelin.

Pse një alias nuk krijon një zonë të dytë

Shtimi i një adrese të dytë në të njëjtin përshtatës, ose krijimi i një ndërfaqeje dummy që imiton një port të dytë, ndryshon shumë pak. Paketat dalin ende përmes të njëjtës lidhje fizike, të njëjtit port switch dhe zakonisht të njëjtit zinxhir firewalli, prandaj mes tyre nuk lind një kufi i ri. Është lehtësi konfigurimi, jo segmentim. Trajtimi i tij si kufi zone është mënyra se si një pretendim izolimi mbijeton vetëm në letër.

Një zonë e veçantë kërkon një ndarje reale në rrugë, dhe ky është kushti që plotëson një përshtatës i dytë. Nëse një rregull varet nga fakti që trafiku drejt VPN nuk ndan kurrë një domen transmetimi me trafikun drejt LAN, një kabllo e vetme nuk mund ta japë atë veti, sido që të adresohet hosti.

Kur një produkt dokumenton një topologji me shumë ndërfaqe për një modalitet të caktuar, ndiqni dokumentacionin e atij produkti në vend që të shpikni një zgjidhje anashkaluese. Prodhuesit ndryshojnë edhe topologjitë e mbështetura midis versioneve, çka është një arsye tjetër për të lexuar udhëzuesin aktual dhe jo një pamje ekrani të një magjistari të vjetër.

Kontrolloni strukturën kundrejt trafikut që lejoni

Listoni klasat e trafikut që serveri duhet të mbajë: klient drejt hostit, klient drejt LAN, host drejt LAN dhe lidhja e jashtme e kriptuar. Secila klasë ka një burim, një destinacion dhe një ndërfaqe, dhe struktura duhet t'i plotësojë të katërtat njëkohësisht. Një strukturë që trajton tre prej tyre është zakonisht ajo që gjeneron tiketa.

Më pas konfirmoni ndërfaqet reale dhe kapjen reale, jo diagramin në dokumentin e projektimit. Komandat më poshtë shtypin të dyja pamjet.

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

Nëse kapja e jashtme tregon trafikun e kriptuar dhe kapja e brendshme tregon trafikun e dekriptuar në ndërfaqen e tunelit, ndërsa përshtatësi fizik i mban të dyja, një NIC e bën punën. Nëse kapja e brendshme është bosh, problemi është në tunel ose në rregullat e përcjelljes, jo në numrin e përshtatësve. Vendosni topologjinë nga ato dy kapje dhe tabela e rrugëtimit, dhe ndryshimi i radhës do të ketë me çfarë të krahasohet.