Full tunnel eller endepunktrute: å holde VPN-serveren tilgjengelig

Legg til en standardrute gjennom tunnelen, og tunnelens egne pakker vil følge den. Tabellen inneholder da en regel som beseirer seg selv. Den krypterte forbindelsen til serveren prøver å reise inne i forbindelsen den prøver å opprette.

To mekanismer hindrer den løkken. Den ene er synlig i rutetabellen, den andre lever inne i applikasjonen.

Indre og ytre trafikk er forskjellige beslutninger

En applikasjonspakke går inn i det virtuelle grensesnittet og blir innkapslet. Resultatet er en ny pakke adressert til serverens offentlige adresse. Den pakken trenger en rute på det fysiske nettverket, for ingenting ved den kan gå inn i tunnelen.

Begge er rutebeslutninger, og bare den første hører til tunnelen. Når klienten installerer en standardrute som også dekker serveren, blir den ytre pakken også fanget.

Symptomene er øyeblikkelige og totale. Håndtrykket fullføres og deretter flyter ingenting, eller forbindelsen faller i det øyeblikket ruten installeres. I begge tilfeller kan keepalive ikke lenger komme ut.

Alternativ én: en vertsrute for endepunktet

Den direkte tilnærmingen legger til en rute for serverens adresse gjennom den opprinnelige gatewayen. Det krever én linje. Den er synlig for alle som leser tabellen. Den er også lett å forklare i en endringslogg.

Svakheten viser seg når den underliggende veien endres. Den lagrede ruten navngir en gateway og et grensesnitt fra det gamle nettverket. Etter et Wi-Fi-bytte finnes kanskje ikke den gatewayen, og ruten blir liggende igjen, ser riktig ut og gjør ingenting.

# 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

Et vertsnavn gjør dette vanskeligere. Hvis endepunktet er et navn som løses til flere adresser, må unntaket dekke adressen som faktisk brukes. Et senere oppslag kan returnere noe ruten aldri dekket.

Alternativ to: beskytt socketen

Den andre tilnærmingen rører aldri rutetabellen. Klienten merker eller beskytter socketen som bærer tunnelen, slik at operativsystemet sender trafikken fra den socketen utenfor tunnelen etter policy. Android eksponerer mekanismen direkte for VPN-applikasjoner. Skrivebordsklienter implementerer ekvivalenter med brannmurmerker eller bind-til-enhet-kall.

Fordelen er at unntaket følger forbindelsen i stedet for en lagret gateway. Et nettverksbytte skriver om den underliggende veien, og den beskyttede socketen flytter med fordi den aldri ble festet til en adresse. Rutetabellen forblir ren.

Prisen er synlighet. Ingenting i rutetabellen viser unntaket, så en gjennomgåer som leter etter en vertsrute finner ingenting og kan konkludere med at designet er utrygt. Beskyttelsen lever i klientens kode og i policyreglene den koden installerer.

Å velge mellom dem

Velg socket-mekanismen når klienten støtter den, fordi den overlever nettverksbyttene som ødelegger en festet rute. Velg vertsruten når unntaket må være synlig for andre verktøy, eller når klienten ikke tilbyr noe bedre.

Ingen av mekanismene fjerner behovet for at serveradressen i det hele tatt er tilgjengelig. En privat gateway har en offentlig lyttadresse, og det er den adressen som må bli utenfor tunnelen. De interne nettverkene bak den blir først tilgjengelige når tunnelen finnes.

Uansett hva du velger, hold det hos komponenten som eier tunnelen. En løs vertsrute lagt til for hånd fungerer til neste nettverk, og da blir den morgendagens mystiske avbrudd.