VPN bezeroa LAN zerbitzarian: zergatik irteten diren erantzunak bide okerretik

Sintomek forma bakarra jarraitzen dute: ostalari bat funtzionatzen du, gero VPN batera konektatzen da bezero gisa, eta orain LAN bezeroek hura iristen dute bere erantzunak desagertzen diren bitartean. Ostalarian egindako harrapaketa batek erakusten du erantzunak tunel gailutik irteten direla LAN interfazearen ordez. Tunelak ez du ezer hautsi, eta konponbidea bide bat da, ez berriz konektatzea. Egin beheko lau egiaztapenak hurrenez hurren eta gelditu lehenengo huts egiten duenean.

Erantzuna pakete berria da, ez alderantzizko bidea

Lagungarria da erantzun bat eskaera batek hartu zuen bidetik itzultzen dela pentsatzeari uztea. Bideratzea pakete bakoitzeko eta norabide bakoitzeko erabakitzen da, bidaltzen duen ostalarian. Tunelaren barruan 10.64.0.23 helbidetik iritsi zen eskaerak ez du itzulera-biderik sortzen; ostalariak erantzuten duenean, erantzun hori pakete berri gisa alderatzen da taularekin eta irabazten duen bidetik irteten da.

Horregatik, LAN bat ere zerbitzatzen duen makinan tunel osoko bezero batek hain hutsegite nahasia sortzen du. Bezeroak bide lehenetsia instalatzen du, edo bezero batzuek nahiago dituzten bi erdi-bide lehenetsiak, eta LAN bezero bati emandako erantzuna tunelarekin bat dator orain. Hornitzailearenera joaten da, eta hark ez du arrazoirik birbidaltzeko, eta LAN bezeroak denbora-muga ikusten du ostalaria martxan eta tokian bertan erantzuten ari den arren. Harrapaketak begi-bistakoa egiten du, eta bideratze-taulak azaltzen du.

Eduki bi azpisare buruan gainerakoa irakurtzen duzun bitartean. Bat VPN helbide-hobia da, urruneko bezeroak handik datoz, adibide honetan 10.64.0.0/24. Bestea lanean jarraitu behar duen LANa da, 172.16.24.0/24, bere bideratzailea 172.16.24.1 helbidean duela. Akatsa da bien arteko trafikoa bide lehenetsiak erabakitzen duela.

Frogatu harrapaketarekin eta kontsultarekin

Ezer aldatu aurretik, egiaztatu zein gailuk erabiliko duen erantzuna. Kontsulta bat harrapaketa bat baino azkarragoa da eta paketea eraikitzean kernelak erantzungo duen galdera berari erantzuten dio.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Irakurri erantzuna bi zatitan. dev tun0 aipatzen badu, ostalariak erantzuna kapsulatuko du eta hornitzaileari emango dio, eta LAN bezeroak ez du inoiz ikusiko. dev eth0 aipatzen badu baina bezeroak oraindik denbora-muga jasaten badu, bidea jada zuzena da eta paketea geroago baztertzen da, eta hori beste arazo bat da, beste konponbide batekin.

Urrats bereko harrapaketak ping-ek ezin duen zalantza argitzen du. LAN bezeroarengana iristen den oihartzun-erantzun batek frogatzen du bideren bat funtzionatzen duela, ez zein interfazek eraman zuen, beraz egin harrapaketa ostalarian bertan eta behatu markoak nondik irteten diren. Azpisare bereko inprimagailuak erantzuten jarraitzen du, haren bide zuzena tunelaren bide lehenetsia baino zehatzagoa baita. Birbidalitako ataka batek beste edozein fluxuk bezala huts egiten du, taulak interfazea aukeratzen baitu, ez konexioak.

Instalatu tunela gainditzen duen biderik estuena

Aurrizkiaren luzerak erabakitzen du, ez metrikak, beraz bezero-hobiaren bidea LAN bideratzailearen bidez VPN bezeroak instalatzen duen edozein bide lehenetsiren gainetik dago. Ez da metrika-kirurgiarik behar, eta bide lehenetsia bezeroak jarri zuen tokian bertan egon daiteke.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Erabili replace, ez add, berriz konektatzen den bezeroak bere sarrera instalatu duela izango baitu eta bigarren add batek huts egiten du bide existitzen deneko errore bategaz, baimen-arazo baten antzera irakurtzen dena. Windows ostalari batean baliokidea route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p da, non -p sarrera berrabiarazien artean mantentzen duen, bezeroak taula berreraiki baitezake tunela berriz igotzen denean. Egungo Windows ostalari batean onartutako baliokidea New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore da, eta route komando zaharra forma zaharkitu gisa gordetzen da.

Xehetasun batek erabakitzen du hau zuzena den edo soilik sinesgarria: hurrengo jauziak bezeroetarako itzulera-bidea benetan duen bideratzailea izan behar du. Bidea berak tunelaren bidez iristen den helbide batera zuzentzeak begizta bat sortzen du, eta hori tartekako galera gisa agertzen da, hutsegite garbi gisa beharrean. Egiaztatu hurrengo jauzia LAN azpisarean dagoela lerroa onartu aurretik.

Mantendu erantzuna berriz konektatu ondoren

Eskuz gehitutako bideak, ondoenean, hurrengo berriz konektatzera arte irauten du. Bezero-hobia dinamikoa bada, ainguratu zerbitzariaren konfigurazioan, bideratu duzun aurrizkia bezeroek jasotzen duten aurrizkia izan dadin; bestela, sarrerak barruti huts batera eramaten du eta sintoma aste batzuk geroago itzultzen da itxurazko kausarik gabe. Bidea bezeroaren beraren up-scriptean idaztea da beste aukera fidagarria, bezeroak taula berridatzi ondoren exekutatzen baita.

Egoerazko suebaki batek bide zuzena garaitu dezake oraindik. Harrapaketak orain erantzuna eth0 interfazetik irteten dela erakusten badu eta bezeroak oraindik denbora-muga jasaten badu, egiaztatu ostalariak paketea bidali aurretik baztertzen duen. Itzulera-bidearen iragazketa zorrotza eta net.ipv4.conf.all.rp_filter 1 baliora ezarrita, iritsi ziren interfazetik atzera bideratuko ez litzatekeen iturria duten paketeak baztertzen dituzte, eta hori da hain zuzen oraintxe sortu eta gero konpondu duzun kasu asimetrikoa, eta conntrack egoerak istorio bera kontatzen du birbidalitako ataken kasuan.

Azken egiaztapena jendeak saltatzen duena da: errepikatu kontsulta tunela behera egon eta berriz gora egin ondoren. Lau baliok bat etorri behar dute idatzi zenuenarekin: helburua, hurrengo jauzia, gailua eta hautatutako iturria. Horietako edozein mugitu bada, bezeroak taula berridatzi du eta konponbidea haren kakoen parte da, ez shell baten historialaren parte.