Zaženete VPN odjemalca prek SSH? Najprej pripnite svojo lastno pot

Prek SSH se prijavite v gradbenega gostitelja, na njem zaženete VPN odjemalca in seja preneha odgovarjati. Nič se ni zrušilo in nič ni videti napačno konfigurirano v očitnem smislu. Odjemalec je namestil privzeto pot, zato odgovori na vašo delovno postajo zdaj odhajajo skozi tunel, kjer naslov vaše delovne postaje ni usmerljiv. Zanimivo je, da je bil ta izid predvidljiv, popravek pa je ena pot, zapisana pred zagonom odjemalca. Predpostavimo strežnik z eno omrežno kartico, prehod 192.0.2.254 in skrbnika, ki se povezuje z 203.0.113.9.

Zapišite pot pred začetkom

ip route show default navaja trenutni prehod in vmesnik, medtem ko ip route get 203.0.113.9 prikazuje, kateri vmesnik in izvorni naslov bi jedro uporabilo za vašo sejo. Shranite oba izhoda. Ko se tunel dvigne, bi morali ta dva ukaza še vedno opisovati fizično pot, in če opisujeta tunel, seja že živi na izposojenem času.

Pomembna je že vzpostavljena povezava, zato ne preverjajte le z novo prijavo. Nova seja lahko za kratek čas uspe zaradi stanja, ki ga stara nima več.

Pripnite naslov v konfiguraciji samega odjemalca

Pot, dodana ročno, izgine ob ponovnem zagonu in tekmuje z lastnimi posodobitvami tabele odjemalca, zato izjemo postavite tja, kjer se tabela upravlja. V OpenVPN se ključna beseda net_gateway razreši v prehod, ki je obstajal pred tunelom, zato route 203.0.113.9 255.255.255.255 net_gateway ohrani natanko en naslov zunaj njega. WireGuard potrebuje drugačen pristop, ker wg-quick sam upravlja poti: nastavite Table = off in dodajte izjemo v PostUp, z ustreznim PostDown, ki jo odstrani. Obe obliki izražata isti namen in obe omejujeta izjemo na en naslov, namesto da bi oslabili tunel za vse.

Za IPv6 ista zamisel vzame predpono enega gostitelja, in primer ovitega prenosa si velja zapomniti: če zunanja povezava samega tunela živi na fiksnem naslovu, mora ta naslov ostati zunaj tunela, ki ga nosi, sicer odjemalec usmeri svoj lastni prenos vase.

Ali pa vzemite glavno tabelo iz enačbe

Ko mora več storitev na gostitelju ohraniti svojo običajno pot, prenehajte urejati glavno tabelo in dajte odjemalcu svojo. Omrežni imenski prostor s parom veth to naredi čisto: privzeta pot odjemalca živi v drugem skladu in tunel uporabljajo le procesi, zagnani v njem. Usmerjanje po pravilnikih doseže podobno mesto za en cilj, ko ustrezni promet pošlje v namensko tabelo, katere privzeta pot še vedno kaže na fizični prehod. Vsak od pristopov pusti glavno tabelo gostitelja brez nove privzete poti, in prav ta lastnost ohranja SSH pri odgovarjanju.

Oba sta več mehanike kot ena pot do gostitelja in oba se izplačata, ko mora tunel preživeti več kot ena stvar na stroju.

Predpostavite, da pripenjanje lahko ne uspe

Pot, vezana na vaš trenutni javni naslov, se zlomi v trenutku, ko vam ga ponudnik znova dodeli. Oddaljeni strežnik takrat potrebuje pot, ki ni odvisna od tega naslova: konzolo, drugi vmesnik za upravljanje ali preskočnega gostitelja, ki ostane zunaj tunela.

Dva varnostna ukrepa staneta deset minut. Čuvaj, ki ustavi odjemalca, če se v nekaj minutah ne pojavi potrditvena prijava, spremeni zaklep v zamudo, druga seja SSH, držana odprta med spremembo, pa dokazuje, da izjema deluje, dokler je tunel dvignjen. Sami keepalives tu ne pomagajo, ker je pot izginila in ni nedejavna; le olajšajo opaziti smrt.

Preverite v vrstnem redu, ki je pomemben

Povežite tunel, potrdite, da pot do vašega naslova še vedno odhaja skozi fizični prehod, nato odprite novo sejo. Če nova seja deluje in stara vseeno umre, je vzrok sledenje povezavam ali požarni zid s stanjem in ne usmerjanje, kar je drugačen popravek.

Zapišite pripeti naslov in ukaz, ki ga je dokazal, v dnevnik sprememb. Naslednja oseba, ki bo na tem gostitelju zagnala odjemalca, bo potrebovala oboje, naslov pa se je do takrat morda že spremenil.