DS-Lite је начин да се клијенту да IPv4 повезивање преко приступне мреже која преноси само IPv6. Кућни рутер нема сопствену посвећену јавну IPv4 адресу, и та једна чињеница убеђује људе да IPv4 VPN не може да ради са те везе. У одлазном смеру обично ради добро. Везу преводи добављач, а далека страна види обичног IPv4 клијента. Оно што се квари је супротан смер: хостинг нечега што очекује непозван долазни IPv4. Разлика је у томе која страна започиње разговор.

Која страна започиње везу

Клијент који започиње везу ствара стање превода у ходу. Преводилац добављача види први пакет, додељује мапирање и прослеђује га. Повратни саобраћај одговара том мапирању јер мапирање већ постоји.

Сервер који чека везе нема такво стање да створи. Неко споља мора да стигне до адресе и порта које добављач није прихватио да мапира, а то је сасвим други захтев.

Пратите одлазни захтев

Архитектура у RFC 6333 именује оба краја. Елемент на страни клијента је B4, који инкапсулира IPv4 у IPv6. Елемент на страни добављача је AFTR, који обавља превод адресе и прослеђује пакет као IPv4.

Client's IPv4 VPN packet
  → Customer B4
  → IPv4 carried over the provider's IPv6 network
  → AFTR address translation
  → IPv4 VPN server

VPN сервер прима нормалну IPv4 везу са преведене адресе добављача. Не треба му DS-Lite режим, посебан порт ни свест о томе да је приступна мрежа клијента само IPv6. То је део који људи пропуштају: далека страна то не може да препозна.

Сопствена конфигурација клијента је исто тако обична. Потребна јој је радна IPv4 путања до сервера, коју B4 и AFTR обезбеђују, и потребно је да се име домаћина сервера реши у IPv4 адресу.

Зашто је долазни хостинг случај који не успева

Покретање IPv4 VPN сервера код куће је решење које се судара са заједничким адресирањем добављача. Преводилац добављача поседује јавну адресу и табелу мапирања и нема разлога да створи трајно долазно мапирање за једног претплатника.

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

Ту се превод на нивоу оператера разликује од једне јавне адресе: чак и исправно локално преусмеравање може да заврши на адреси коју дели много претплатника.

Дијагностикујте пре него што промените план приступа

Прво потврдите обезбеђени режим. Уграђени двоструки стек, DS-Lite и мрежа само са IPv6 која користи други механизам превода су три различита уређења, а маркетиншка имена добављача не одговарају увек техничком.

Затим утврдите четири запажања за одлазни квар. Да ли клијент решава име домаћина VPN у IPv4 одредиште? Да ли ради обична IPv4 повезаност, уместо захтева прегледача који је можда тихо користио IPv6? Који транспорт и порт клијент покушава, и да ли дневници крајње тачке уопште виде тај покушај? Да ли се квар дешава током почетне размене, после периода мировања или само при већим преносима?

Та четири одговора упућују на филтрирање, истек стања превода, погрешну крајњу тачку или руковање величином пакета. Ништа од тога се не утврђује гледањем DS-Lite на страници налога.

Пажљиво читајте промене добављача

Промена налога може да се поклопи са радном везом док мења неколико својстава одједном. Забележите које својство се променило, јер ново име пакета није техничко објашњење.

Упутство да се укључи двоструки стек је двосмислено док неко не потврди шта добављач заиста обезбеђује. Третирање тога као универзалног захтева за IPv4 VPN клијенте претвара претпоставку у политику.

Ако је стварни захтев долазни IPv4 хостинг, разговарајте са добављачем о подржаном долазном уређењу, уграђеном адресирању или другом дизајну приступа. Ако је захтев преносни рачунар који стиже до удаљеног сервера, питајте уместо тога о том тачном одлазном току. Редослед рада: именујте смер, потврдите обезбеђени режим, тестирајте обичан IPv4 и један транспорт, и промените план приступа само ако смер то заиста захтева.

Повезани чланци