Firefox стартуван во namespace ја предаде URL-то на постоечка инстанца

Команда се извршува внатре во namespace-от на VPN, се појавува прозорец на Firefox, а страницата сепак излегува преку обичната врска. Поставувањето на рутирањето веројатно не е првото нешто што треба повторно да се изгради. Проверете дали командата ја создаде инстанцата на браузерот што ја очекувавте или го предаде URL-то на онаа што веќе работеше на друго место. Таа разлика го објаснува резултатот во еден чекор и штеди еден час со nftables.

Знакот е дека прозорецот се појавува веднаш, без студен старт.

Нов прозорец не е нова инстанца

Десктоп апликациите рутински повторно користат постоечки процес. Стартер во еден мрежен namespace не го преместува веќе работниот примач во тој namespace, зашто примачот никогаш не бил дел од стартувањето. Однесувањето на Firefox при далечинско управување е поврзано со профили: стартување против профил што веќе се користи ги предава аргументите на неговиот сопственик. Новиот прозорец е вистински; новата мрежна патека не е.

Приватното прелистување и опцијата за нов прозорец не се контроли за мрежна изолација.

Тоа не е ни знаменце од командната линија што влијае само на режимот на прозорецот. Ако профилот е зафатен, барањето оди кај процесот што го поседува, и тој процес го задржува namespace-от во кој почнал.

Присилете посебна инстанца на посебен профил

Користете наменски профил создаден преку поддржаниот работен тек за профили на браузерот и стартувајте го експлицитно со тој профил. Во градбите на Firefox што го поддржуваат тоа, --new-instance бара нова инстанца наместо прозорец во постоечка. Погледнете го сопствениот излез за помош на инсталираната градба, зашто достапните знаменца се разликуваат по верзија.

Не обидувајте се истовремено да го отворите истиот активен профил и не третирајте предупредувањето дека профилот е во употреба како упатство да ги избришете датотеките за заклучување.

Стартувајте го браузерот и под неговиот обичен корисник што не е root. Поставувањето на мрежата често бара административни права, и примамливо е да му ги дадете истите на браузерот зашто е дел од истиот експеримент. Графичкиот браузер не ги бара, а неговото стартување како root создава посебна класа на проблеми со профилот и дозволите. Држете ја привилегијата и мрежната патека како две независни одлуки.

Проверете кој процес го носи сообраќајот

На Linux, мрежниот namespace на процесот е видлив преку неговата врска за namespace. Прочитајте ја за процесот за кој мислите дека го прави барањето, а потоа за процесот што навистина го прави.

readlink /proc/ACTUAL_PID/ns/net

Браузерите работат со повеќе процеси, затоа идентитетот е важен: процесот на содржината што ја воспоставува врската можеби не е тој што прв го проверивте. Споредете ја врската со namespace-от што го имавте на ум и потврдете со свежо, безопасно барање што можете да го припишете на една инстанца. Припишувањето е целиот тест. Ако не можете да кажете кој процес ја воспоставил врската, не сте го тестирале namespace-от.

Кога namespace-от навистина е погрешен

Понекогаш стартерот навистина не успева и новата инстанца почнува во погрешниот namespace. Проверете ја услугата или обвивката што го создала, зашто единица или запис на работниот простор може да го загуби namespace-от кога ќе се изврши повторно преку сесиската магистрала. Потоа тестирајте повторно од терминал внатре во правилниот namespace пред да го обвините браузерот. Една променлива одеднаш е единствениот начин ова да остане дијагностички.

Споделувањето екран не споделува ни resolver.

Ако процесот е во правилниот namespace, а раздвојувањето на имињата сѐ уште не успева,истражете ја неговата resolver-околина како посебен проблем. Ниту една друга промена на рутирањето не може да премести барање што било предадено на погрешната инстанца уште пред да почне.