VPN од локација до локација: кој правец навистина бара правило?

Двата краја известуваат за воспоставен тунел, далечната филијала одговара од портата, а апликацијата се уште истекува за корисниците на едната страна. Обичниот совет вели да се додаде правило на огнениот ѕид во двата правци. Понекогаш тоа е точно, понекогаш дуплира правило што веќе постои, а понекогаш второто правило е тоа што ја крши состојбата. Кој случај важи зависи од тоа каде огнениот ѕид го гледа пакетот.

Повратниот сообраќај со состојба го менува бројот

Огнениот ѕид со состојба го запишува барањето и го пушта одговорот без второ правило, па дизајнот на кој му треба само едно правило е нормален. Списокот за пристап без состојба нема таква меморија, и одговорот мора експлицитно да се дозволи. И двата се точни на сопствената платформа, и затоа советите се противречат.

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

Каде огнениот ѕид ги гледа дешифрираните пакети

Во тунел заснован на политики, огнениот ѕид може да го оцени шифрираниот пакет пред дешифрирањето и дешифрираниот пакет потоа, на различни интерфејси. Правило напишано за погрешниот интерфејс е присутно, точно и никогаш не се совпаѓа. Така множество правила копирано од функционално распоредување може да пропадне на идентичен хардвер.

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

Асиметричното рутирање ја крши претпоставката

Огнениот ѕид со состојба претпоставува дека ги гледа двете половини од разговорот. Ако одговорот се врати преку друга порта, тој уред нема состојба за барањето и го отфрла според сопствената политика. Симптомот е еднонасочен неуспех што ниту едно правило на страната на испраќачот не може да го поправи. Проследете ја патеката на одговорот пред да уредите нешто.

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

Проверете ги двата правци со вистински изворни адреси

Тестирајте со адресата што далечната страна навистина ја гледа, бидејќи преведувањето може да направи изворното правило да не се совпадне со ништо. Извршете фаќање на двете порти истовремено.

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

Барањето што се појавува на далечната порта со неочекувана изворна адреса објаснува правило што никогаш не се совпаѓа, а одговорот што пристигнува на погрешниот интерфејс објаснува несовпаѓање на состојбата. Потоа тестирајте една дестинација во одобрениот опсег и една надвор од него, за да биде границата покажана, а не претпоставена.

Запишете ја изворната адреса по преведувањето, интерфејсот што го користел дешифрираниот пакет и правилото што се совпаднало. Овие три факти одговараат на следниот тикет без да се повторува целата истрага.