Jedna VPN završna točka kroz Squid: usko CONNECT izuzeće

Squid na CONNECT zahtjev odgovara prvim http_access retkom koji se podudara, a taj redak može biti odbijanje. Ta jedna činjenica objašnjava zašto izuzeće za VPN završnu točku obično propada iz prvog pokušaja, jer zahtjev nikada ne stigne do dopuštenja koje je netko dodao na dnu. Usko rješenje zadržava postojeće čuvare portova i uči ih o jednom pregledanom izvoru, odredištu i portu. Sve ostalo na proxyju ponaša se točno kao prije.

Kako Squid odlučuje o CONNECT zahtjevu

CONNECT zahtjev imenuje host i port, a Squid prolazi kroz http_access retke redom dok se jedan od njih ne podudara. Podudaranje odbijanja odmah prekida procjenu i klijent dobiva 403 od proxyja. Zato je položaj pravila važniji od njegove formulacije. Pomicanje istog retka jedan korak više može potpuno promijeniti ishod.

Uobičajeni čuvari odbijaju sve izvan Safe_ports i odbijaju CONNECT izvan SSL_ports. Ta imena su ACL definirani u vašoj vlastitoj konfiguraciji, pa njihov sadržaj pripada vama, a ne protokolu. Distribucija može dopustiti širok raspon portova kao Safe_ports dok zasebno ograničava CONNECT. Pročitajte žive vrijednosti prije nego pretpostavite da je port blokiran po dizajnu.

Potvrdite da je proxy komponenta koja odbija zahtjev. 403 koji generira Squid nimalo ne sliči TLS upozorenju s VPN poslužitelja, a spajanje dvaju u jedan problem košta prvi sat. Provjerite redak pristupnog dnevnika za zahtjev, jer bilježi i radnju i pravilo koje ju je proizvelo.

Napravite jedno kombinirano podudaranje umjesto tri odvojena ACL-a

Izuzeće sagradite od tri činjenice: odobrenog raspona izvora, jedne odobrene adrese odredišta i jednog jedinog porta na kojem završna točka sluša. Dva odvojena ACL-a i jedno kombinirano podudaranje daju vrlo različitu politiku, jer se procjenjuje upravo kombinacija. Kombiniranom ACL-u dajte ime po tome što dopušta, a ne po metodi koju nosi.

Oblik ispod koristi dokumentacijske raspone koje treba zamijeniti pregledanim vrijednostima. Squid ne zadržava nijedno od tih imena, pa ih vi birate i vi ih održavate usklađenima. Ovaj je recept ograničen na Squid 6 i 7, čija dokumentirana konfiguracija podržava all-of grupu. Trenutna referenca označava te direktive nedostupnima u Squid 8, pa ovo tretirajte kao recept vezan uz verziju, a ne kao put migracije, i provjerite direktivu u referenci svoje verzije prije primjene.

acl pvpn_src src 192.0.2.128/25
acl pvpn_dst dst 198.51.100.77/32
acl pvpn_port port 1194
acl pvpn_ok all-of CONNECT pvpn_port pvpn_dst pvpn_src

all-of grupa podudara se samo kad se podudara svaki član, što znači da se izvor, odredište i port provjeravaju u jednom retku. Grupa sama po sebi ništa ne daje, a zahtjev koji se podudara sa samo dvije od tri činjenice ne može je zadovoljiti. To svojstvo drži izuzeće uskim kad netko kasnije doda drugi pristupnik. Ili se novo odredište dodaje namjerno, ili se zahtjev vraća na izvorne čuvare.

Savijte čuvare portova bez uklanjanja

Na svojim postojećim pozicijama dva uobičajena čuvarska retka izgledaju ovako. Obično stoje poslije autentifikacije i prije redaka politike koji dopuštaju bilo što.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Dodajte negirano kombinirano podudaranje svakome od njih, tako da podudarajuće izuzeće preživi čuvara koji bi ga inače odbio. Mijenjaju se samo čuvarski retci, i to samo za po jedan dodatni član svaki.

http_access deny CONNECT !SSL_ports !pvpn_ok
http_access deny !Safe_ports !pvpn_ok

Članovi u jednom pristupnom retku kombiniraju se, pa redak sada odbija samo zahtjeve koji padnu i na izvornoj provjeri i na izuzeću. Zahtjev za odobrenu završnu točku prolazi, a svaki drugi zahtjev zadržava staro ponašanje porta. Ovo je uže od dodavanja porta na globalnu SSL_ports listu, što bi taj port dopustilo svakom odredištu. Ako port već postoji na toj listi, ovaj ACL ništa ne sužava i starije, šire dopuštenje i dalje vrijedi za druga odredišta, pa pročitajte živu listu prije nego tvrdite da je izuzeće otvorilo port. Ono je i reverzibilno, jer se dva retka vraćaju u prethodni oblik. Referenca za kontrolu pristupa dokumentira redoslijed i uobičajene čuvare o kojima ova promjena ovisi.

Gdje se izuzeće ne smije postaviti

Iskušenje je staviti dopuštenje iznad čuvara i završiti. Takav smještaj preskače i zaštite autentifikacije i lokalnog odredišta koje obično stoje pri vrhu radne konfiguracije. Rezultat nije usko izuzeće, nego rupa s komentarom iznad sebe. Svako novo dopuštenje držite na istom pregledanom stupnju kao i ostatak klijentske politike.

Provjerite što zahtjevu još treba nakon čuvara portova. Autentificirani račun, dopuštena adresa klijenta i politika odredišta sve vrijede i dalje, a izuzeće ne mijenja nijedno od toga. Ako vaš proxy već dopušta odobrenom računu dosegnuti proizvoljna odredišta, čuvar porta nikada nije bio prava kontrola.

Razmotrite je li završna točka uopće TCP. CONNECT izuzeće prenosi TCP tokove, a OpenVPN profil koji koristi UDP neće postati dostupan kroz njega. Promijenite profil na TCP samo ako poslužitelj tako sluša i operator prihvaća razliku u ponašanju.

Provjerite granicu parserom i stvarnim zahtjevom

Parsirajte konfiguraciju prije ponovnog učitavanja i držite drugu sesiju otvorenom dok to radite. Sintaksna pogreška pri učitavanju može ostaviti proxy na staroj konfiguraciji ili odbiti novu u cijelosti. Parser prijavljuje odbijeni redak, što je više nego što će vam reći klijentska pogreška.

Zatim ponovno učitajte i pošaljite jedan stvarni CONNECT kroz proxy s odobrenog izvora. Pokretanje parsera dolazi prvo, jer ponovno učitavanje s tipfelerom ne uči vas ničemu o politici.

squid -k parse
squid -k reconfigure
curl -v -p -x http://proxy.lab.internal:3128 https://vpn.lab.internal:1194/ --max-time 5

Testirajte tri slučaja: odobreni izvor i račun, neodobreni izvor i drugo odredište na istom portu. Treći slučaj dokazuje da je izuzeće usko, jer koristi port bez podudaranja odredišta. Pročitajte pristupni dnevnik za sva tri umjesto da vjerujete klijentskoj poruci. Uspješan CONNECT uspostavlja TCP tok i ništa više, pa VPN rukovanje ostaje zaseban test.