Фиксни UDP портови могу да заобиђу прослеђивање портова, али не сваки NAT
Заштитни зид са стањем пропушта партнеров пакет као повратни саобраћај када оба краја фиксирају један порт. Ево када то ради и шта му тихо чини крај.
Два кућна рутера, ниједан прослеђен порт и VPN који се понекад ипак повеже. UDP то дозвољава, јер заштитни зид ће пропустити пакет који може да упари са током који је машина већ започела. То је условни трик, а не функција, и услове је лако навести кад знате шта заштитни зид пореди. Они су и разлог зашто се исти профили понашају различито на различитим мрежама.
Поређење које заштитни зид прави
Свака одлазна датаграма ствара краткотрајан запис: адреса извора, порт извора, адреса одредишта, порт одредишта. Све што стигне и поклопи се са записом третира се као одговор и пропушта. Правила за долазни саобраћај ту не играју улогу.
Дакле питање није да ли заштитни зид пушта партнера унутра. Питање је да ли пакет партнера изгледа као одговор који запис чека. Промените једно поље тог четвороделног тупла и пакет постаје странац. Зато се радна поставка може покварити кад се промени само број порта, и зато исти порт може радити на једном рутеру, а на следећем не.
Фиксирајте локални порт извора и исти број ће се појавити на обе стране размене. То је цео механизам и објашњава зашто је трик крхак, а не тајанствен.
Фиксирање једног порта на сваком крају
Подразумевани UDP порт OpenVPN-а је 1194, а lport поставља порт извора са којег шаље. Фиксирајте оба партнера и одлазни тупл сваког од њих показује на порт на којем други слуша:
# peer A
lport 1194
remote 198.51.100.20 1194
# peer B
lport 1194
remote 203.0.113.10 1194
То ради само док ниједан рутер између њих не преписује порт извора. Кад се пакети појаве у снимку, а тунел се не подигне, преписивање је први осумњичени.
Где тупл престаје да се поклапа
NAT који мапира по одредишту даје сваком партнеру другачији спољни порт. Адреса за коју је партнеру речено да је користи није адреса која до њега стиже, па долазни пакет не одговара ничему и бива тихо одбачен.
Превођење на нивоу оператера, наслагани NAT и рандомизација портова завршавају исто. Исто и свака средња кутија која преписује портове, а адресе оставља на миру.
Токовни транспорти су у горем положају. TCP руковање се прати корак по корак, па VPN заснован на TCP не може уопште да се пробије на овај начин и потребан му је слушалац негде на путу.
Обично једна страна прва попусти
У пракси се две мреже ретко понашају исто. Један рутер може да даје предвидиво мапирање, а други портове по одредишту, и резултат је конфигурација која ради између две куће, а не успева из мобилне мреже. Извештаји који противрече један другом обично описују два различита пара рутера. Ниједан аутор није у криву и ниједан резултат се не генерализује.
Пре него што дирнете профиле, откријте која је страна одбацила пакет. Снимци на оба краја решавају то из једног покушаја: датаграме које напусте A и никада не стигну до B значе да је ток преписан на путу, док датаграме које стигну до B без одговора значе да их заштитни зид није прихватио као повезане.
Два партнера са јавним IPv6 адресама заобилазе цео проблем. Без превођења нема шта да се упари, па је довољно правило заштитног зида које именује партнере и дизајн престаје да зависи од понашања рутера.
Када престати са покушајима
Домаћин са јавном адресом је поуздан одговор. Он може да заврши тунел за оба партнера или једноставно помогне да открију тренутну спољну адресу оног другог, и оба решења раде шта год NAT-ови радили. Управљани оверлеј пружа исту координацију ако политика то дозвољава.
Ниједно од ових не захтева искључен заштитни зид. Искључивање заштите да би се добила директна веза одбацује разлог због којег је директни покушај био привлачан и оставља машину отворену током целог теста.
Прво испробајте директно решење, па запишите шта сте видели. Понашање NAT-а и снимак који га је показао вреднији су од пара портова који сте на крају користили, јер ће следећа мрежа бити другачија. приручник за OpenVPN 2.6 документује lport и remote опције од којих ово зависи.