Kiel publika prokuro atingas privatan originon tra VPN

Publiki retejon tra tunelo kaj doni al uzantoj VPN-aliro estas du malsamaj aranĝoj, kiuj dividas unu kablon. En la unua, publika inversa prokuro akceptas la peton de la vizitanto kaj plusendas ĝin tra la tunelo al origino, kiun neniu povas atingi rekte. En la dua, la uzanto devas aliĝi al la VPN antaŭ ol la aplikaĵo entute estas atingebla. Miksi la du priskribojn estas tio, kio finfine publike elmetas privatan malantaŭan servon.

Du modeloj, kiuj aspektas same sur diagramo

Desegnu la sagojn antaŭ ol elekti ion ajn. Publika publikiga modelo iras de retumilo al prokuro per HTTPS, poste de prokuro al origino tra la tunelo, kaj la origino neniam akceptas konekton el la interreto. Nur-VPN-modelo iras de kliento al enirejo, kaj la aplikaĵo estas atingebla nur el la interno de tiu vojo. La tekkomputilo de la uzanto sidas en la sama reto kiel la aplikaĵo, kaj tio estas la tuta senco de tiu modelo.

La modeloj malsamas laŭ tio, kiu aŭtentikigas kaj kie. En la unua, la prokuro estas la publika enirejo kaj ĝi plusendas ĉiun alvenantan peton, ankaŭ malamikan, laŭ la politiko agordita sur ĝi. En la dua, la atingeblo mem estas la pordego, kio estas kruda sed reala akcepto.

Kie TLS haltas, kaj kion ĝi efektive pruvas

TLS inter retumilo kaj prokuro protektas tiun salton kaj ebligas al la retumilo kontroli la retejon, kiun ĝi intencis viziti. Se la prokuro finigas TLS, la peto ekzistas en legebla formo interne de tiu procezo antaŭ ol ĝi estas plusendita. Dua TLS-sesio al la origino povas protekti la sekvan salton kaj aparte kontroli la finpunkton de la aplikaĵo. Neniu el la sesioj decidas, kiu homo rajtas uzi la aplikaĵon. Wildcard-atestilo sur la prokuro ankaŭ ne etendiĝas al tiu dua salto.

Tio estas la parto, kiun homoj kunpremas en la vorton ĉifrita. Konfidenco, integreco kaj servila identeco estas transportaj ecoj; rajtigo estas decido de la aplikaĵo. Privata adreso malantaŭ tunelo ŝanĝas kiu povas atingi la ingon, ne kiu rajtas ensaluti poste.

Fidu plusenditajn kapliniojn nur de la prokuro

Aplikaĵoj, kiuj protokolas aŭ rajtigas laŭ la klienta adreso, kutime legas kaplinion, kiun la prokuro aldonas. Tiu kaplinio estas nur teksto, do io ajn, kio povas atingi la originon rekte, povas postuli ajnan adreson, kiun ĝi volas. Limigu la originon tiel, ke nur la tunela adreso de la prokuro povu konektiĝi, kaj agordu la aplikaĵon akcepti la kaplinion nur el tiu adreso.

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

Se tiu peto sukcesas de gastiganto, kiu ne estas la prokuro, la origino fidas kaplinion, kiun ĝi devus ignori. Riparu la aŭskultilon antaŭ ol tuŝi la aplikaĵon. Rifuzo estas multe pli bona rezulto ol protokola linio portanta falsitan adreson.

Tenu la originon atingebla el ekzakte unu loko

Ligu la aŭskultilon de la origino al la tunela adreso aŭ barikadu ĝin per fajroŝirmilo al la prokuro, poste konfirmu, kio efektive aŭskultas. Servo startigita kun wildcard-ligo akceptas konektojn sur ĉiu interfaco, kiun la gastiganto havas, inkluzive de unu, kiun vi forgesis esti enkursigebla. La aŭskulta tabelo estas la baza vero, ne la agorda dosiero, kiun vi intencis apliki. Se la wildcard-ligo estas intenca, la fajroŝirmilo ankoraŭ devas esti la komponanto, kiu mallarĝigas ĝin.

ss -ltnp | grep -E ':(80|443)'

Faru la saman revizion por administraj interfacoj, kiuj estas la kutima akcidenta elmeto. Poste skribu la du modelojn aparte: la publika retejo tra la prokuro, kaj la administra interfaco atingebla nur tra la tunelo. La frazo, ke la servilo estas malantaŭ VPN, diras nenion el tio.