Koko tunnelointi vai päätepisteen reitti: VPN-palvelimen pitäminen tavoitettavana
Tunneli kulkee sen verkon yli, jonka se korvaa. Vertaa isäntäreitin poikkeusta sovellustason socket-merkintään ja tiedä, milloin kumpikin pettää.
Lisää oletusreitti tunnelin kautta, niin tunnelin omat paketit seuraavat sitä. Taulu sisältää silloin säännön, joka kumoaa itsensä. Salattu yhteys palvelimeen yrittää kulkea sen yhteyden sisällä, jota se yrittää muodostaa.
Kaksi mekanismia estää tuon silmukan. Toinen näkyy reititystaulussa, toinen elää sovelluksen sisällä.
Sisempi ja ulompi liikenne ovat eri päätöksiä
Sovelluksen paketti saapuu virtuaaliliitäntään ja kapseloidaan. Tuloksena on uusi paketti, joka on osoitettu palvelimen julkiseen osoitteeseen. Tämä paketti tarvitsee reitin fyysisessä verkossa, koska mikään siitä ei saa mennä tunneliin.
Molemmat ovat reitityspäätöksiä, ja vain ensimmäinen kuuluu tunnelille. Kun asiakas asentaa oletusreitin, joka kattaa myös palvelimen, myös ulompi paketti siepataan.
Oireet ovat välittömiä ja täydellisiä. Kättely valmistuu ja sen jälkeen mikään ei virtaa, tai yhteys katkeaa heti, kun reitti asennetaan. Kummassakin tapauksessa keepalive ei voi enää lähteä.
Vaihtoehto yksi: isäntäreitti päätepisteelle
Suora lähestymistapa lisää reitin palvelimen osoitteelle alkuperäisen yhdyskäytävän kautta. Se vie yhden rivin. Se näkyy jokaiselle, joka lukee taulua. Se on myös helppo selittää muutosmerkinnässä.
Sen heikkous ilmenee, kun alla oleva polku muuttuu. Tallennettu reitti nimeää yhdyskäytävän ja liitännän vanhasta verkosta. Wi-Fi-vaihdon jälkeen sitä yhdyskäytävää ei ehkä ole, ja reitti jää jäljelle, näyttää oikealta eikä tee mitään.
# 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
Isäntänimi tekee tästä vaikeampaa. Jos päätepiste on nimi, joka ratkeaa useaksi osoitteeksi, poikkeuksen on katettava osoite, jota todella käytetään. Myöhempi haku voi palauttaa jotain, mitä reitti ei koskaan kattanut.
Vaihtoehto kaksi: suojaa socket
Toinen lähestymistapa ei koske reititystauluun koskaan. Asiakas merkitsee tai suojaa socketin, joka kuljettaa tunnelia, joten käyttöjärjestelmä lähettää kyseisen socketin liikenteen tunnelin ulkopuolelle käytännön mukaan. Android tarjoaa mekanismin suoraan VPN-sovelluksille. Työpöytäasiakkaat toteuttavat vastineet palomuurimerkinnöillä tai laitteeseen sitomisen kutsuilla.
Etuna on, että poikkeus seuraa yhteyttä eikä tallennettua yhdyskäytävää. Verkon muutos kirjoittaa alla olevan polun uudelleen, ja suojattu socket siirtyy sen mukana, koska sitä ei koskaan kiinnitetty osoitteeseen. Reititystaulu pysyy puhtaana.
Hinta on näkyvyys. Mikään reititystaulussa ei näytä poikkeusta, joten isäntäreittiä etsivä katselmoija ei löydä mitään ja voi päätellä, että suunnittelu on turvaton. Suoja elää asiakkaan koodissa ja sen asentamissa käytäntösäännöissä.
Valinta niiden välillä
Valitse socket-tason mekanismi, kun asiakas tukee sitä, koska se kestää verkkomuutokset, jotka rikkovat kiinnitetyn reitin. Valitse isäntäreitti, kun poikkeuksen on oltava muiden työkalujen nähtävissä tai kun asiakas ei tarjoa mitään parempaa.
Kumpikaan mekanismi ei poista tarvetta sille, että palvelimen osoite on ylipäätään tavoitettavissa. Yksityisellä yhdyskäytävällä on julkinen kuunteluosoite, ja juuri sen osoitteen on pysyttävä tunnelin ulkopuolella. Sen takana olevat sisäverkot tulevat tavoitettaviksi vasta, kun tunneli on olemassa.
Minkä tahansa valitsetkin, pidä se tunnelin omistavan komponentin luona. Käsin lisätty irrallinen isäntäreitti toimii seuraavaan verkkoon asti, ja sitten siitä tulee huomisen mystinen katkos.