Voltunnel teenoor eindpunt-roete: hou die VPN-bediener bereikbaar

Voeg 'n verstekroete deur die tonnel by, en die tonnel se eie pakkette volg dit. Die tabel bevat dan 'n reël wat homself verydel. Die versleutelde verbinding na die bediener probeer binne die verbinding beweeg wat hy probeer opstel.

Twee meganismes verhoed daardie lus. Een is in die roetetabel sigbaar, die ander woon in die toepassing.

Binneste en buitenste verkeer is verskillende besluite

'n Toepassingspakket gaan die virtuele koppelvlak binne en word ingekapsel. Die resultaat is 'n nuwe pakket wat na die bediener se openbare adres gerig is. Daardie pakket het 'n roete op die fisiese netwerk nodig, want niks daarvan mag die tonnel binnegaan nie.

Albei is roetebesluite, en net die eerste een hoort by die tonnel. Wanneer die kliënt 'n verstekroete installeer wat ook die bediener dek, word die buitenste pakket ook gevang.

Die simptome is onmiddellik en totaal. Die handdruk voltooi en dan vloei niks, of die verbinding val die oomblik toe die roete geïnstalleer word. In albei gevalle kan die lewendhou nie meer uitgaan nie.

Opsie een: 'n host-roete vir die eindpunt

Die direkte benadering voeg 'n roete vir die bediener se adres deur die oorspronklike poort by. Dit neem een reël. Dit is sigbaar vir enigiemand wat die tabel lees. Dit is ook maklik om in 'n veranderingsrekord te verduidelik.

Die swakheid daarvan verskyn wanneer die onderliggende pad verander. Die gestoorde roete noem 'n poort en 'n koppelvlak uit die ou netwerk. Na 'n Wi-Fi-skakel bestaan daardie poort dalk nie meer nie, en die roete bly agter, lyk korrek en doen niks.

# 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

'n Gasheernaam maak dit moeiliker. As die eindpunt 'n naam is wat na verskeie adresse oplos, moet die uitsondering die adres dek wat werklik in gebruik is. 'n Latere opsoek kan iets teruggee wat die roete nooit gedek het nie.

Opsie twee: beskerm die sokkel

Die ander benadering raak nooit die roetetabel nie. Die kliënt merk of beskerm die sokkel wat die tonnel dra, sodat die bedryfstelsel daardie sokkel se verkeer per beleid buite die tonnel stuur. Android stel die meganisme direk aan VPN-toepassings beskikbaar. Tafelbladkliënte implementeer ekwivalente met brandmuurmerke of bind-to-device-oproepe.

Die voordeel is dat die uitsondering die verbinding volg eerder as 'n gestoorde poort. 'n Netwerkverandering herskryf die onderliggende pad, en die beskermde sokkel beweeg saam omdat dit nooit aan 'n adres vasgepen was nie. Die roetetabel bly skoon.

Die koste is sigbaarheid. Niks in die roetetabel wys die uitsondering nie, so 'n keurder wat na 'n host-roete soek, vind niks en kan tot die gevolgtrekking kom dat die ontwerp onveilig is. Die beskerming woon in die kliënt se kode en in die beleidsreëls wat daardie kode installeer.

Om tussen hulle te kies

Kies die sokkelvlak-meganisme wanneer die kliënt dit ondersteun, want dit oorleef die netwerkveranderinge wat 'n vasgepende roete breek. Kies die host-roete wanneer die uitsondering vir ander gereedskap sigbaar moet wees, of wanneer die kliënt niks beters bied nie.

Nie een van die meganismes verwyder die noodsaak dat die bedieneradres hoegenaamd bereikbaar moet wees nie. 'n Privaat poort het 'n openbare luisteraarsadres, en daardie adres is wat buite die tonnel moet bly. Die interne netwerke daar agter word eers bereikbaar nadat die tonnel bestaan.

Watter een jy ook kies, hou dit by die komponent wat die tonnel besit. 'n Verdwaalde host-roete wat met die hand bygevoeg is, werk tot die volgende netwerk, en dan word dit môre se raaiselagtige onderbreking.