Käynnistätkö VPN-asiakkaan SSH:n yli? Kiinnitä ensin oma reittisi
Koko tunnelin asiakas kirjoittaa uudelleen taulun, joka kuljettaa SSH-vastauksesi. Kiinnitä yksi isäntäreitti vanhan yhdyskäytävän kautta tai aja asiakas omassa nimiavaruudessaan.
Kirjaudut SSH:lla build-isäntään, käynnistät siinä VPN-asiakkaan, ja istunto lakkaa vastaamasta. Mikään ei kaatunut, eikä mikään näytä ilmeisessä mielessä väärin konfiguroidulta. Asiakas asensi oletusreitin, joten vastaukset työasemallesi lähtevät nyt tunnelin kautta, jossa työasemasi osoite ei ole reititettävissä. Mielenkiintoista on, että tämä lopputulos oli ennakoitavissa, ja korjaus on yksi reitti, joka kirjoitetaan ennen asiakkaan käynnistymistä. Oletetaan palvelin, jossa on yksi verkkokortti, yhdyskäytävä 192.0.2.254 ja ylläpitäjä, joka yhdistää osoitteesta 203.0.113.9.
Kirjaa polku ennen aloittamista
ip route show default nimeää nykyisen yhdyskäytävän ja liitännän, kun taas ip route get 203.0.113.9 näyttää, mitä liitäntää ja lähdeosoitetta ydin käyttäisi istunnollesi. Säilytä molemmat tulosteet. Tunnelin noustua näiden kahden komennon pitäisi yhä kuvata fyysistä polkua, ja jos ne kuvaavatkin tunnelia, istunto elää jo lainatulla ajalla.
Merkitsevää on jo muodostettu yhteys, joten älä validoi pelkällä uudella kirjautumisella. Uusi istunto voi onnistua hetken tilan kautta, jota vanhalla ei enää ole.
Kiinnitä osoite asiakkaan omassa kokoonpanossa
Käsin lisätty reitti katoaa uudelleenkäynnistyksessä ja kilpailee asiakkaan omien taulupäivitysten kanssa, joten laita poikkeus sinne, missä taulua hallitaan. OpenVPN:ssä avainsana net_gateway ratkeaa yhdyskäytäväksi, joka oli olemassa ennen tunnelia, joten route 203.0.113.9 255.255.255.255 net_gateway pitää täsmälleen yhden osoitteen sen ulkopuolella. WireGuard tarvitsee toisenlaisen lähestymistavan, koska wg-quick hallitsee reittejä itse: aseta Table = off ja lisää poikkeus PostUp:ään sekä sitä vastaava PostDown, joka poistaa sen. Molemmat muodot ilmaisevat saman aikomuksen, ja molemmat rajaavat poikkeuksen yhteen osoitteeseen sen sijaan, että heikentäisivät tunnelia kaikelle.
IPv6:lle sama ajatus ottaa yhden isännän etuliitteen, ja käärittyä kuljetusta koskeva tapaus kannattaa muistaa: jos tunnelin oma ulompi yhteys elää kiinteässä osoitteessa, sen osoitteen on pysyttävä sen tunnelin ulkopuolella, jota se kuljettaa, tai asiakas reitittää oman kuljetuksensa itseensä.
Tai ota päätaulu pois yhtälöstä
Kun isännän useiden palveluiden on säilytettävä tavallinen polkunsa, lopeta päätaulun muokkaaminen ja anna asiakkaalle oma. Verkon nimiavaruus veth-parilla tekee sen puhtaasti: asiakkaan oletusreitti elää toisessa pinossa ja tunnelia käyttävät vain sen sisällä käynnistetyt prosessit. Käytäntöperusteinen reititys pääsee samaan paikkaan yhdelle kohteelle lähettämällä täsmäävän liikenteen omaan tauluun, jonka oletus osoittaa edelleen fyysiseen yhdyskäytävään. Kumpikin lähestymistapa jättää isännän päätaulun ilman uutta oletusreittiä, ja juuri se ominaisuus pitää SSH:n vastaamassa.
Molemmat ovat enemmän koneistoa kuin yksi isäntäreitti, ja molemmat ovat sen arvoisia, kun useamman kuin yhden asian koneella on selvittävä tunnelista.
Oleta, että kiinnitys voi epäonnistua
Nykyiseen julkiseen osoitteeseesi sidottu reitti katkeaa heti, kun palveluntarjoajasi määrittää sen uudelleen. Etäpalvelin tarvitsee silloin polun, joka ei riipu siitä osoitteesta: konsolin, toisen hallintaliitännän tai hyppypalvelimen, joka pysyy tunnelin ulkopuolella.
Kaksi varotoimea maksaa kymmenen minuuttia. Vahdit, joka pysäyttää asiakkaan, jos vahvistuskirjautuminen ei ilmesty muutaman minuutin kuluessa, muuttaa uloslukituksen viiveeksi, ja muutoksen aikana auki pidetty toinen SSH-istunto todistaa, että poikkeus toimii tunnelin ollessa ylhäällä. Pelkät keepalivet eivät tässä auta, koska polku on poissa eikä joutilaana; ne vain tekevät kuolemasta helpomman huomata.
Vahvista siinä järjestyksessä, jolla on merkitystä
Yhdistä tunneli, varmista, että reitti osoitteeseesi lähtee yhä fyysisen yhdyskäytävän kautta, ja avaa sitten uusi istunto. Jos uusi istunto toimii ja vanha kuolee silti, syy on yhteyksien seuranta tai tilallinen palomuuri eikä reititys, mikä on eri korjaus.
Kirjoita kiinnitetty osoite ja komento, joka sen todisti, muutoslokkiin. Seuraava henkilö, joka käynnistää asiakkaan sillä isännällä, tarvitsee molemmat, ja osoite on voinut siihen mennessä muuttua.