Startsto in VPN-klient oer SSH? Pinje earst dyn eigen rûte

Do SSH-est nei in bouthost, startest dêr de VPN-klient, en de sesje hâldt op mei antwurdzjen. Neat is crasht, en neat liket op ’e mjitte ferkeard konfigurearre yn ’e foarbyldige sin. De klient ynstallearre in standertrûte, sadat antwurden nei dyn wurkstasjon no fia de tunnel fuortgeane, wêr’t it adres fan dyn wurkstasjon net berikber is. It nijsgjirrige is dat dizze útkomst foarsisber wie, en de oplossing is ien rûte dy’t skreaun wurdt foardat de klient start. Nim oan in server mei ien netwurkkaart, in gateway fan 192.0.2.254, en in behearder dy’t ferbynt fan 203.0.113.9 ôf.

Skriuw it paad op foardatsto begjinst

ip route show default neamt de hjoeddeiske gateway en ynterface, wylst ip route get 203.0.113.9 sjen lit hokker ynterface en boarneadres de kernel foar dyn sesje brûke soe. Hâld beide útfieringen. Nei’t de tunnel omheech komt, moatte dy twa kommando’s noch it fysike paad beskriuwe, en as se ynstee de tunnel beskriuwe, libbet de sesje al op liend tiid.

It is de al fêstige ferbining dy’t fan belang is, dus falidearje net allinne mei in nije oanmelding. In nije sesje kin koart slagje troch tastân dy’t de âlde net mear hat.

Pinje it adres yn ’e eigen konfiguraasje fan de klient

In rûte dy’t mei de hân taheakke is, ferdwynt by it opnij opstarten en raceet mei de eigen tabelfernijingen fan ’e klient, dus set de útsûndering dêr’t de tabel beheard wurdt. Under OpenVPN kin it kaaiwurd net_gateway oplost wurde nei de gateway dy’t der foar de tunnel wie, dus route 203.0.113.9 255.255.255.255 net_gateway hâldt krekt ien adres dêr bûten. WireGuard hat in oare oanpak nedich omdat wg-quick de rûtes sels beheart: set Table = off en foegje de útsûndering ta yn PostUp, mei in byhearrende PostDown dy’t it fuorthellet. Beide foarmen uterje deselde bedoeling, en beide beheine de útsûndering ta ien adres ynstee fan de tunnel foar alles te ferswakjen.

Foar IPv6 nimt itselde idee in foarheaksel fan ien host, en it gefal fan ferpakke ferfier is it wurdich te ûnthâlden: as de bûtenferbining fan ’e tunnel sels op in fêst adres libbet, moat dat adres bûten de tunnel bliuwe dy’t it draacht, oars rûtet de klient syn eigen ferfier yn himsels.

Of helje de haadtabel út ’e diskusje

As ferskate tsjinsten op ’e host har normale paad hâlde moatte, stopje dan mei it bewurkjen fan ’e haadtabel en jou de klient syn eigen. In netwurknammeromte mei in veth-pear docht dat skjin: de standertrûte fan ’e klient libbet yn in oare stapel en allinnich prosessen dy’t dêr binnen starten brûke de tunnel. Beliedsrouting berikt in ferlykber plak foar ien bestimming, troch passend ferkear nei in tawijde tabel te stjoeren wêrfan’t de standert noch nei de fysike gateway wiist. Elk fan ’e oanpakken lit de haadtabel fan ’e host sûnder in nije standertrûte, en dat is de eigenskip dy’t SSH antwurdzjen hâldt.

Beide binne mear masjinerie as ien hostrûte, en beide binne it wurdich as mear as ien ding op ’e doaze de tunnel oerlibje moat.

Nim oan dat it pinjen mislearje kin

In rûte keppele oan dyn hjoeddeiske iepenbiere adres brekt op it stuit dat dyn oanbieder it opnij tawijst. In server op ôfstân hat dan in paad nedich dat net fan dat adres ôfhinklik is: in console, in twadde beheardynterface, of in springhost dy’t bûten de tunnel bliuwt.

Twa feilichheidsmaatregelen kostje tsien minuten. In watchdog dy’t de klient stoppet as in befêstigingsonomylding net binnen in pear minuten ferskynt, feroaret in útsluting yn in fertraging, en in twadde SSH-sesje dy’t ûnder de feroaring iepen holden wurdt, bewiist dat de útsûndering wurket wylst de tunnel omheech is. Allinne keepalives helpe hjir net, want it paad is fuort ynstee fan ynaktyf; se meitsje de dea allinnich makliker te merken.

Ferifiearje yn ’e folchoarder dy’t fan belang is

Ferbyn de tunnel, befêstigje dat de rûte nei dyn adres noch fia de fysike gateway fuortgiet, en iepenje dan in nije sesje. As de nije sesje wurket en de âlde dochs stjert, is de oarsaak ferbiningsfolgjen of in stateful firewall ynstee fan routing, wat in oare oplossing is.

Skriuw it fêstpine adres en it kommando dat it bewiisde yn ’e feroaringslog. De folgjende persoan dy’t in klient op dy host start, hat beide nedich, en it adres kin dan al feroare wêze.