Folle tunnel of rûte nei it einpunt: de VPN-tsjinner berikber hâlde

Foegje in standertrûte troch de tunnel ta, en de pakketten fan de tunnel sels folgje dy. De tabel befettet dan in regel dy't himsels ferslacht. De fersifere ferbining mei de tsjinner besiket binnen de ferbining te reizgjen dy't er besiket oan te lizzen.

Twa meganismen foarkomme dy lus. Ien is sichtber yn 'e rûtetabel, de oare libbet yn 'e applikaasje.

Binnen- en bûtenferkear binne ferskillende besluten

In applikaasjepakket giet it firtuele ynterface yn en wurdt ynkapsulearre. It resultaat is in nij pakket dat rjochte is op it iepenbiere adres fan 'e tsjinner. Dat pakket hat in rûte op it fysike netwurk nedich, want neat derfan mei de tunnel yn.

Beide binne rûtebesluten, en allinnich it earste heart by de tunnel. As de klant in standertrûte ynstallearret dy't ek de tsjinner dekt, wurdt it bûtenpakket ek fongen.

De symptomen binne fuortendaliks en folslein. De handshake foltôget en dan floeit der neat, of de ferbining falt fuort op it stuit dat de rûte ynstallearre wurdt. Yn beide gefallen kin de keepalive net mear fuort.

Opsje ien: in host-rûte foar it einpunt

De direkte oanpak foeget in rûte ta foar it adres fan 'e tsjinner fia de oarspronklike gateway. It kostet ien rigel. It is sichtber foar elkenien dy't de tabel lêst. It is ek maklik út te lizzen yn in feroaringsrecord.

Syn swakte docht bliken as it ûnderlizzende paad feroaret. De bewarre rûte neamt in gateway en in ynterface út it âlde netwurk. Nei in Wi-Fi-wiksel bestiet dy gateway miskien net mear, en de rûte bliuwt efter, sjocht der goed út en docht neat.

# before the tunnel: which path reaches the endpoint?
ip route get 198.51.100.7

# pin it through the current gateway
ip route add 198.51.100.7/32 via 192.168.1.1 dev wlan0

# after the tunnel is up, confirm the pin survived
ip route get 198.51.100.7

In hostnamme makket dit dreger. As it einpunt in namme is dy't nei ferskate adressen oplost, moat de útsûndering it adres dekke dat echt brûkt wurdt. In lettere opfraach kin wat weromjaan dat de rûte nea dekte.

Opsje twa: de socket beskermje

De oare oanpak rekket de rûtetabel nea. De klant markearret of beskermet de socket dy't de tunnel draacht, sadat it bestjoeringssysteem it ferkear fan dy socket neffens belied bûten de tunnel stjoert. Android stelt it meganisme direkt beskikber oan VPN-applikaasjes. Desktopklanten ymplementearje ekwivalenten mei firewall-marken of bind-oan-apparaat-opropen.

It foardiel is dat de útsûndering de ferbining folget ynstee fan in bewarre gateway. In netwurkferoaring skriuwt it ûnderlizzende paad oer, en de beskerme socket beweecht mei om't er nea oan in adres fêstset wie. De rûtetabel bliuwt skjin.

De priis is sichtberens. Neat yn 'e rûtetabel toant de útsûndering, dus in beoardieler dy't nei in host-rûte siket fynt neat en kin konkludearje dat it ûntwerp ûnfeilich is. De beskerming libbet yn 'e koade fan 'e klant en yn 'e beliedsregels dy't dy koade ynstallearret.

Kieze tusken beide

Kies it socket-nivo-meganisme as de klant it stipet, want it oerlibbet de netwurkferoarings dy't in fêstsette rûte brekke. Kies de host-rûte as de útsûndering sichtber wêze moat foar oare ark, of as de klant neat better biedt.

Gjin fan beide meganismen hellet de needsaak wei dat it adres fan 'e tsjinner hielendal berikber is. In privee gateway hat in iepenbier harkadres, en dat adres moat bûten de tunnel bliuwe. De ynterne netwurken dêrefter wurde pas berikber as de tunnel bestiet.

Hokker oft jo ek kieze, hâld it by it komponint dat de tunnel besit. In fersweefde host-rûte dy't mei de hân tafoege is, wurket oant it folgjende netwurk, en dan wurdt it de mysterieuze útfal fan moarn.