Tunel osoak zure SSH saioa hil zuen: finkatu itzulera-bidea
Tunel osoak zure SSH saioaren erantzunak ere harrapatzen ditu. Finkatu ostalari-bide bat zure administrazio helbiderako ataka zaharretik, eta berrinstalatu berriz konektatzean.
Abiarazi OpenVPN bezero bat SSH bidez erabiltzen ari zaren makinan, eta komandoaren erdian saioa izoztu egiten da. Tunelak konektatuta dagoela dio, ostalariak haren bidez internetera iristen da, eta zure tekla-sakatzeak iristen jarraitzen dute ezer itzuli gabe. Aldatu dena ez da tunela: zuri zuzendutako paketeen itzulera-bidea da, orain defektuzko bide berriarekin bat egiten duena eta urrutiko atakak zure mahaira iristeko erabiliko ez duen tunel batean sartzen dena.
Zer instalatzen duen redirect-gateway-ek benetan
Bere def1 forman redirect-gateway gehitzen ditu 0.0.0.0/1 eta 128.0.0.0/1 defektuzko bidea gainidatzi beharrean. Bi erdiek helbide-espazio osoa hartzen dute, eta biek jarraitzen dute 0.0.0.0/0 baino aurrizki luzeagoak, beraz, bat-etortze zehatzagorik ez duen helmuga orok tunelera jotzen du orain. Hori da gogoratu beharreko mekanismoa, azpiko konponketa bakoitzak bat-etortze zehatzago bat instalatuz egiten baitu lan.
Zure administrazio helbidea helmuga horietako bat da.
VPN zerbitzariak bere bezeroen trafikoa internet aldera birbidaltzen du. Ez du zu konektatzen zaren helbide publikorako biderik, ezta pakete horiek bezerorengandik datozen trafikoaz bestela tratatzeko arrazoirik ere, beraz, baztertu egiten ditu. Bitartean, bidali zenuen eskaerak ostalaria iritsi zen hala ere, eta horregatik saioa alde batetik baino ez dirudi bizirik.
ip route show table main | head -n 20
ip route get 198.51.100.23Aurkitu zure iturburu-helbidea eta tunelaren aurreko bidea
Zerbitzarian, zerrendatu ezarritako SSH konexioa eta idatzi hura iritsi zen pareko helbidea. Helbide hori da zure itzulera-bideak estali behar duena, eta ez da beti pentsatzen duzuna: jauzi-ostalari batek, NAT ataka batek edo operadorearen itzultzaile batek beste iturburu bat jar dezakete.
Gero, aurkitu tunela abiarazi aurretik trafikoa eraman zuten ataka fisikoa eta interfazea. def1 konfigurazioan defektuzko bidea oraindik dago erdi-defektuzkoen azpian, beraz informazioa eskuragarri dago, nahiz eta bide-taulera luze bat begiz irakurtzeak erroreak gonbidatzen dituen.
Idatzi bi balioak eta interfazearen izena elkarrekin, gehitu behar duzun bideak hirurak behar baititu. Ostalariak politika-bideratzeko araua erabili bazuen bere uplinka aukeratzeko, baliteke bide arrunta ez aztertzea, eta aukera horrek konponketa aldatzen du.
Finkatu erdi-defektuzkoak gainditzen dituen ostalari-bide bat
Bide bat /32 bi erdi-defektuzkoak baino luzeagoa da, beraz zure helbiderako erantzunek tunelaren ordez hura hartzen dute. Hurrengo jauzia tunelaren aurreko ataka da eta gailua interfaze fisikoa da, eta horrek paketea tunela existitu aurretik erabiltzen zuen bidean mantentzen du.
ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0Egiaztatu bilaketa batekin taula ikuskatu beharrean: erantzunak eth0 eta ataka izendatu behar ditu, inoiz ez tun0.
OpenVPN-ek jada gehitzen du ostalari-bide bat VPN zerbitzariaren beraren helbidera arrazoi beragatik, beraz eredua ezaguna da eta administrazio helbidea beste salbuespen bat besterik ez da. Ez jo route-nopull konpontzeko, botatako bideak baztertzen baititu tunelak behar dituenak, besteak beste urrutiko sarea eta DNS aukerak.
Egin dezala berriz konektatze bat gainditu
Eskuz gehitutako bide bat desagertu egiten da bezeroa berriz konektatu eta berea instalatzen duenean, eta horrek konponketa etengabeko etenaldia bihurtzen du. Lotu komandoa bideak instalatu ondoren exekutatzen den zerbaiti.
Bai route-up script batek bai sare-kudeatzailearen pre-up kakoak balio dute, eta egiaztapen fidagarria berriz konektatu eta gero bilaketa bera egitea da.
Windows-en baliokidea -p erabiliz gehitutako bide iraunkorra da, berrabiarazteak gainditzen dituena baina sare-aldaketa baten ondoren ataka zuzena seinalatu behar duena. Plataforma edozein dela ere, idatzi arrazoia bidearen ondoan: hurrengo administratzaileak jakin behar du existitzen dela kudeaketa-saio bat babesteko, ez zelako sare-diseinuak hala eskatzen zuen.
Finkatutako bide bat oraindik nahikoa ez denean
Itzulera-bideko iragazketak baztertu dezake interfaze batetik iristen eta beste batetik irteten den pakete bat, eta hori da finkatutako bide batek sortzen duena. Egiaztatu rp_filter balio eraginkorra ezer globalean desgaitu aurretik, eta hobetsi asimetria konpontzea egiaztapena itzaltzearen ordez. Interfaze bakoitzeko ezarpena da aplikatzen dena, eta loose moduak sarritan asimetria erregistratzen du soilik paketea baztertu beharrean. Irakurri biak iragazkia zure errua delako ondorioa atera aurretik.
Politika-bideratzea duten ostalariek araua behar dute bideaz gain, arau-oinarriak taula aukeratzen baitu bertako bidea aztertu aurretik. main taulako bide bat ikusezina da beste taula batera seinalatzen duen arau batekin bat egiten duen fluxuarentzat. Irakurri arauak main-era ezer gehitu aurretik. Arau batek kudeaketa-trafikoa estaltzen badu, salbuespena arau horren taulara doa.
Eduki kanpo-banda kanpoko kontsola irekia probatzen duzun bitartean, eta egiaztatu berriro bigarren saio batetik erabiltzen ari zarena deskonektatu aurretik. Zure kudeaketa-trafikoa tunelera bidaltzen duen bide batek konponketa egiten ari zaren konexioa mozten du. Orduan berriro sartzeak kontsola seriekoa edo erreskate-abioa esan nahi du, eta hori truke txarra da egiaztapen-pauso bat saltzeagatik.