Site-nei-site-VPN: hokker rjochting hat echt in regel nedich?

Beide kanten melde in oanleine tunnel, de fiere filiale antwurdet fan 'e gateway, en de applikaasje bliuwt foar brûkers oan ien kant yn 'e tiid rinne. It gewoane advys is om in brânmuorrerel yn beide rjochtingen ta te foegjen. Soms is dat goed, soms duplisearret it in regel dy't al bestiet, en soms is it de twadde regel dy't de steat brekt. Hokker gefal jildt hinget ôf fan wêr't de brânmuorre it pakket sjocht.

Steatfolle weromgong feroaret it oantal

In steatfolle brânmuorre registrearret de oanfraach en lit it antwurd troch sûnder twadde regel, dus in ûntwerp dat mar ien regel nedich hat, is normaal. In steatleaze tagongslist hat sa'n ûnthâld net, en it antwurd moat eksplisyt tastien wurde. Beide binne korrekt op har eigen platfoarm, en dêrom sprekke de advizen inoar tsjin.

Lês de trochstjoerdokumintaasje foar it platfoarm foar jo, en kontrolearje oft it belied dat jo bewurkje steatfol is wêr't it it pakket sjocht. In eksplisite wegering foar oanleine ferkear, of in regeloarder dy't it antwurd foar de steattabel evaluearret, makket in wurkjend ûntwerp riedseleftich. It oantal regels is in ymplemintaasjedetail, wylst de eask is dat beide rjochtingen fan in tastiene petear foltôgje kinne.

Wêr't de brânmuorre ûntsiferde pakketten sjocht

Yn in beliedsbasearre tunnel kin de brânmuorre it fersifere pakket foar ûntsifering en it ûntsifere pakket dêrnei evaluearje, op ferskillende ynterfaces. In regel skreaun foar de ferkearde is oanwêzich, korrekt en wurdt nea oanpast. Sa kin in regelset kopiearre út in wurkjende ynset fale op identike hardware.

Rûtebasearre IPsec en de measte moderne ymplemintaasjes leverje in tunnelinterface, sadat it ûntsifere pakket dêr oankomt en gewoane interface-regels jilde. Befêstigje hokker model de ynset brûkt foardat jo in regelset kopiearje út in hânlieding skreaun foar de oare. It tunnelinterface is ek it plak om te sjen as jo witte wolle oft in pakket oait ûntsifere is.

Asymmetrysk rûtebou brekt de oanname

In steatfolle brânmuorre nimt oan dat er beide helten fan it petear sjocht. As it antwurd weromkomt troch in oare gateway, hâldt dat apparaat gjin steat foar de oanfraach en smyt it fuort neffens syn eigen belied. It symptoom is in ienrjochtingsflater dy't gjin regel oan 'e stjoerende kant reparearje kin. Folch it paad fan it antwurd foardat jo eat bewurkje.

Kontrolearje de rûte fan it antwurd foardat jo in brede tastimmingsregel oan beide kanten ta foegje. Alles tolerearje op elk ynterface ferstoppet de rûteflater en ferbredelet tagelyk de tagong, wat de slimste kombinaasje is dy't beskikber is.

Kontrolearje beide rjochtingen mei echte boarneadressen

Test mei it adres dat de fiere kant echt sjocht, want oersetting kin in boarneregel hielendal neat lykje litte. Fier de opname op beide gateways tagelyk út.

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

In oanfraach dy't mei in ûnferwacht boarneadres op 'e fiere gateway ferskynt, ferklearret in regel dy't nea oanpast, en in antwurd dat op it ferkearde ynterface oankomt, ferklearret in steatmisferstân. Test dan ien bestimming binnen it goedkarde berik en ien dêrbûten, sadat de grins sjen litten wurdt ynstee fan oannommen.

Skriuw it boarneadres nei oersetting op, it ynterface dat it ûntsifere pakket brûkte, en de regel dy't oanpast waard. Dy trije feiten beantwurdzje it folgjende kaartsje sûnder it hiele ûndersyk te werheljen.