Käivitad VPN-kliendi üle SSH? Kinnita enne oma marsruut

Sa lähed SSH-ga sisse ehitushosti, käivitad sellel VPN-kliendi ja sessioon lakkab vastamast. Miski ei kukkunud kokku ja miski ei näe ilmsel moel valesti seadistatud välja. Klient paigaldas vaikimisi marsruudi, nii et vastused sinu tööjaamale väljuvad nüüd tunnelist, kus sinu tööjaama aadress ei ole marsruuditav. Huvitav on see, et see tulemus oli etteaimatav, ja parandus on üks marsruut, mis kirjutatakse enne kliendi käivitumist. Eeldame serverit ühe võrgukaardiga, lüüsi 192.0.2.254 ja administraatorit, kes ühendub aadressilt 203.0.113.9.

Kirjuta tee üles enne alustamist

ip route show default näitab praegust lüüsi ja liidest, samas kui ip route get 203.0.113.9 näitab, millist liidest ja lähteaadressi kernel sinu sessiooni jaoks kasutaks. Hoia mõlemad väljundid alles. Pärast tunneli tõusmist peaksid need kaks käsku endiselt kirjeldama füüsilist teed, ja kui nad kirjeldavad hoopis tunnelit, elab sessioon juba laenatud ajal.

Tähtis on juba loodud ühendus, seega ära valideeri ainult uue sisselogimisega. Uus sessioon võib lühidalt õnnestuda oleku kaudu, mida vanal enam ei ole.

Kinnita aadress kliendi enda konfiguratsioonis

Käsitsi lisatud marsruut kaob taaskäivitamisel ja võistleb kliendi enda tabeliuuendustega, seega pane erand sinna, kus tabelit hallatakse. OpenVPN puhul lahendub märksõna net_gateway lüüsiks, mis eksisteeris enne tunnelit, seega route 203.0.113.9 255.255.255.255 net_gateway hoiab täpselt ühe aadressi sellest väljas. WireGuard vajab teistsugust lähenemist, sest wg-quick haldab marsruute ise: sea Table = off ja lisa erand PostUp-sse, koos vastava PostDown-ga, mis selle eemaldab. Mõlemad vormid väljendavad sama kavatsust ja mõlemad piiravad erandi ühe aadressiga, selle asemel et tunnelit kõige jaoks nõrgendada.

IPv6 puhul võtab sama idee ühe hosti prefiksi, ja mähitud transpordi juhtum tasub meeles pidada: kui tunneli enda välimine ühendus elab kindlal aadressil, peab see aadress jääma väljapoole tunnelit, mida ta kannab, muidu marsruudib klient oma transpordi iseendasse.

Või võta põhitabel võrrandist välja

Kui hosti mitmed teenused peavad säilitama oma tavapärase tee, lõpeta põhitabeli redigeerimine ja anna kliendile oma. Veth-paariga võrgu nimeruum teeb seda puhtalt: kliendi vaikimisi marsruut elab teises virnas ja tunnelit kasutavad ainult selle sees käivitatud protsessid. Poliitikapõhine marsruutimine jõuab ühe sihtkoha jaoks sarnasesse kohta, saates sobiva liikluse spetsiaalsesse tabelisse, mille vaikimisi tee osutab endiselt füüsilisele lüüsile. Kumbki lähenemine jätab hosti põhitabeli ilma uue vaikimisi marsruudita, ja just see omadus hoiab SSH vastamas.

Mõlemad on rohkem masinavärki kui üks hosti marsruut, ja mõlemad on seda väärt, kui rohkem kui üks asi masinas peab tunnelist üle elama.

Eelda, et kinnitamine võib ebaõnnestuda

Sinu praeguse avaliku aadressiga seotud marsruut katkeb hetkel, kui sinu pakkuja selle uuesti määrab. Kaugserver vajab siis teed, mis ei sõltu sellest aadressist: konsooli, teist haldusliidest või hüppehosti, mis jääb tunnelist välja.

Kaks kaitsemeedet maksavad kümme minutit. Valvekoer, mis peatab kliendi, kui kinnitusega sisselogimine ei ilmu mõne minuti jooksul, muudab lukustumise hilinemiseks, ja muudatuse ajal lahti hoitud teine SSH-sessioon tõestab, et erand töötab, kui tunnel on üleval. Ainult keepalive'id siin ei aita, sest tee on kadunud, mitte jõude; need muudavad surma vaid märgatavamaks.

Kontrolli selles järjekorras, mis loeb

Ühenda tunnel, kinnita, et marsruut sinu aadressini väljub endiselt füüsilise lüüsi kaudu, seejärel ava uus sessioon. Kui uus sessioon töötab ja vana sureb ikkagi, on põhjuseks ühenduste jälgimine või olekupõhine tulemüür, mitte marsruutimine, mis on teine parandus.

Kirjuta kinnitatud aadress ja käsk, mis seda tõestas, muudatuste registrisse. Järgmine inimene, kes sellel hostil kliendi käivitab, vajab mõlemat, ja aadress võib selleks ajaks olla muutunud.