Zergatik ez diren Access Server bezeroak LANetik irisgarriak

Ordenagailu eramangarria konektatzen da, tunela martxan dago, eta barne zerbitzu baterako eskaerak konexioan zintzilik geratzen dira. Zerbitzuan bertan eskaera 10.90.0.25 bezalako helbide batetik iristen da, erantzuna lehenespenezko atebiderantz irteten da, eta ezer ez da itzultzen, atebide horrek ez baitaki non dagoen 10.90.0.25. Beste muturretik akats berak konektatutako bezeroari ping egin ezin dion barne ostalari baten itxura du. Biak objektu bakar bat falta dira: VPN bezeroen poolerako itzulera-bidea, sare pribatuak soilik gehi dezakeena.

Irakurri zerbitzuak ikusten duen jatorrizko helbidea

Eremu bakar horrek gainerako guztia erabakitzen du. Barne zerbitzuak poolaren helbidea ikusten badu, Access Serverrek bideratu egiten du bezeroen trafikoa ezkutatu beharrean, eta erantzun bakoitza poolera bideratu behar da. Horren ordez zerbitzariaren beraren helbide pribatua ikusten badu, zerbitzariak masquerade egiten du eta itzulera-bidea dagoeneko funtzionatzen du, baina zerbitzuaren erregistroetan eta sarbide-arauetan bezero bakoitzeko identitatea galtzearen truke.

Konparatu bi muturrak ezer aldatu aurretik. Zerbitzarian, zerrendatu tunelaren interfazeak eta haien helbideak; bezeroan, egiaztatu helbide horietatik zein duen benetan; barne ostalarian, begiratu konexio bizia.

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

Azken komandoa da kasu haudian huts egiten duena: edo tunelaren aurrizkia irisgaitza dela jakinarazten du, edo, okerrago, zure lehenespenezko atebidea itzultzen du, eta horrela amaitzen dute erantzunek interneten.

Ez suposatu pool bakarra. Zerbitzari batek barruti dinamikoa eta erabiltzaile bakoitzeko mapatze estatikoak izan ditzake, eta helbide estatikoa aurrizki dinamikotik erabat kanpo egon daiteke. Gogoratzen duzun barrutia soilik bideratzen baduzu, helbide finkoak dituzten erabiltzaileak hondatuta jarraitzen dute eta beste guztiek arazoa konponduta dagoela jakinarazten dute.

Gehitu bidea erantzuna erabakitzen den lekuan

Bidea barne zerbitzuak dagoeneko erabiltzen duen atebidearena da, ez zerbitzuarena, baldin eta hark bere trafikoa bideratzen ez badu. Zuzendu Access Serverren helbide pribatu irisgarrira, bezeroak duen tunelaren helbidetik desberdina den balioa.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

Hodei-sare batean baieztapen bera bide-taularen sarrera bihurtzen da, zeinaren helburua zerbitzaria exekutatzen duen instantzia edo sare-interfazea den, eta interfaze horretan jatorriaren eta helmugaren egiaztapena desgaituta dago. Ohartu sarrera horrek zer egiten ez duen: bide bat ez da sarbide-emate bat, beraz segurtasun-taldeek, sareko ACLek eta ostalariaren suebakiak trafikoa baimendu behar dute oraindik.

Egin ezazu iraunkor, eta mantendu poolen tamainak zintzo. Alboko ez diren bi poolek bi bide behar dituzte, eta konfiguratutako aurrizkitik haratago hazten den pool batek isilpean erantzunek norabiderik ez duten bezeroak sortzen ditu. Poolen barrutiak kontrolatzen badituzu, aukeratu behin bideratu eta bakean utzi dezakezun laburpen bat.

Birbidaltzeak eta iragazkiek bidearekin bat etorri behar dute

Bideratzea bidearen erdia baino ez da. Zerbitzariak tuneletik eta interfaze pribatutik birbidaltzeko baimena izan behar du, eta Linuxen horrek net.ipv4.ip_forward esan nahi du gehi interfaze-parea uzten duen birbidaltze-katea, eta host gogortu batean normalean norabide bakoitzerako arau esplizitu bat.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

Egoerazko iragazkiak jendea bide okerretik eramaten duen sintoma bat azaltzen du. Ezarritako fluxu baten barruko erantzunak ez du sarrerako arau berririk behar, beraz SYN-ACKaren ondoren zintzilik geratzen den konexioa ez da falta den accept arau batek blokeatzen; baztertu edo gaizki bideratzen ari da. Mantendu bereizketa hori, bideratze-aldaketa suebaki-aldaketatik bereizten baitu.

Itzulera-bide asimetrikoek arazo beraren bertsio isilagoa dira. Poolera bi bide iristen badira eta erantzunak eskaera iritsi zen interfazeaz bestelako batetik irteten dena hartzen badu, alderantzizko bidearen iragazketa zorrotzak baztertu egiten du eta fluxua bezero batzuentzat soilik huts egiten du.

Bideratua edo maskaratua: aukeratu nahita

Bideratutako moduak bezeroaren poolaren helbidea gordetzen du zerbitzuan, eta horrek bezero bakoitzeko erregistroa eta politika ahalbidetzen ditu, eta trukean bezeroari erantzun behar dion barne sare bakoitzak poolaren bidea behar du. Maskaratutako moduak baldintza hori kentzen du erantzunak zerbitzarira itzultzen direlako, baina zerbitzuak ezin du jada bezero bat bestetik bereizi eta ezin du ezer hasi bezero zehatz baten aldera.

Portaera hori zerbitzari bizian aldatzeak uneko saioak botatzen ditu, beraz probatu lehenengo bezero batekin eta fluxu batekin. Aldaketa erantzun zuzena bada, zerbitzariko konfigurazio-erabakia da, ez da saihestu beharreko zerbait gero beharrezkoak ez diren bideak gehituta.

Bezeroaren atzeko azpisarea zeregin bereizia da

Ordenagailu eramangarriaren beraren LANean dagoen gailua iristea ez da ordenagailu eramangarriaren tunelaren helbidea iristea bezalakoa. Bezeroak azpisare-atelari gisa jardutea eskatzen du: bezeroaren aldean deklaratutako sarea, bezeroaren sistema eragilean gaitutako birbidaltzea, eta LAN horretan bezeroaren alderako bidea. Ordenagailu eramangarriaren etxeko barrutiarentzako sare pribatuko bide bat gehitzeak ez du hori egiten, eta gatazkak sortzen ditu bi erabiltzailek etxeko barruti bera dutenean.

Norabidea ere politika kontua da. Bezeroari barne zerbitzu baterako konexioa irekitzeko baimenak ez dio automatikoki barne ostalariari bezero horretarako konexioa irekitzen uzten. Egiaztatu zerbitzariaren sarbide-politika eta bezeroaren ostalariaren suebakia, bidea hondatuta dagoela ondorioztatu aurretik.

Egiaztatu fluxu batekin eta harrapaketa batekin

Frogatu bidea konexio bakar batekin, irisgarritasun-proba orokor baten ordez. Beha ezazu fluxu bera bi muturretan: zerbitzura iristen den eskaera eta hura uzten duen erantzuna.

tcpdump -ni any host 10.90.0.25 and port 443

Konponketa aurretik harrapaketak erantzuna bideratuko ez duen atebiderantz irteten erakusten du. Konponketaren ondoren erantzuna zerbitzariaren aldera irteten da eta fluxua osatzen da. Gero egiaztatu atebideak bigarren bezero-helbide baterako erabiliko lukeen bidea, estali ez duzun pool bat orain ager dadin, astebete barru ez.

Bukatu hau ixten duten lau egiaztapenekin: zerbitzuko jatorrizko helbidea zure asmoa zen moduarekin bat dator, atebideak pool erabilgarri bakoitzera bidea du, birbidaltzeak eta iragazkiek bi norabideak baimentzen dituzte, eta fluxu erreal batek hasieratik amaierara egiten du. Access Serverren bideratzearen ohiko galderak dokumentuak printzipio bera adierazten du erabileran dagoen bertsiorako, eta haren konfigurazio-interfaze onartuak gida zaharragoetatik desberdindu daitezke.