SNX Linux: 32 bitu bibliotēkas un atkārtoti iestatāms risinātājs

SNX Linux vidē neizdodas ielādētājā, maršrutu tabulā vai risinātājā, un katra kļūda izskatās kā pieteikšanās problēma. Apstrādājiet četrus simptomus pēc kārtas.

Check Point SSL Network Extender Linux vidē neizdodas četros atpazīstamos veidos, un trīs no tiem tiek nepareizi nolasīti kā pieteikšanās problēma. Vai nu binārais fails nepalaižas, vai palaižas un neatstāj maršrutu, vai savienojas un nosaukumu izšķiršana mirst, vai pārlūka portāls strādā, bet komandrinda ne. Apstrādājiet tos šajā secībā, jo katrs ir nākamā ievades nosacījums.

Pirmais simptoms: ielādētājs atsakās pirms pieteikšanās

No ugunsmūra iegūtais instalētājs ievieto 32 bitu setuid-root bināro failu /usr/bin/snx. 64 bitu distribūcijā tas nedarbojas, kamēr nav iespējota i386 arhitektūra un nav bibliotēku, ar kurām tas ir saistīts.

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install libstdc++5:i386 libstdc++6:i386 libx11-6:i386 libpam0g:i386
ldd /usr/bin/snx | grep "not found"

Tukšs not found saraksts ir vārti visam, kas seko. Precīzā pakotņu kopa mainās starp laidieniem: vienam strādājošam ziņojumam bija vajadzīgas libstdc++5:i386, libx11-6:i386 un libpam0g:i386, citam bija vajadzīgas arī libstdc++6:i386. Lasiet ldd, nevis kopējiet pakotņu sarakstu no apmācības, kas rakstīta citai distribūcijai.

Ja snx nav atrodams vispār, instalētājs nekad netika pabeigts vai tika instalēts kaut kur ārpus jūsu PATH. Tā ir cita kļūda, un to ir vērts apstiprināt pirms arhitektūru pievienošanas sistēmai. Pārbaudiet ar command -v snx un ieskatieties mapē, ko norādīja instalētājs. i386 pakotņu pievienošana mašīnai, kurā binārā faila vienkārši nav, neko nelabo.

Otrais simptoms: pieteikšanās izdodas, un nekas netiek maršrutēts

Veiksmīga pieteikšanās izveido tunsnx un pati rediģē maršrutu tabulu, tāpēc pārbaudiet, kas patiešām pastāv, pirms kaut ko citu maināt.

ip -br addr show tunsnx
ip route | grep tunsnx
snx -d

Demontāžai izmantojiet snx -d. Procesa nogalināšana atstāj saskarni un tās maršrutus, un nākamais mēģinājums tad neizdodas iemesla dēļ, kam nav nekāda sakara ar akreditācijas datiem. Pirmā pieteikšanās arī ieraksta servera parakstu zem /etc/snx/, tāpēc nepārraudzītam skriptam var būt nepieciešama viena interaktīva izpilde, pirms tas vispār var strādāt. Dzēsiet šo stāvokli tikai tad, kad plānojat serveri apstiprināt no jauna.

Trešais simptoms: nosaukumi tiek izšķirti, līdz tunelis paceļas

Šis klusi salūzt. snx ieraksta grūstos DNS serverus tieši /etc/resolv.conf. Kur šis ceļš ir simboliskā saite uz /run/systemd/resolve/, izmaiņas var pazust nākamajā risinātāja notikumā, un pēc atvienošanas grūstie ieraksti tikpat labi var palikt.

Darbojas divi izkārtojumi, un izvēlei jābūt apzinātai, nevis tādai, ko ieteica pirmais meklēšanas rezultāts:

  • Pārņemiet failu: aizstājiet simbolisko saiti ar statisku failu un instalējiet libnss-resolve kopā ar tā i386 variantu, lai nosaukumu servisam joprojām būtu rezerves ceļš, kad fails tiek pārrakstīts zem tā.
  • Paturiet systemd-resolved kā īpašnieku un reģistrējiet tuneļa saiti: resolvectl dns tunsnx 10.0.0.10, tad resolvectl domain tunsnx corp.example, un apstipriniet ar resolvectl status.

Pierakstiet pirms VPN esošos nosaukumu serverus pirms savienošanās. Ja failu rediģējat ar roku, grūsto ierakstu noņemšana pēc tam ir procedūras daļa, nevis neobligāta tīrīšana, jo portatīvais dators, kas pēc atvienošanas saglabā uzņēmuma DNS, nespēs izšķirt neko citu.

Ceturtais simptoms: portāls strādā, bet CLI ne

Nesenie ugunsmūra laidieni pārvietoja starpprogrammatūru no pārlūka uz vietējo Java dēmonu, tāpēc portāls sazinās ar vietējo aģentu portā 14186. Šai adresei nepieciešams pārlūka sertifikāta izņēmums un darbojošs process.

ps ax | grep cshell
/usr/bin/cshell/launcher

Komandrinda ir atsevišķs ceļš: snx -s vpn.example.com -u user, kur ~/.snxrc glabā serveri, lietotājvārdu un atkārtotas autentifikācijas izvēli. Strādājoša portāla sesija neko neizsaka par to, vai CLI ir pareizi instalēta, un kailais klients neapstrādā vienreizējus kodus.

Konteineru saīsne, kas izmaksā vairāk nekā ietaupa

snx pārbauda tun moduli, to ielādē, ja tā nav, izveido tuneļa saskarni, pārraksta maršrutus un dzen satiksmi caur to. To reproducēt konteinerī nozīmē montēt /dev un /lib/modules un piešķirt plašas iespējas, kas konteinerim nodod lielāko daļu resursdatora tīkla administrēšanas.

Kad smilškaste tiešām ir vajadzīga, virtuālā mašīna ir tīrāka robeža: klients iegūst kodolu, ko drīkst mainīt, un resursdators saglabā savu maršrutu tabulu. Izvēlieties to, pirms veltīt pēcpusdienu iespējām, par kuru piešķiršanu jūs nožēlosiet.

Saistītie raksti