Kas rändlev VPN-klient saab kontorile teenust majutada?
Rändlev klient saab kontorisüsteeme teenindada ainult siis, kui lüüs suunab tema poole, hostipoliitika seda lubab ja seade jääb piisavalt kauaks kättesaadavaks.
Sinu kontori sülearvuti saab kodust sisse helistada ja ikkagi pakkuda midagi, mida kontor vajab, aga ainult siis, kui kolm eraldi otsust kokku langevad. Tunnel on transport, sisemine aadress on sihtkoht ja poliitika otsustab, kes võib koputada. Kui käsitleda ükskõik millist neist kogu vastusena, tekib tuttav kaebus: host vastab pingidele, aga rakendus ei ühenda kunagi. Rollid ei ole samad ja erinevus on täpselt seal, kus elab disainitöö.
Sissehelistamise suund ei ütle teenuse suuna kohta midagi
Kui klient käivitab tunneli, avab see tee, mida mõlemad suunad saavad kasutada, kui see on olemas. Kas uus ühendus tohib jaoturist selle kliendi poole siseneda, on lüüsi poliitika küsimus, mitte selle omadus, kes sisse helistas. Näiteks ruuditud OpenVPN jaoturis vajab server marsruuti kliendi sisemise aadressi juurde ja edastamist, mis lubab peer-suhet.
Kujuta ette laosüsteemi, mis küsitleb rändlevate sülearvutite agenti, või arendajat, kes vajab kodust tööjaamast test-API-t. Mõlemad tahavad, et kontori pool alustaks vestlust, mis on tavalisest klient-serveri mustrist vastupidine.
Majutatud kaugjuurdepääsu tooted erinevad siin ja see erinevus ei ole viga. Mõned hallatavad VPN-teenused blokeerivad teadlikult soovimatuid ühendusi ühendatud klientide suunas, sest nende mudel on klient-ressursini, mitte ressurss-kliendini. Loe toote dokumenteeritud arhitektuuri enne, kui lubad kolleegile, et tema sülearvuti saab serverina toimida.
Jälgi vastusteekonda enne pordi avamist
Teel on kolm osa: lüüsil marsruut, mis osutab kliendi sisemisele aadressile, poliitika, mis lubab konkreetset helistajat, ja sihtmärgil kuulav teenus. Iga osa ebaõnnestub erinevalt, seepärast ei ütle «VPN töötab» peaaegu midagi.
Hea uudis on see, et sisemine tee ei vaja kliendi koduruuteris pordi edastamist. Just selles on mõte avaldada teenus tunneli aadressil, mitte kodu WAN-aadressil, kus avatus ja NAT-reeglid oleksid täiesti teistsugused. Koduruuter võib ka keelduda kontorist saabuva ühenduse hairpinimisest, nii et WAN-tee ebaõnnestub põhjustel, mis pole sinu VPN-iga seotud. Liikluse tunnelis hoidmine väldib mõlemat probleemi korraga.
Kontrolli ka sihtmärgi poolt. Ainult 127.0.0.1 külge seotud teenus ei saa vastu võtta tunneliliidesele saabuvat ühendust, ükskõik kui õiged on lüüsi marsruudid. Hosti tulemüürireegel, mis lubab porti ainult kohalikust alamvõrgust, jätab samuti kontori liikluse kõrvale ja see reegel on sõltumatu temast kõrgemal olevast VPN-poliitikast.
Nimed ja aadressid on disainiotsused
Tunneli sisene aadress ei ole automaatselt nimi. Privaatne DNS-kirje, mida kontrollid, on selgem kui lootus, et avastusprotokoll tunneli ületab, sest link-local multicast nime lahendamine jääb kohalikku segmenti ega muutu alamvõrkudevaheliseks DNS-iks.
Aadressi stabiilsus on sama oluline. Kui VPN-kliendid võtavad lühikese rendiajaga basseinist, muutub sülearvuti sisemine aadress seansside vahel ja iga järjehoidja, tulemüüri ulatus ja jälgimiskontroll, mis sellele ehitatud, puruneb vaikselt. Kasuta reserveeringut või dokumenteeritud dünaamilise värskendamise teed.
Kooskõlasta nimi sellega, kellele kuulub VPN-i identiteet, et kirje, aadressi määramine ja juurdepääsupoliitika muutuksid koos, mitte kolmes eraldi pileti.
Testi teenust, mitte liikmelisust
Sihtmärgilt kinnita, mis kuulab ja mis aadressil, seejärel kinnita lüüsi vaade tagasiteele:
$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23
Nüüd testi kontori poolelt päris päringuga, mitte kajaga. Edukas curl teenuse vastu tõestab marsruudi, poliitika ja kuulaja korraga, samas kui edukas ping tõestab ainult seda, et ICMP on lubatud. Kui päring ebaõnnestub, liigu kolme osa kaudu tagasi, selle asemel et tulemüüri laiendada ja loota.
Kättesaadavus kuulub samasse vestlusesse. Sülearvuti magab, rändab võrkude vahel ja katkeb päeva lõpus. Teenus, mis peab vastama igal tunnil, kuulub alati sisselülitatud hostile, samas kui parimal jõul töötav teenus võib jääda kliendile, kui see piirang on kirja pandud.
Avalda ressurss teadlikult, nime, lubatud helistajate loendi ja omanikuga, ja kaugseade muutub toetatud teenuseks, mitte juhuslikuks serveriks.