Unu URL por oficejo kaj VPN? Kial la mito pri la permeslisto malsukcesas

Konektu la tunelon, malfermu la saman legosignon, kaj la permesita retejo respondas precize kiel ĝi faris el la oficejo. Tio estas la supozo, sur kiu kaŝe ripozas la plej multaj planoj de fora aliro, kaj ĝi validas nur dum tri apartaj aferoj samtempe restas veraj. Neniu el ili estas trajto de la VPN-kliento, kaj neniu DNS-rikordo povas liveri iun ajn el ili. Kiam la legosigno malsukcesas hejme, la retumilo donas al vi unu ĝeneralan eraron, ĉu la kaŭzo estas mankanta vojo, neaprobigita elira adreso aŭ prokuro, kiu anstataŭigis la raportitan fonton. Trakti tiujn tri kiel unu problemon estas la maniero, per kiu malgranda politika ripeto fariĝas semajno da plilarĝigado de permeslistoj.

La dizajno, kiu postvivas renkonton kun reala oficeja reto, estas pli mallarĝa ol la supozo: eksplicita decida tabelo de tri vicoj, unu deviga punkto, kiun oni ne povas preterpasi, kaj nea testprovo, kiu pruvas ion. Malmunti la supozon venas unue, ĉar ĉio poste dependas de scii, kiu tavolo misprezentas la fonton.

La mito: konekti ne estas enkursigadi

Tunelo establiĝas, kaj la kliento instalas vojojn por ia aro da prefiksoj. Tio estas ĉio, kion konekti faras. Ĉu neligita HTTPS-peto vojaĝas tra la tunelo, kaj de kiu publika adreso ĝi ŝajnas veni kiam ĝi alvenas, estas decidoj farataj poste de aliaj komponantoj: la enkursiga tabelo elektas la vojon, kaj la eliro elektas la fonton.

Tial la oficejo kaj la kuireja tablo diverĝas kun la sama tekkomputilo, la sama retumila profilo kaj la sama legosigno. En la oficejo la peto eliras tra prizorgata publika adreso, kun kiu la reteja operatoro konsentis. Tra plena tunelo ĝi povas eliri tra la VPN-eliro, kiu estas alia adreso kaj, ĝis iu aldonas ĝin, neaprobigita. Tra dividita tunelo ĝi eble tute ne eniras la tunelon. Nur du el tiuj tri vojoj iam estis parto de la interkonsento kun la reteja posedanto, kaj la tria ne estas difekto riparinda per plia allow-linio.

Tri petstatoj, du aprobitaj eliroj

Skribu la matricon antaŭ ol tuŝi fajroŝirmilon, ĉar la tabelo estas la dizajno kaj la regulo nur unu el ĝiaj realigoj. La adresoj sube estas dokumentaj gamoj; anstataŭigu ilin per viaj propraj prizorgataj valoroj kaj konservu ilin ie, kie la reteja posedanto povas ilin kontroli.

La meza vico estas kie la plej multaj el tiuj planoj rompiĝas. Gravas la adreso, kiun vidas la deviga aparato, ne la privata adreso, kiun la tekkomputilo tenas ene de la tunelo, kaj ne ĝia LAN-adreso. Valoro kiel 10.8.0.6 signifas nenion por publika retejo, kaj same 192.168.1.44. Tunela adreso estas adresada detalo de la tunelo, ne atestilo, kiun la retejo povas kontroli.

Se via VPN ne povas liveri stabilan, dokumentitan eliron, la matrico havas neniun validan mezan vicon, kaj neniu kvanto da permeslistoj elpensos unu. La honestaj ebloj tiupunkte estas privata retejo atingata per eksplicitaj privataj vojoj, aŭ identec-konscia alirpordego antaŭ la aplikaĵo. Ambaŭ havas alian kontrakton ol publika permeslisto, kaj ambaŭ estas pli facile klarigeblaj al revizoro ol listo, kiu kreskis ĝis ĝi hazarde ekfunkciis.

Legu la fonton tie, kie la decido estas farata

Metu la limigon sur la aparaton, kiu finas la peton, kaj konfirmu, ke neniu alterna origina vojo preterpasas ĝin. La Nginx-alirmodulo taksas la instrukciojn allow kaj deny laŭorde, la unua kongruo gajnas, kaj reguloj hereditaj de ĉirkaŭanta bloko ankoraŭ validas ene de location. Mallarĝa allow apud larĝa allow en la sama loko kutime signifas, ke la larĝa decidas. Legu la tutan efikan agordon por tiu location antaŭ ol redakti eĉ unu ĝian linion.

server {
    listen 443 ssl;
    server_name intranet.example.com;

    set_real_ip_from 10.20.0.10;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    location /app/ {
        allow 203.0.113.24;    # office public exit
        allow 198.51.100.77;   # approved VPN egress
        deny  all;
        proxy_pass http://app_backend;
    }
}

Malantaŭ ŝarĝbalancilo aŭ inversa prokuro, tiu regulo vidas la prokuron krom se vi diras al ĝi alie. Restarigu la adreson de la alvokanto nur per la subtenata fidinda-prokura mekanismo, kun eksplicita listo de prokuraj adresoj. Peta kapo, kiu asertas aprobitan adreson, ne estas pruvo, ke la alvokanto posedas ĝin, kaj ĉe publika aŭskultanto nevalidigita plusendita kapo igas la permesliston ornamaĵo.

Poste kontrolu la alian adresan familion. Regula aro, kiu kovras nur IPv4, estas nekompleta decido por gastigantnomo, kiu ankaŭ respondas ĉe AAAA, kaj kliento kun funkcianta IPv6 atingos la saman aplikaĵon per vojo, kiun vi neniam reviziis.

Dividita tunelo: la peto, kiu neniam eniras

Dividita tunelo portas nur la prefiksojn en sia listo. Internaj oficejaj subretoj kutime eniras tiun liston; publika retejo ne. La retumilo solvas la nomon, komparas la elektitan adreson kun la enkursiga tabelo, kaj tamen trovas la lokan implican pordegon antaŭ ĝi.

Do la peto alvenas el la hejma konekto de la uzanto, estas rifuzata, kaj la raporto legiĝas kvazaŭ la VPN rompiĝis, dum la tunelo faras precize tion, por kio ĝi estis agordita. Du riparoj estas legitimaj: enkursigu tiun celon tra la tunelo kaj lasu la aprobitan eliron porti ĝin, aŭ akceptu, ke la retejo estas atingata rekte, kaj donu al foraj uzantoj alian aprobitan vojon, kiel la alirpordegon. Plilarĝigi la publikan permesliston de la retejo ĝis hejma adreso hazarde inkluziviĝas estas nek unu nek la alia, kaj ĝi forigas la limon, kiun la dizajno devintus devigi. La unuaj du konservas la matricon honesta; la tria kaŝe forviŝas vicon el ĝi.

Pruvu la rifuzon, poste la restaŭron

Testu per peto, kiu praktikas la realan decidon, de kliento staranta sur ĉiu vico de la tabelo. Atingebleca kontrolo kontraŭ ia neligita adres-montra paĝo pruvas nenion, ĉar tiu celo eble sekvas alian vojon ol la aplikaĵo.

curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'

Komparu la aliran rekordon de la limo kun tio, kion la tabelo antaŭdiris. Poste mallevu la tunelon kaj faru novan peton, kiu devus esti rifuzata; paĝo jam ŝargita aŭ konekto jam malfermita tute nenion testas. Se neniu rifuzo aperas, la deviga punkto ne estas tie, kie vi kredas.

Konservu aplikaĵan aŭtentikigon post la reta akcepto, ĉar oficeja eliro kaj VPN-eliro ĉiu reprezentas multajn homojn kaj neniu identigas individuon. La instrukcio por uzantoj restas mallonga: ŝaltu la aprobitan tunelon, poste reprovu. Tio konservas unu URL oportuna dum la fonta regulo restas decido anstataŭ konjekto.