VPN-ը երթուղիչում, թե պորտի փոխանցում. ո՞րն է հաղթում։

Երթուղիչն ինքն է ավարտում VPN-ը, և հին փոխանցման կանոնը դեռևս նույն UDP պորտն ուղարկում է LAN-ի մի մեքենայի։ Դրանցից միայն մեկը կարող է իրական վերջնակետը լինել, և միջուկը նրանց միջև չի դատում։ Նպատակակետի թարգմանությունը վերագրում է փաթեթը նախքան տեղական ծառայությանը դիմելը, ուստի VPN գործընթացը սպասում է տրաֆիկի, որն արդեն ուղարկվել է այլ տեղ։ Խնդիրն է որոշել, թե ով է տիրապետում պորտին, ապա կանոնները համաձայնեցնել։

Մեկ պորտ, երկու հավակնոտ սեփականատեր

Երթուղիչի ներսում աշխատող VPN սերվերին անհրաժեշտ է մուտքային թույլտվություն, որը տանում է դեպի իր սեփական սոկետը։ Նույն պորտի նպատակակետ-NAT գրառումը տանում է բոլորովին այլ տեղ՝ LAN հասցե և փոխանցման որոշում։ Դրանք տարբեր վերջնակետեր են՝ տարբեր մատյաններով և տարբեր ձախողման եղանակներով։ Սովորական նշանն այն է, որ մի հասցեային ընտանիք աշխատում է, իսկ մյուսը՝ ոչ, որովհետև մնացած գրառումը գրվել է մեկ ընտանիքի համար և երբեք չի վերանայվել։

Գրանցեք պահանջը խմբագրելուց առաջ՝ ընտանիք, արտաքին հասցե, տրանսպորտ, պորտ և թարգմանված նպատակ։

Թարգմանությունը կատարվում է տեղական ստուգումից առաջ

Նպատակակետ NAT-ը փոխում է փաթեթի նպատակը նախնական երթուղավորման փուլում, նախքան միջուկը կընտրի տեղական առաքման և փոխանցման միջև։ Հենց նպատակը դառնում է LAN հոսթ, փաթեթն անցնում է փոխանցման ուղով։ Երթուղիչի սեփական սոկետի մուտքային կանոնները երբեք չեն դիտարկվում, դրա համար VPN մատյանը դատարկ է մնում, մինչ հաճախորդը սպասում է։

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

Այդ հերթականությունը ողջ մեխանիզմն է, և սարքերի ինտերֆեյսները թաքցնում են այն նշիչների հետևում՝ չփոխելով այն։ Փաթեթի ուղին դեռևս որոշում է նպատակակետի սեփականատերը։

Եթե LAN հոսթը նախատեսված վերջնակետն է, փոխանցումը ճիշտ է, և երթուղիչը չպետք է նույն պորտով նաև լսի։

Պահեք մեկ քարտեզագրում և հեռացրեք մյուսը

Թվարկեք այդ պորտի և ընտանիքի NAT գրառումները և ընտրեք վերապրողին՝

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

Նույն համարով TCP գրառումը անտեղի է UDP ձախողման համար, և դրանք որպես մեկ օբյեկտ դիտարկելը հանգեցնում է սխալ կանոնի ջնջման։ Երբ տեղական սոկետը պետք է հաղթի, հակասող քարտեզագրման սեփականատերը հեռացնում կամ վերագրում է այդ մեկ գրառումը, և երթուղիչի սեփական պորտի մուտքային թույլտվությունը մնում է տեղում։ Անկապ փոխանցումները, կառավարման ուղին և կանոնների հավաքածուի պատճենը բոլորը պետք է վերապրեն փոփոխությունը։

Եթե VPN-ը բնակվում է առանձին հոսթում, փոխանցումը ճիշտ օբյեկտն է։ Կոնտեյներում կամ վիրտուալ մեքենայում գտնվող ծառայությունը կարող է հրապարակված պորտի կարիք ունենալ նույնիսկ այն դեպքում, երբ տուփը կոչվում է երթուղիչ, ուստի հետևեք սոկետին և նրա անվանատարածքին, ոչ թե պատյանի պիտակին։

Հաստատեք սեփականատիրոջը դրսից

Փորձարկեք յուրաքանչյուր ընտանիք առանձին, որովհետև երթուղիչում ավարտվող IPv6 կապը ոչինչ չի ասում այն IPv4 կապի մասին, որը հին կանոնը վերահասցեավորում է։ Կարդացեք ընդունող ծառայության մատյանը՝ տեսնելու, թե որ վերջնակետն է պատասխանել, և հաճախորդի հաջողության հաղորդագրությունը համարեք թույլ ապացույց։ Իմաստալից փորձարկման համար անհրաժեշտ է նոր հոսք։ Արտաքին հոսթից զոնդ ուղարկեք nc -zvu 203.0.113.7 1194-ով և կարդացեք հաղթողի մատյանը journalctl -u openvpn@server -n 20-ով։ Երթուղիչի լսողն ինքն է գրանցում կապը, մինչդեռ LAN հոսթը գրանցում է այն իր սեփական ծառայության մեջ։

Կապերի հետևումը պահում է գոյություն ունեցող հոսքերը իրենց սկզբնական քարտեզագրման վրա, ուստի հաստատված սեանսը կարող է ապրել ձեր հենց նոր ուղղած կանոնից ավելի երկար։

Երբ նախատեսված վերջնակետը պատասխանում է իր սովորական ինքնության ստուգումներով, փորձարկեք թունելի հետևում գտնվող մասնավոր ռեսուրս։ Արտաքին լսողին հասնելը միայն առաջին ցատկն է. ներքին երթուղավորումը և հավելվածի լիազորումը առանձին արդյունքներ են։